คล็อด เฟเบิล 5: ทำความเข้าใจขีดจำกัดอัตราการใช้งาน

หากคุณกำลังพัฒนาบนโมเดลใหม่ล่าสุดของ Anthropic และสงสัยเกี่ยวกับขีดจำกัดอัตรา (rate limits) ของ Claude Fable 5 นี่คือคำตอบที่ตรงไปตรงมา: Anthropic ไม่ได้จัดส่งระบบขีดจำกัดอัตราแยกต่างหากสำหรับ Fable 5 โดยเฉพาะเมื่อเปิดตัว Fable 5 (รหัสโมเดล claude-fable-5, ราคา 10 ดอลลาร์ต่อล้านโทเค็นอินพุต และ 50 ดอลลาร์ต่อล้านโทเค็นเอาต์พุต, เปิดตัวเมื่อวันที่ 9 มิถุนายน 2026) ใช้ Messages API มาตรฐานเดียวกัน และอิงตามขีดจำกัดอัตรา API แบบเทียร์มาตรฐานขององค์กรคุณ ขีดจำกัดเหล่านั้นจะปรับเพิ่มขึ้นตามการใช้งานและประวัติการใช้จ่ายของบัญชีคุณ ซึ่งบังคับใช้ต่อองค์กรและต่อคลาสโมเดล และตัวเลขที่แน่นอนที่คุณได้รับขึ้นอยู่กับเทียร์การใช้งานที่คุณอยู่ กรอบแนวคิดนี้มีความสำคัญ เพราะหากคุณกำลังวางแผนความจุสำหรับเอเจนต์ Fable 5 คุณกำลังวางแผนตามระบบเทียร์ของ Anthropic ไม่ใช่ตามตัวเลขวิเศษที่พิมพ์อยู่ในการประกาศเปิดตัว หากคุณเพิ่งเริ่มต้นกับโมเดลนี้ ภาพรวมของ Claude Fable 5 เป็นบทความเสริมที่ดีในการอ่าน

สรุป (TL;DR)

Claude Fable 5 ใช้ขีดจำกัดอัตราแบบเทียร์มาตรฐานของ Anthropic: จำนวนคำขอต่อนาที (RPM) บวกกับโทเค็นอินพุตต่อนาที (ITPM) และโทเค็นเอาต์พุตต่อนาที (OTPM) ซึ่งบังคับใช้ต่อองค์กรและต่อคลาสโมเดล ขีดจำกัดจะเพิ่มขึ้นเมื่อยอดใช้จ่ายสะสมของคุณขยับขึ้นไปในเทียร์การใช้งาน (1 ถึง 4) โปรดยืนยันตัวเลขจริงของคุณเสมอใน Anthropic Console และจัดการข้อผิดพลาด 429 โดยการอ่านเฮดเดอร์ retry-after

ขีดจำกัดอัตราของ Anthropic ทำงานอย่างไร

Anthropic ไม่ได้กำหนด "ขีดจำกัด API" ทั่วโลกเพียงค่าเดียว แต่ใช้ระบบเทียร์การใช้งาน และเทียร์ของคุณจะเป็นตัวกำหนดปริมาณงาน (throughput) ที่คุณได้รับ มีแนวคิดที่เกี่ยวข้องสองอย่าง: ขีดจำกัดการใช้จ่าย (คุณสามารถเรียกเก็บเงินได้เท่าไหร่ต่อเดือนปฏิทิน) และขีดจำกัดอัตรา (คุณสามารถเรียก API ได้เร็วแค่ไหน) บทความนี้เกี่ยวกับอย่างหลัง แต่ทั้งสองอย่างเชื่อมโยงกัน เพราะเทียร์ของคุณคือสิ่งที่ขับเคลื่อนทั้งคู่

ประเภทของขีดจำกัด

สำหรับ Messages API ขีดจำกัดอัตราจะถูกวัดในสามมิติ ซึ่งแต่ละมิติจะถูกบังคับใช้ต่อนาทีและต่อคลาสโมเดล:

• คำขอต่อนาที (RPM): คุณสามารถเริ่มต้นการเรียก API ที่แยกกันได้กี่ครั้งในแต่ละนาที
• โทเค็นอินพุตต่อนาที (ITPM): คุณสามารถส่งโทเค็นอินพุตได้กี่โทเค็นในแต่ละนาที สำหรับโมเดลส่วนใหญ่ในปัจจุบัน จะนับเฉพาะโทเค็นอินพุตที่ไม่ได้แคชเท่านั้น โทเค็นที่อ่านจากแคชพร้อมต์จะไม่นับรวมใน ITPM ซึ่งเป็นเหตุผลว่าทำไมการแคชจึงสามารถเพิ่มปริมาณงานที่มีประสิทธิภาพของคุณได้สูงกว่าตัวเลขดิบมาก
• โทเค็นเอาต์พุตต่อนาที (OTPM): โมเดลสามารถสร้างโทเค็นให้คุณได้กี่โทเค็นในแต่ละนาที สิ่งนี้จะถูกประเมินแบบเรียลไทม์เมื่อโทเค็นถูกสตรีมออก และค่าสูงสุด max_tokens ของคุณจะไม่ถูกเรียกเก็บเงินล่วงหน้า การตั้งค่า max_tokens ที่สูงด้วยตัวมันเองไม่ได้ใช้ OTPM เพียงแค่โทเค็นที่ถูกสร้างขึ้นจริงเท่านั้นที่จะถูกนับ

Anthropic บังคับใช้สิ่งเหล่านี้ด้วยอัลกอริทึมโทเค็นบัคเก็ต แทนที่จะรีเซ็ตโควต้าเต็มของคุณในตอนต้นของแต่ละนาที ความจุของคุณจะเติมเต็มอย่างต่อเนื่องจนถึงค่าสูงสุด ผลที่ตามมาคือ ขีดจำกัดเช่น "50 RPM" สามารถทำงานได้เหมือนประมาณหนึ่งคำขอต่อวินาที ดังนั้นการเรียกแบบรัวๆ อาจทำให้เกิดการชนขีดจำกัดได้ แม้ว่าค่าเฉลี่ยต่อนาทีของคุณจะดูปกติก็ตาม การส่งข้อมูลที่ราบรื่นและสม่ำเสมอจะได้รับประโยชน์จากตัวเลขเดียวกันมากกว่าการส่งข้อมูลที่ไม่สม่ำเสมอ

ต่อองค์กร ต่อคลาสโมเดล

รายละเอียดเพิ่มเติมสองอย่างกำหนดว่าตัวเลขเหล่านี้จะนำไปใช้กับคุณอย่างไร ประการแรก ขีดจำกัดถูกกำหนดในระดับองค์กร ไม่ใช่ต่อ API key ดังนั้น API key ทุกตัวในองค์กรของคุณจะใช้จากพูลเดียวกัน (คุณสามารถกำหนดขีดจำกัดที่เล็กกว่าต่อพื้นที่ทำงานได้ หากคุณต้องการป้องกันพื้นที่ทำงานหนึ่งจากอีกพื้นที่ทำงานหนึ่ง) ประการที่สอง ขีดจำกัดจะถูกนำไปใช้ต่อคลาสโมเดล ซึ่งหมายความว่าการส่งข้อมูลของ Fable 5 และการส่งข้อมูลของ Opus (ตัวอย่างเช่น) จะถูกวัดกับบัคเก็ตที่แยกจากกัน คุณสามารถเรียกใช้คลาสโมเดลที่แตกต่างกันไปจนถึงขีดจำกัดของแต่ละคลาสได้พร้อมกัน โดยที่คลาสหนึ่งจะไม่กีดกันอีกคลาสหนึ่ง

เทียร์ก้าวหน้าอย่างไร

เทียร์จะก้าวหน้าโดยอัตโนมัติเมื่อการซื้อเครดิตสะสมของคุณถึงเกณฑ์ที่กำหนด ตามเทียร์ที่ Anthropic เผยแพร่ (ตรวจสอบสถานะของคุณเองใน Console) โครงสร้างจะมีลักษณะดังนี้: เทียร์ 1 ปลดล็อคเมื่อซื้อเครดิต 5 ดอลลาร์, เทียร์ 2 ที่ยอดสะสม 40 ดอลลาร์, เทียร์ 3 ที่ยอดสะสม 200 ดอลลาร์ และเทียร์ 4 ที่ยอดสะสม 400 ดอลลาร์ โดยมีขีดจำกัดการใช้จ่ายรายเดือนเพิ่มขึ้นในแต่ละขั้น คุณจะเลื่อนระดับทันทีที่คุณข้ามเกณฑ์ ไม่ต้องยื่นคำร้องใดๆ เหนือเทียร์ 4 ขีดจำกัดที่สูงขึ้นจะดำเนินการผ่านฝ่ายขายหรือการออกใบแจ้งหนี้รายเดือน

สำหรับข้อมูลเชิงลึกเพิ่มเติมว่าการซื้อเหล่านั้นแปลงเป็นค่าใช้จ่ายในโมเดลเฉพาะนี้อย่างไร รายละเอียดราคา Claude Fable 5 เป็นส่วนเสริมที่ดีในส่วนนี้

สิ่งนี้มีความหมายอย่างไรสำหรับ Claude Fable 5 โดยเฉพาะ

นี่คือส่วนที่ผู้คนต้องการทราบมากที่สุด Fable 5 ไม่ได้มีกรอบขีดจำกัดที่แปลกประหลาดเฉพาะโมเดล มันถูกจัดเข้าอยู่ในตารางเทียร์มาตรฐานในฐานะคลาสโมเดลของตัวเอง ดังนั้นคำถามที่ว่า "ขีดจำกัด Fable 5 ของฉันคืออะไร" จึงกลายเป็น "องค์กรของฉันอยู่ในเทียร์ใด และแถวของ Fable 5 บอกว่าอย่างไรสำหรับเทียร์นั้น"

ตามเทียร์ขีดจำกัดอัตราที่ Anthropic เผยแพร่ (ย้ำอีกครั้งว่าโปรดยืนยันของคุณใน Console เนื่องจากข้อตกลงแบบกำหนดเองและระดับองค์กรจะแตกต่างกัน) แถวของ Fable 5 จะปรับขนาดโดยประมาณดังนี้:

• เทียร์ 1: 50 RPM, 100,000 ITPM, 20,000 OTPM.
• เทียร์ 2: 1,000 RPM, 500,000 ITPM, 100,000 OTPM.
• เทียร์ 3: 2,000 RPM, 1,500,000 ITPM, 300,000 OTPM.
• เทียร์ 4: 4,000 RPM, 4,000,000 ITPM, 800,000 OTPM.

ถือว่าสิ่งเหล่านี้เป็นรูปแบบของระบบ ไม่ใช่สัญญา Anthropic จะอัปเดตตาราง ข้อตกลง Priority Tier และข้อตกลงระดับองค์กรจะเปลี่ยนแปลงภาพรวม และ Console ของคุณคือแหล่งข้อมูลที่แท้จริง หากตัวเลขในที่นี้ไม่ตรงกับสิ่งที่บัญชีของคุณแสดง โปรดเชื่อบัญชีของคุณ

มิติที่กระทบ Fable 5 มากที่สุดคือ OTPM Fable 5 ถูกสร้างขึ้นสำหรับงานที่ต้องการโทเค็นจำนวนหลายล้าน งานที่มีขอบเขตเวลานาน ประเภทของการทำงานที่เอเจนต์ต้องประมวลผลงานขนาดใหญ่และสร้างผลลัพธ์จำนวนมากไปพร้อมกัน การสร้างผลลัพธ์ที่ยาวนานไม่ได้ใช้ OTPM เป็นก้อนใหญ่ตั้งแต่เริ่มต้น แต่จะค่อยๆ ดึงงบประมาณเอาต์พุตของคุณลงมาอย่างต่อเนื่องในขณะที่มันสตรีม ดังนั้นงาน Fable 5 ที่ทะเยอทะยานเพียงงานเดียวสามารถอยู่ใกล้เพดาน OTPM ของคุณได้เป็นระยะเวลานาน และหากคุณเรียกใช้งานหลายงานพร้อมกัน OTPM มักจะเป็นกำแพงแรกที่คุณชน ไม่ใช่ RPM มีสองพฤติกรรมที่ตามมา: กำหนด max_tokens ให้เหมาะสม เพื่อไม่ให้การสร้างผลลัพธ์ที่ควบคุมไม่ได้ขยายตัว และสตรีมผลลัพธ์ที่ยาวนาน เพื่อที่คุณจะได้ไม่ต้องถือการเชื่อมต่อเปิดรอการตอบกลับขนาดใหญ่ที่ไม่ได้สตรีม (ซึ่งจะช่วยให้คุณหลีกเลี่ยงการหมดเวลาของคำขอด้วย) หากคุณกำลังเชื่อมต่อโมเดลเป็นครั้งแรก คู่มือ API ของ Claude Fable 5 จะอธิบายรูปร่างของคำขอที่ขีดจำกัดเหล่านี้ใช้

การอ่านและตรวจสอบขีดจำกัดของคุณ

อย่าคาดเดาขีดจำกัดของคุณจากโพสต์บล็อก รวมถึงบทความนี้ด้วย มีสองวิธีที่เชื่อถือได้ในการดูตัวเลขจริง

วิธีแรกคือ Anthropic Console หน้า Limits ใต้การตั้งค่าจะแสดงเทียร์ปัจจุบันขององค์กรของคุณและขีดจำกัดอัตราต่อโมเดลที่บังคับใช้ และหน้า Usage จะแสดงอัตราโทเค็นอินพุตและเอาต์พุตจริงของคุณเมื่อเวลาผ่านไปเทียบกับเพดาน รวมถึงอัตราการเข้าถึงแคชของคุณ แผนภูมิเหล่านี้เป็นวิธีที่เร็วที่สุดในการตอบคำถามที่ว่า "ฉันมีพื้นที่ว่างเพียงพอหรือไม่ หรือกำลังจะชนขีดจำกัดแล้ว" ก่อนที่คุณจะเพิ่มปริมาณการส่งข้อมูล

วิธีที่สองคือเฮดเดอร์การตอบกลับในการเรียก API ทุกครั้ง Anthropic จะส่งชุดเฮดเดอร์ anthropic-ratelimit-* ที่บอกสถานะของคุณในขณะนั้นอย่างแม่นยำ:

• anthropic-ratelimit-requests-limit และ anthropic-ratelimit-requests-remaining สำหรับ RPM
• anthropic-ratelimit-input-tokens-limit และ anthropic-ratelimit-input-tokens-remaining สำหรับ ITPM
• anthropic-ratelimit-output-tokens-limit และ anthropic-ratelimit-output-tokens-remaining สำหรับ OTPM
• เฮดเดอร์ *-reset ที่ตรงกันสำหรับแต่ละรายการ ในรูปแบบ RFC 3339 ซึ่งบอกคุณว่าบัคเก็ตนั้นจะเติมเต็มเมื่อใด

เฮดเดอร์โทเค็นที่เหลือจะถูกปัดเศษเป็นหลักพันที่ใกล้ที่สุด และเฮดเดอร์โทเค็นแบบรวมจะรายงานขีดจำกัดที่เข้มงวดที่สุดในขณะนี้ (เช่น ขีดจำกัดระดับพื้นที่ทำงานหากคุณได้ตั้งค่าไว้) การอ่าน *-remaining ในทุกการตอบกลับช่วยให้ไคลเอ็นต์ของคุณสามารถชะลอตัวเองได้ก่อนที่จะเกิดข้อผิดพลาด 429 ซึ่งเป็นความแตกต่างระหว่างการใช้ backpressure อย่างราบรื่นและการเกิดข้อผิดพลาดจำนวนมาก

การจัดการ 429 อย่างราบรื่น

การตอบสนอง 429 หมายความว่าคุณถึงขีดจำกัดข้อใดข้อหนึ่ง เนื้อหาจะบอกคุณว่าเกิดจากข้อใด และที่สำคัญ การตอบสนองจะมีเฮดเดอร์ retry-after พร้อมจำนวนวินาทีที่ต้องรอก่อนที่จะลองใหม่อีกครั้ง การลองใหม่ก่อนเวลาที่ retry-after ระบุไว้จะล้มเหลวอีกครั้ง ดังนั้นโปรดปฏิบัติตาม

ข่าวดีก็คือ SDK อย่างเป็นทางการได้ทำสิ่งที่ถูกต้องอยู่แล้ว Anthropic SDK จะพยายามใหม่สำหรับข้อผิดพลาด 429 และ 5xx โดยอัตโนมัติด้วย exponential backoff (โดยค่าเริ่มต้นคือ 2 ครั้ง) โดยจะอ่าน retry-after เพื่อกำหนดเวลาในการพยายามแต่ละครั้ง สำหรับแอปพลิเคชันส่วนใหญ่ พฤติกรรมที่สร้างมาให้ในตัวนี้ก็เพียงพอแล้ว และคุณไม่ควรสร้าง loop การพยายามใหม่ด้วยตนเอง เว้นแต่คุณต้องการสิ่งที่ SDK ไม่มีให้ นี่คือการเรียกพื้นฐานด้วย Fable 5:

import anthropic

client = anthropic.Anthropic()  # อ่าน ANTHROPIC_API_KEY จาก environment

# เพิ่ม max_retries เหนือค่าเริ่มต้น 2 สำหรับงานแบตช์ที่มีแนวโน้มเกิด 429
resilient = client.with_options(max_retries=5)

message = resilient.messages.create(
    model="claude-fable-5",
    max_tokens=4096,
    messages=[
        {"role": "user", "content": "Draft a release summary for our June changelog."}
    ],
)

print(message.content[0].text)

หากคุณต้องการการควบคุมที่ชัดเจน เช่น เพื่อแสดงสถานะ "เรากำลังยุ่ง ลองใหม่อีกครั้ง" ใน UI ของคุณเอง คุณสามารถจับข้อยกเว้นประเภท (typed exception) และอ่านเฮดเดอร์ได้ด้วยตนเอง:

import anthropic

client = anthropic.Anthropic()

try:
    message = client.messages.create(
        model="claude-fable-5",
        max_tokens=4096,
        messages=[{"role": "user", "content": "Summarize this incident report."}],
    )
except anthropic.RateLimitError as exc:
    wait_seconds = int(exc.response.headers.get("retry-after", "60"))
    print(f"Rate limited. Backing off for {wait_seconds}s before retry.")

นอกเหนือจากการลองใหม่แล้ว วิธีแก้ไขที่ยั่งยืนสำหรับแรงกดดันอย่างต่อเนื่องคือการจัดคิว หากการส่งข้อมูลของคุณไม่สม่ำเสมอ ให้ใส่คำขอลงในคิวและระบายออกในอัตราที่เทียร์ของคุณสามารถรองรับได้ โดยใช้เฮดเดอร์ anthropic-ratelimit-*-remaining เพื่อกำหนดจังหวะการระบายออก นั่นจะเปลี่ยนกำแพงของ 429 ให้กลายเป็นไปป์ไลน์ที่ราบรื่นและช้าลงเล็กน้อย ซึ่งเกือบจะเป็นสิ่งที่คุณต้องการเสมอ การควบคุมการชะลอและจัดคิวแบบเดียวกันนี้ปรากฏขึ้นเมื่อคุณทดสอบ API ที่มีขีดจำกัดอัตราใดๆ และรูปแบบใน การทดสอบ ChatGPT API ด้วย Apidog สามารถนำไปใช้กับงาน Claude ได้โดยตรง

การเพิ่มขีดจำกัดและลดแรงกดดันของคุณ

เมื่อคุณชนขีดจำกัดบ่อยครั้ง คุณมีสองทางเลือก: เพิ่มขีดจำกัด หรือลดความต้องการ

หากต้องการเพิ่มขีดจำกัด ให้เลื่อนเทียร์ของคุณ เนื่องจากเทียร์จะเลื่อนขึ้นตามการซื้อเครดิตสะสม การใช้งานจริงอย่างสม่ำเสมอจะดันคุณขึ้นสู่ตารางโดยอัตโนมัติ และแต่ละขั้นจะเพิ่ม RPM, ITPM และ OTPM อย่างมีนัยสำคัญ หากคุณต้องการข้ามกำหนดการอัตโนมัติ หรือต้องการขีดจำกัดแบบกำหนดเองหรือระดับองค์กร โปรดติดต่อฝ่ายขายผ่านหน้า Limits ใน Console; Priority Tier และการเรียกเก็บเงินรายเดือนมีไว้สำหรับเวิร์กโหลดที่มีปริมาณมากและมีความมุ่งมั่นโดยเฉพาะ

หากต้องการลดความต้องการขีดจำกัด ให้โจมตีปริมาณงานของโทเค็นโดยตรง:

• ใช้ Batches API สำหรับงานที่ไม่ไวต่อเวลาแฝง มันจะประมวลผลคำขอ Messages API แบบอะซิงโครนัสโดยมีค่าใช้จ่ายประมาณ 50 เปอร์เซ็นต์ของค่าใช้จ่ายมาตรฐาน และมีพูลขีดจำกัดอัตราแยกต่างหาก ดังนั้นจึงป้องกันไม่ให้งานจำนวนมากแข่งขันกับการส่งข้อมูลแบบเรียลไทม์และการโต้ตอบของคุณ
• เปิดใช้งานการแคชพร้อมต์สำหรับบริบทที่ใช้ซ้ำ เนื่องจากโทเค็นอินพุตที่แคชโดยทั่วไปจะไม่นับรวมใน ITPM การแคชพร้อมต์ระบบขนาดใหญ่ ชุดเครื่องมือ หรือเอกสารอ้างอิงในชุด Fable 5 สามารถเพิ่มปริมาณงานอินพุตที่มีประสิทธิภาพของคุณได้โดยไม่ต้องแตะเทียร์ของคุณ ตรวจสอบอัตราการเข้าถึงแคชของคุณในหน้า Usage เพื่อยืนยันว่ามันทำงานได้ดี
• ปรับขนาด max_tokens ให้เหมาะสม ไม่มีค่าปรับ OTPM สำหรับการตั้งค่าสูงสุดที่สูง แต่ max_tokens ที่กว้างขวางช่วยให้การตอบสนองครั้งเดียวทำงานได้ยาวนานและใช้ OTPM ได้นานขึ้น ตั้งค่าให้ตรงกับสิ่งที่งานต้องการจริง
• สตรีมผลลัพธ์ที่ยาวนาน การสตรีมช่วยป้องกันคุณจากการหมดเวลาของคำขอในการสร้างผลลัพธ์ขนาดใหญ่ และช่วยให้คุณดูผลลัพธ์สะสมแบบเรียลไทม์ ซึ่งเข้ากันได้ดีกับการอ่านเฮดเดอร์ OTPM

เทคนิคเหล่านี้จะเสริมซึ่งกันและกัน ไปป์ไลน์ Fable 5 ที่มีการแคช, จัดเป็นชุด, และสตรีมได้ดี สามารถทำงานได้มากกว่าไปป์ไลน์ที่เรียบง่าย ภายใต้เทียร์เดียวกัน สำหรับเวิร์กโหลดสไตล์เอเจนต์โดยเฉพาะ การเดินชม Claude Fable 5 agent แสดงให้เห็นว่าเครื่องมือเหล่านี้เข้ากับลูปที่ทำงานนานได้อย่างไร และหากคุณกำลังเปรียบเทียบคลาสโมเดลสำหรับงานที่ไวต่อปริมาณงาน คู่มือ API ของ Claude Opus 4.8 และ บันทึกราคา Opus 4.8 เป็นข้อมูลอ้างอิงที่มีประโยชน์ เนื่องจากแต่ละคลาสโมเดลมีบัคเก็ตขีดจำกัดแยกต่างหาก

ตรวจสอบการใช้งาน Fable 5 ของคุณด้วย Apidog

วิธีที่ชัดเจนที่สุดในการทำความเข้าใจขีดจำกัดที่แท้จริงของคุณคือการดูขีดจำกัดเหล่านั้นบนคำขอสด และ API client ทำให้สิ่งนั้นเป็นรูปธรรม ด้วย Apidog คุณสามารถสร้างคำขอ Fable 5 ต่อ Messages API ส่ง และตรวจสอบการตอบกลับทั้งหมด รวมถึงเฮดเดอร์ anthropic-ratelimit-* และอ็อบเจกต์ usage ที่รายงานจำนวนโทเค็นอินพุต เอาต์พุต และแคชสำหรับคำขอเหล่านั้น การเห็นตัวเลขเหล่านี้เคียงข้างกัน คำขอแล้วคำขอ จะบอกคุณว่าคุณใกล้จะถึง ITPM และ OTPM แค่ไหน และการแคชช่วยคุณประหยัดได้มากเพียงใด โดยไม่ต้องรอให้เกิด 429 เพื่อหาคำตอบ

ลูปที่ใช้งานได้จริงในขณะที่คุณกำลังสร้าง: ส่งพร้อมต์ Fable 5 ที่เป็นตัวแทนใน Apidog อ่านค่า anthropic-ratelimit-output-tokens-remaining และ usage.output_tokens จากการตอบกลับ และสังเกตว่าการสร้างผลลัพธ์ที่ยาวนานทำให้จำนวนที่เหลือลดลงเร็วแค่ไหน จากนั้นเพิ่มพร้อมต์ระบบที่แคช ส่งอีกครั้ง และยืนยันว่า usage.cache_read_input_tokens เพิ่มขึ้น ในขณะที่การใช้ ITPM ของคุณแทบไม่เปลี่ยนแปลง การเปรียบเทียบสองคำขอนี้จะเปลี่ยนตารางเทียร์ที่เป็นนามธรรมให้กลายเป็นความรู้สึกถึงขีดจำกัดของคุณเอง คุณยังสามารถบันทึกคำขอ เปลี่ยนแปลง max_tokens และดูว่าการใช้ OTPM ติดตามผลลัพธ์จริงอย่างไร แทนที่จะเป็นเพดาน ซึ่งเป็นวิธีที่เร็วที่สุดในการทำให้คุณมั่นใจว่า max_tokens ที่สูงนั้นปลอดภัย ดาวน์โหลด Apidog หากคุณต้องการทำการทดลองนั้นด้วยคีย์ของคุณเอง และจับตาดูเฮดเดอร์การตอบกลับในขณะที่คุณปรับอัตราคำขอของคุณ ทีมที่ใช้ Apidog เป็นมาตรฐานสำหรับการออกแบบและทดสอบ API อยู่แล้วสามารถรวมการตรวจสอบ Fable 5 เข้ากับพื้นที่ทำงานเดียวกันที่พวกเขาใช้สำหรับทุกอย่าง