Claude API แจ้ง Rate Limit เกินกำหนด แก้อย่างไร

ถ้า Claude API ตอบ 429 rate_limit_error อย่าเพิ่งส่งคำขอซ้ำรัว ๆ ให้ตรวจว่าเกินจำนวน Request, ปริมาณ Input token, Output token หรือ Spend limit เพราะแต่ละกรณีใช้วิธีแก้ต่างกัน

❶ ตรวจว่าเกินขีดจำกัดประเภทใด

Claude API วัด Rate limit ของ Messages API ตามจำนวนคำขอต่อนาที (RPM), Input token ต่อนาที (ITPM) และ Output token ต่อนาที (OTPM) หากเกินอย่างใดอย่างหนึ่งก็อาจได้รับ 429

อ่านข้อความใน error.message และตรวจ Response headers เพื่อดูว่า Limit ใดเต็ม โดยขีดจำกัดจริงขึ้นอยู่กับ Organization, Workspace, รุ่นโมเดล และ Usage tier

❷ อ่าน retry-after ก่อนลองใหม่

ถ้า Response มี Header retry-after ให้รอตามจำนวนวินาทีที่ระบุก่อนส่ง Request ใหม่ การลองก่อนครบเวลามีโอกาสได้รับ 429 ซ้ำ

หากใช้ SDK ทางการ โดยปกติ SDK จะลองใหม่สำหรับความผิดพลาดชั่วคราวด้วย Exponential backoff และเคารพ retry-after เมื่อมี Header นี้ ควรตรวจจำนวน Retry ของระบบเพิ่มเติม เพื่อไม่ให้แอปและ SDK ส่งซ้ำซ้อนกัน

❸ ลดการส่งคำขอเป็นชุดถี่เกินไป

Rate limit ใช้ Token bucket จึงอาจถูกชนได้จากการส่งคำขอเป็นก้อน แม้ค่าเฉลี่ยต่อนาทีจะดูไม่สูงเกินไป ลองปรับระบบให้:

  1. จำกัดจำนวน Request ที่ทำงานพร้อมกัน
  2. ใส่คิวและทยอยส่งคำขอ
  3. เว้นช่วงระหว่างคำขอ แทนการยิงเป็น Burst
  4. ใช้ Exponential backoff พร้อมสุ่มช่วงเวลารอเล็กน้อยเมื่อระบบลองใหม่
  5. หลีกเลี่ยงการ Retry ทั้งชุดทันทีเมื่อมีบาง Request ล้มเหลว

❹ ลดการใช้ Input และ Output token

ถ้าเกิน ITPM ให้ลดข้อความหรือข้อมูลที่ส่งในแต่ละ Request ตัดบริบทซ้ำที่ไม่จำเป็น และใช้ Prompt caching กับเนื้อหาที่นำกลับมาใช้ซ้ำ เช่น System prompt หรือเอกสารอ้างอิง

ถ้าเกิน OTPM ให้ลดปริมาณคำตอบที่ต้องสร้างหรือแบ่งงานให้สั้นลง สำหรับโมเดลส่วนใหญ่ ค่า max_tokens ไม่ได้ถูกนับเป็น Output token ที่ใช้จริงใน Rate limit; ระบบนับ Token ที่สร้างออกมาจริง

❺ ตรวจว่าเป็น Spend cap แทน Rate limit หรือไม่

429 อาจเกิดจาก Organization ถึง Spend cap รายเดือน ไม่ใช่เพราะส่งคำขอถี่เกินไป ให้ตรวจข้อความ Error และ error.details.error_code หากเป็น enforced_spend_limit_reached การ Retry จะยังล้มเหลวจนกว่าจะมีการคืนสิทธิ์ใช้งานหรือเพิ่มขีดจำกัด

กรณี Spend cap มักไม่มี retry-after ให้ตรวจหน้า Billing และ Rate limits ใน Claude Console หากเป็น Spend limit ที่องค์กรตั้งเอง ให้ผู้ดูแลตรวจหรือปรับ Limit ตามนโยบาย

❻ ตรวจ Response headers และ Usage

Response headers ช่วยแสดงขีดจำกัดและเวลาที่จะฟื้นตัว ค่าที่ควรดู ได้แก่:

  • retry-after — เวลาที่ควรรอก่อนลองใหม่
  • anthropic-ratelimit-requests-remaining — จำนวน Request ที่ยังเหลือ
  • anthropic-ratelimit-requests-reset — เวลาที่ Request limit จะเติมกลับ
  • anthropic-ratelimit-input-tokens-remaining — Input token ที่ยังเหลือ
  • anthropic-ratelimit-output-tokens-remaining — Output token ที่ยังเหลือ
  • Header ที่ลงท้ายด้วย -reset — เวลาที่ขีดจำกัดนั้นจะเติมกลับ

ตรวจกราฟ Rate limit และ Usage ใน Claude Console เพื่อดูช่วงเวลาที่ระบบชนเพดาน และตรวจ Workspace ID หากต้องแยกว่าคำขอถูกนับกับ Workspace ใด

ComSiam แนะนำให้บันทึก Status, Error message, Request ID และ Headers ที่เกี่ยวข้องไว้ โดยลบ API key และข้อมูลลับออกก่อนส่งต่อให้ทีมตรวจสอบ

❼ ขอเพิ่ม Rate limit เมื่อปรับระบบแล้วก็ยังไม่พอ

หากลด Burst, จำกัดจำนวนงานพร้อมกัน และปรับการใช้ Token แล้ว แต่ปริมาณงานที่จำเป็นยังสูงกว่าขีดจำกัด ให้ตรวจหน้า Rate limits ใน Claude Console เพื่อดู tier และวงเงินปัจจุบัน จากนั้นส่งคำขอเพิ่ม Limit ผ่านตัวเลือก Request tier increase หากมี

การเพิ่ม Rate limit กับการเพิ่ม Spend cap เป็นคนละเรื่อง ควรตรวจว่าความต้องการคือเพิ่มจำนวนคำขอ/Token ต่อช่วงเวลา หรือเพิ่มงบใช้จ่ายรายเดือน

❽ คำถามที่พบบ่อย

429 หมายถึงส่ง Request ถี่เกินไปเสมอหรือไม่?

ไม่เสมอไป อาจเกิดจาก RPM, ITPM, OTPM หรือ Spend cap รายเดือน ให้ตรวจข้อความ Error, Header และข้อมูล Usage ประกอบกัน

ถ้ามี retry-after ควรทำอย่างไร?

รอตามเวลาที่ระบุ ก่อนส่งคำขอใหม่ การลองก่อนกำหนดอาจถูกปฏิเสธอีก

retry-after ไม่มี แปลว่าอะไร?

อาจเป็น 429 จาก Spend cap ซึ่งไม่หายด้วยการรอช่วงสั้น ๆ ให้ตรวจ error.details.error_code และหน้า Billing หรือ Spend limits ใน Console

การใช้ Prompt caching ช่วยลด Rate limit ได้ไหม?

อาจช่วยลด Input token ที่นับต่อคำขอสำหรับโมเดลส่วนใหญ่ เมื่อมีบริบทซ้ำที่นำกลับมาใช้ได้ ควรตรวจ Usage และ Cache rate ใน Console เพื่อดูผลจริง

❾ สรุปวิธีแก้ Claude API Rate Limit

เริ่มจากแยกว่าเกิน RPM, ITPM, OTPM หรือ Spend cap อ่าน retry-after และ Rate limit headers ก่อน Retry จากนั้นปรับระบบส่งงานให้ไม่เป็น Burst ลดบริบทซ้ำ และใช้คิวกับ Backoff เมื่อจำเป็น

หาก Spend cap เต็ม ให้ตรวจ Billing ส่วนการเพิ่ม Rate limit ให้ดูหน้า Rate limits ใน Claude Console ComSiam แนะนำให้ติดตาม Usage และ Request ID เพื่อรู้ว่า Limit ใดเป็นคอขวดก่อนปรับระบบหรือยื่นขอเพิ่มวงเงิน