Anthropic ยกเพดาน rate limit ของ Claude API — Sonnet กับ Haiku ได้ลิมิตเท่า Opus ทุกระดับ พร้อมยุบ tier เหลือ 3 ชั้น Start/Build/Scale

เมื่อ 26 มิถุนายน 2026 Anthropic ปรับโครงสร้าง rate limit ของ Claude API ใหม่ โดยจุดสำคัญคือ throughput ของ Claude Sonnet และ Haiku ถูกยกขึ้นมาให้เท่ากับ Claude Opus ในทุกระดับการใช้งาน (tier) — แปลว่าการเลือกใช้โมเดลที่ถูกกว่าจะไม่มี “ค่าปรับด้านความเร็ว” อีกต่อไป พร้อมกันนั้นบริษัทยัง ยุบระบบ tier ให้เหลือ 3 ชั้น คือ Start, Build และ Scale

Anthropic ระบุชัดว่า ไม่มีองค์กรไหนได้ลิมิตต่ำลงกว่าเดิม องค์กรส่วนใหญ่ขยับขึ้น tier สูงขึ้น และไม่ต้องทำอะไรเพิ่ม การเปลี่ยนแปลงมีผลอัตโนมัติ โดยรายละเอียดลิมิตของแต่ละ tier ดูได้ใน Claude Console

ทำไม “Sonnet/Haiku เท่า Opus” ถึงสำคัญกับนักพัฒนา

ก่อนหน้านี้โมเดลระดับต่างกันมักมาพร้อมเพดาน throughput (tokens-per-minute / requests-per-minute) ต่างกัน ทำให้ทีมที่อยากประหยัดต้นทุนด้วยการใช้ Claude Haiku 4.5 หรือ Claude Sonnet 4.6 ในงานปริมาณมาก ต้องแลกกับเพดานความเร็วที่ต่ำกว่า การยกลิมิตให้เท่ากันหมายความว่า การตัดสินใจเลือกโมเดลกลับมาอยู่บนพื้นฐานของ “งานนี้ต้องใช้ความฉลาดแค่ไหน” ล้วน ๆ ไม่ใช่ “โมเดลถูกแต่ยิงได้ช้ากว่า”

ตัวเลขจากตารางลิมิตทางการยืนยันเรื่องนี้ชัดเจน — Opus 4.x, Sonnet 4.x และ Haiku 4.5 มีเพดานเท่ากันเป๊ะในทุก tier: ระดับ Start อยู่ที่ 1,000 RPM / 2,000,000 input tokens ต่อนาที (ITPM) / 400,000 output tokens ต่อนาที (OTPM), ระดับ Build ขยับเป็น 5,000 RPM / 5M ITPM / 1M OTPM และระดับ Scale สูงสุดที่ 10,000 RPM / 10M ITPM / 2M OTPM (โมเดล Fable 5 ยังมีเพดานแยกต่ำกว่าเล็กน้อย)

ผลที่ตามมาตรง ๆ คืองานสาย agentic และ high-volume — เช่น batch classification, การประมวลผลเอกสารจำนวนมาก, หรือ agent ที่ยิง API ถี่ ๆ — ออกแบบสถาปัตยกรรมต้นทุน/ความเร็วได้ยืดหยุ่นขึ้น ทีมสามารถดัน Haiku/Sonnet ในเลเยอร์ที่กินปริมาณสูงโดยไม่ชนเพดานเร็วเกินไป แล้วสำรอง Opus ไว้เฉพาะจุดที่ต้องการเหตุผลซับซ้อนจริง ๆ อีกจุดที่ช่วยดัน throughput จริงคือ โทเคนที่อ่านจาก prompt cache ไม่ถูกนับรวมใน ITPM (สำหรับโมเดลส่วนใหญ่) ฉะนั้นการแคชพรอมป์ต์ที่ใช้ซ้ำจึงเพิ่มปริมาณงานที่ทำได้จริงต่อนาทีโดยไม่ต้องขอลิมิตเพิ่ม

ยุบ tier เหลือ Start / Build / Scale

การลดความซับซ้อนของระบบ tier ลงเหลือสามชั้นช่วยให้ทีมคาดเดาเส้นทางการสเกลได้ง่ายขึ้น — จากเริ่มต้นทดลอง (Start) ไปสู่การสร้างจริง (Build) และการขยายปริมาณงานระดับโปรดักชัน (Scale) แทนที่จะต้องไล่ไต่หลายชั้นแบบเดิม โครงสร้างที่กระชับนี้สอดคล้องกับทิศทางของแพลตฟอร์มที่พยายามทำให้เส้นทางจาก prototype ไป production ราบรื่นขึ้นสำหรับนักพัฒนา

มุมมอง AI Curator

ในมุมหนึ่ง นี่เป็นการเปลี่ยนแปลงเชิง “นโยบายลิมิต” ที่ฟังดูไม่หวือหวา แต่ในทางปฏิบัติมันสะท้อนการแข่งขันที่ลึกกว่านั้น — เมื่อช่องว่างคุณภาพระหว่างโมเดลแคบลง สนามรบจริงย้ายมาที่ต้นทุนต่อโทเคนและ throughput การที่ Anthropic ยก Sonnet/Haiku ขึ้นเทียบ Opus ด้านความเร็ว เท่ากับลดแรงเสียดทานในการเลือกโมเดลถูกลง ซึ่งเป็นประโยชน์โดยตรงต่อทีมที่คุมงบ และกดดันให้คู่แข่งต้องตอบด้วยข้อเสนอที่ดึงดูดพอกัน นี่ต่อเนื่องจากเทรนด์ที่บล็อกเราเห็นมาตลอด — ทั้ง DSpark ของ DeepSeek ที่เร่ง inference และดีลฮาร์ดแวร์ inference ของหลายค่าย ล้วนชี้ไปที่สงคราม “เสิร์ฟโมเดลให้ถูกและเร็วกว่า”

สำหรับทีมไทย/SEA ที่สร้างบน Claude API บทเรียนเชิงปฏิบัติคือ ถึงเวลาทบทวนสถาปัตยกรรมการเลือกโมเดลอีกครั้ง — งานที่เคยถูกบีบให้ใช้ Opus เพราะกลัวชนเพดานของ Sonnet/Haiku อาจย้ายลงมาใช้โมเดลถูกกว่าได้แล้วโดยไม่เสียความเร็ว ช่วยลดต้นทุน API ลงอย่างมีนัยสำคัญในงานปริมาณมาก ข้อควรระวังคืออย่าลืมว่า rate limit ที่สูงขึ้นไม่ได้แปลว่าคุณภาพเท่ากัน — Haiku ยังเป็นโมเดลเล็กที่เหมาะกับงานง่าย การย้ายโมเดลควรวัดผลคุณภาพจริงควบคู่ไปด้วย ไม่ใช่ย้ายเพราะลิมิตเปิดกว้างขึ้นเพียงอย่างเดียว

แหล่งข่าว:

• Rate limits — Anthropic Claude API documentation (ตาราง Start/Build/Scale ที่ Opus, Sonnet, Haiku ลิมิตเท่ากัน)
• Claude Developer Platform — rate limits update (26 มิ.ย. 2026) — Releasebot