HTTP 429 หมายความว่าอะไร เมื่อ coding agent ของคุณชนกำแพง

ไม่ค่อยมีอะไรหยุดโมเมนตัมได้เท่าเอเจนต์หยุดกลางงานพร้อมเลข 429 สีแดง มันดูเหมือนความล้มเหลว แต่จริงๆ ไม่ใช่ — มันคือผู้ให้บริการกำลังบอกว่า ยังไม่ใช่ตอนนี้ และการรู้ว่าคำนั้นหมายความว่าอย่างไร จะบอกคุณเองว่าขั้นถัดไปต้องทำอะไร ลิมิตอัตราการใช้งานคือระบบท่อของทุก setup เขียนโค้ดด้วย AI และเอเจนต์ไปชนมันบ่อยกว่าผู้ใช้แชทมาก ด้วยเหตุผลเชิงโครงสร้างที่ควรทำความเข้าใจไว้ก่อนที่คุณจะเป็นคนที่กำลังจ้องข้อผิดพลาดนั้นเสียเอง

429 กำลังบอกอะไรจริงๆ

HTTP 429 Too Many Requests หมายความว่าเซิร์ฟเวอร์ได้รับและเข้าใจคำขอของคุณแล้ว แต่ปฏิเสธที่จะประมวลผล — เพราะโควตาถูกใช้เกินไปแล้ว ที่สำคัญคือมันถูกออกแบบให้เป็นชั่วคราว: การตอบกลับมักมีคำใบ้ Retry-After บอกว่าให้กลับมาเมื่อไร นี่คือสิ่งที่แยกมันออกจากเพื่อนบ้านในตระกูลข้อผิดพลาด 401 หรือ 403 หมายถึงการยืนยันตัวตนหรือสิทธิ์ ซึ่งลองใหม่ก็ไม่ช่วย 402 ชี้ไปที่การเรียกเก็บเงิน ส่วน 5xx คือปัญหาของผู้ให้บริการเอง แต่ 429 เป็นปัญหาของคุณ และแก้ไขได้

ทำไมเอเจนต์ถึงชนลิมิตบ่อยกว่าแชท

การสนทนาในแชทหนึ่งครั้งคือคำขอหนึ่งหรือสองคำขอ แต่เทิร์นของเอเจนต์หนึ่งเทิร์นคือหลายสิบคำขอ: อ่านไฟล์ ค้นหา แก้ไข รันเทสต์ ตอบสนองต่อผลลัพธ์ — แต่ละขั้นคือ API call ใหม่ที่แบกคอนเท็กซ์ซึ่งงอกขึ้นเรื่อยๆ ไปด้วย เพดานที่ต้องระวังมีสามตัวแยกกัน: คำขอต่อนาที โทเคนต่อนาที และการเชื่อมต่อพร้อมกัน เอเจนต์มักจะใช้โควตาโทเคนต่อนาทีหมดก่อน เพราะทุกคำขอล้วนขนคอนเท็กซ์หลายพันโทเคนไปด้วยทั้งนั้น ส่วนแพลนแบบสมาชิกยังซ้อนเพดานการใช้งานอย่างเป็นธรรม (fair-use) เพิ่มเข้ามาอีกชั้น — โควตารายวันหรือรายสัปดาห์ — ซึ่งอาจโผล่มาเป็นคำเตือนการใช้งานแทนที่จะเป็นคำตอบ 429 สะอาดๆ ทำให้หลายคนงงในครั้งแรก

ตอบสนองอย่างแรก: ถอยให้ถูกวิธี

ถ้ามี header Retry-After ก็ทำตามนั้น ถ้าไม่มีให้ลองใหม่ด้วย exponential backoff บวก jitter — รอหนึ่งวินาที แล้วสอง สี่ แล้วแปด การกดส่งซ้ำรัวๆ ทำให้แย่ลง: คำขอที่ซ้ำๆ อาจยืดช่วง throttle ให้ยาวออกไป และพายุ retry ด้วยมือจากหลาย pane ที่เปิดอยู่จะคูณปัญหาเล็กให้กลายเป็นปัญหาใหญ่ และต้องหาให้ได้ด้วยว่าลิมิตตัวไหนที่สะดุด โควตาของบัญชีคุณเองกับความแออัดฝั่งผู้ให้บริการมีพฤติกรรมต่างกันมาก และการแยกแยะสองอย่างนี้ออกจะช่วยให้คุณไม่ต้องเสียเวลาหนึ่งชั่วโมงไปโทษตัวเองกับเรื่องที่จริงๆ แล้วเป็นชั่วโมงเร่งด่วนของคนอื่น

การแก้เชิงโครงสร้าง: ใช้น้อยลง กระจายให้กว้างขึ้น

การแก้ที่ยั่งยืนคือการลดดีมานด์ ไม่ใช่การหลบมัน ตัดคอนเท็กซ์ให้บาง: ชี้เอเจนต์ไปที่ไฟล์ที่เกี่ยวข้องสามไฟล์ย่อดีกว่าก๊อปครึ่งรีโปมาวาง เมื่อใกล้เพดาน ให้รันงานยาวงานเดียวแทนการเปิดหกเซสชันขนานกัน รวมการแก้ไขที่เกี่ยวข้องเข้าเป็นเทิร์นเดียวที่ระบุสิ่งที่ต้องการให้ชัด แทนการค่อยๆ หยอดคำสั่งทีละนิด ดันงาน bulk ข้ามคืนไปไว้ช่วงนอกพีค แบ่งพายไลน์ออกเพื่อให้โมเดลที่ถูกกว่าจัดการขั้นประจำ และเก็บโมเดลพรีเมียมไว้ใช้กับการตัดสินใจ ถ้าคุณสลับไปมาระหว่างผู้ให้บริการอยู่แล้ว การเปรียบเทียบต้นทุน coding agent ใช้เป็นแผนที่คร่าวๆ ของราคาและประสิทธิภาพได้ในตัว และการรู้ว่า Claude, GPT และ Gemini ต่างกันอย่างไรสำหรับการเขียนโค้ด จะช่วยให้คุณเลือกผู้ให้บริการสำรองที่สมเหตุสมผลได้ก่อนจะถึงตอนที่จำเป็นเร่งด่วน

เมื่อ 429 เกิดซ้ำแล้วซ้ำเล่า

การระเบิดเป็นครั้งคราวในชั่วโมงพีคคือสภาพอากาศ แต่รูปแบบที่เกิดทุกวันอย่างต่อเนื่องคือสภาพภูมิอากาศ ถ้าคุณชนลิมิตทุกวัน แปลว่าคุณโตเกินแพลนหรือผู้ให้บริการไปแล้ว — ขยับเพดานขึ้น ย้ายไปแพลนระดับสูงกว่า หรือย้ายบางเวิร์กโหลดไปที่อื่นถาวร คอยสังเกตด้วยว่างานไหนเป็นตัวจุดชนวน: ถ้าเป็นงานรีแฟกเตอร์ใหญ่ๆ เสมอ นั่นคือปัญหาขนาดคอนเท็กซ์ที่สวมชุดคอสตูมลิมิตอัตราการใช้งานอยู่ และการลดสิ่งที่คุณส่งออกไปจะแก้ได้มากกว่าการอัปเกรดแพลน

มุมของ meshcode

เพราะ meshcode ให้แต่ละ pane ชี้ไปที่แบ็กเอนด์ของตัวเองได้ 429 จากผู้ให้บริการหนึ่งจึงกลายเป็นการตัดสินใจเรื่อง routing แทนที่จะเป็นการหยุดชะงัก: ย้ายงานที่ติดไปโมเดลอื่น ให้งานอื่นๆ ทำงานต่อไป แล้วสลับกลับมาเมื่อหน้าต่างเคลียร์แล้ว พกคีย์ของคุณมาเอง แล้วแผน fallback ก็เป็นของคุณที่จะจัดการ ไม่ใช่ของแพลตฟอร์ม

👉 ดาวน์โหลด meshcode — Mac, Windows