Catatan penulis: Saat menemui 429, tidak perlu langsung mengganti model. Artikel ini memakai 3 langkah pemeriksaan untuk menentukan apakah pembatasan laju berasal dari penyedia upstream, gateway, atau paket gratis, sekaligus memberikan cara konfigurasi exponential backoff, Retry-After, dan failover.
Saat menjalankan tugas batch tengah malam, log tiba-tiba membanjir dengan 429 Too Many Requests, dan reaksi pertama banyak orang adalah “model ini tidak bagus, cepat ganti saja”. Penilaian seperti ini biasanya terlalu dini. 429 hanya berarti “ada yang membatasi Anda”, tanpa memberi tahu siapa yang membatasi, dan tanpa menjelaskan dimensi pembatasannya. Poin utama artikel ini adalah lokal dulu sumber pembatasan laju, baru putuskan mau backoff atau beralih.
Ini bukan artikel pengantar retry yang serba umum. Kami akan mengikuti urutan pemeriksaan yang sebenarnya: membedah pesan error, header respons, dan dimensi pembatasan laju, lalu memberikan saran konfigurasi parameter backoff dan jalur failover.
Nilai inti: Setelah membaca artikel ini, Anda bisa dalam beberapa menit menentukan apakah suatu 429 berasal dari penyedia upstream, gateway perantara, atau kuota paket gratis, serta menyiapkan strategi toleransi kesalahan yang “tunggu kalau memang harus tunggu, beralih kalau memang harus beralih” untuk aplikasi Anda.
Poin Inti dalam Menilai Pembatasan Laju 429
429 adalah status code “Terlalu Banyak Permintaan” (Too Many Requests) dalam standar HTTP. Dalam skenario API Model Bahasa Besar, kode ini dapat dikembalikan oleh lapisan mana pun dalam rantai pemanggilan. Tabel berikut merangkum tiga sumber paling umum beserta cara penanganan yang tepat untuk masing-masing.
| Sumber pembatasan laju | Ciri khas | Perlu ganti model? | Penanganan yang disarankan |
|---|---|---|---|
| Vendor model upstream | Body error memuat tipe error dan pilihan kata khas vendor; header respons memuat field pembatasan laju milik vendor | Biasanya tidak perlu | Lakukan backoff sesuai Retry-After; bila perlu turunkan konkurensi atau ajukan penambahan kuota |
| Gateway perantara/platform agregasi | Pilihan kata error berasal dari gateway dan menyiratkan rate tingkat akun atau grup | Tidak perlu | Periksa kuota dan pengaturan konkurensi di sisi gateway, atau ganti grup gateway |
| Tingkat gratis/kuota uji coba | Menyebut kuota gratis, batas harian, atau kapasitas yang tidak memadai | Tergantung situasi | Naikkan ke paket berbayar, atau beralih ke model sejenis yang masih punya kapasitas |
Mengapa 429 Bukan Berarti Modelnya Tidak Tersedia
Saat modelnya sendiri tidak tersedia, sinyal yang lebih umum adalah error seri 5xx. Contohnya, kelebihan beban di Anthropic akan mengembalikan 529 overloaded_error, sedangkan gangguan gateway atau load balancer umumnya berupa 502 dan 503. Status code ini menunjukkan bahwa server untuk sementara tidak sanggup menangani permintaan, dan itu berbeda dari “akun Anda melewati kuota”.
Sementara itu, 429 membawa makna kepemilikan yang jelas: aturan pembatasan laju ditujukan kepada Anda—bisa jadi kunci API Anda, organisasi Anda, tingkat gratis tempat Anda berada, atau laju yang dialokasikan gateway kepada Anda. Mengganti model kadang bisa menjadi jalan pintas, tetapi jika pembatasan laju berasal dari kuota tingkat akun di gateway, mengganti model tetap akan membentur batas yang sama. Jika pembatasan laju berasal dari batas token per menit vendor upstream, menunggu beberapa detik sudah cukup untuk pulih; mengganti model justru menimbulkan ketidakpastian kualitas output.
Rangkuman troubleshooting Claude Code dari pihak ketiga juga menguatkan hal ini: saat Claude Code menerima 429, ia menampilkan Request rejected (429), diikuti pesan asli dari server. Pesan asli itulah yang memberi tahu Anda apakah pembatasan laju berasal dari Anthropic, gateway, atau tingkat gratis. Jadi langkah pertama dalam troubleshooting selalu membaca pesan error secara lengkap, bukan hanya melihat status code.
Perbedaan 429 dengan Kode Status Terdekat
Untuk menghindari pencampuran berbagai kesalahan, tabel berikut mencantumkan beberapa kode status yang mudah dikacaukan dengan 429 dalam pemanggilan Model Bahasa Besar.
| Kode status | Arti | Pihak yang bertanggung jawab | Cocok untuk retry | Cocok untuk failover |
|---|---|---|---|---|
| 429 | Terlalu banyak permintaan, memicu batas laju atau kuota | Kuota pemanggil | Cocok, perlu backoff | Beralih setelah backoff tidak efektif |
| 529 | Upstream kelebihan beban (khusus Anthropic) | Kapasitas sisi server | Cocok, backoff singkat | Cocok |
| 503 | Layanan sementara tidak tersedia | Sisi server atau gateway | Cocok | Cocok |
| 500/502 | Kesalahan internal atau kesalahan gateway | Sisi server atau gateway | Retry dalam jumlah terbatas | Cocok |
| 400/401/403 | Masalah parameter, autentikasi, atau izin | Konfigurasi pemanggil | Tidak cocok | Tidak cocok, perlu perbaiki konfigurasi |
Ada satu detail yang mudah terlewat dalam tabel ini: mekanisme fallbackModel di Claude Code menurut pengujian pihak ketiga hanya terpicu saat overload 529, dengan maksimal 3 model cadangan yang dicoba, dan tidak terpicu saat 429. Ini menunjukkan bahwa perancang alat itu sendiri juga berpendapat bahwa reaksi pertama terhadap 429 seharusnya adalah backoff, bukan mengganti model.
Cara Menentukan dari Mana Pembatasan 429 Berasal: 3 Langkah Pemeriksaan
Berikut adalah alur pemeriksaan 429 yang bisa langsung Anda ikuti. Tiga langkah ini disusun dari biaya terendah ke tertinggi, dan pada sebagian besar kasus, lokasi masalah sudah bisa ditemukan di langkah pertama.
Langkah 1: Baca isi kesalahan 429 secara lengkap
Jangan hanya mencatat kode status di log, tetapi rekam juga isi respons apa adanya. Kesalahan 429 yang dikembalikan oleh lapisan yang berbeda memiliki perbedaan kata yang cukup jelas, dan inilah petunjuk paling langsung.
- Dikembalikan oleh penyedia upstream: isi kesalahan biasanya menyertakan bidang tipe kesalahan dari penyedia. Misalnya, Anthropic memberikan tipe
rate_limit_error, sedangkan API bergaya OpenAI memberikan kode kesalahan sepertirate_limit_exceeded, serta menjelaskan apakah yang melebihi batas adalah jumlah permintaan atau jumlah token. - Dikembalikan oleh gateway: kata-katanya sering menyebut konsep milik gateway itu sendiri seperti “akun”, “grup”, “token”, “saluran”, atau secara eksplisit menuliskan nama gateway.
- Dikembalikan oleh tingkat gratis: akan muncul kata-kata seperti “free tier”, “quota”, “daily limit”, “capacity”. Dalam pengujian uji coba gratis pihak ketiga terhadap beberapa model, kesalahan 429 bertipe kapasitas ini sering dijumpai.
Jika Anda memanggil melalui layanan proksi atau platform agregasi, perhatikan secara khusus apakah gateway meneruskan kesalahan asli dari upstream. Jika diteruskan, berarti upstream yang membatasi Anda; sedangkan kata-kata kustom yang tidak diteruskan menandakan bahwa gateway yang membatasi Anda.
Langkah 2: Periksa header respons 429
Header respons adalah rantai bukti kedua. Vendor besar biasanya mengembalikan sisa kuota dan waktu reset di header respons, dan gateway juga bisa menyertakan field miliknya sendiri.
| Header respons | Sumber umum | Arti | Kegunaan untuk diagnosis |
|---|---|---|---|
Retry-After |
Standar HTTP, berlaku umum di banyak pihak | Jumlah detik yang disarankan untuk menunggu | Prioritaskan saat melakukan backoff |
x-ratelimit-remaining-requests |
Antarmuka bergaya OpenAI | Sisa jumlah permintaan pada jendela saat ini | Menentukan apakah限流 terjadi karena RPM |
x-ratelimit-remaining-tokens |
Antarmuka bergaya OpenAI | Sisa jumlah token pada jendela saat ini | Menentukan apakah限流 terjadi karena TPM |
anthropic-ratelimit-requests-remaining |
Anthropic | Sisa jumlah permintaan | Memastikan限流 berasal dari Anthropic |
anthropic-ratelimit-input-tokens-remaining |
Anthropic | Sisa jumlah token input | Menentukan apakah限流 terjadi karena token input |
Aturan penilaiannya sederhana: jika muncul header限流 dengan prefiks vendor dan nilai sisanya 0, hampir pasti vendor upstream yang membatasi Anda; jika tidak ada header限流 vendor sama sekali, hanya ada field kustom gateway atau bahkan tidak ada apa-apa, maka kemungkinan besar masalahnya ada di lapisan gateway. Perlu diperhatikan, beberapa vendor dalam beberapa tahun terakhir mengubah batas spesifik agar hanya ditampilkan di konsol, sehingga informasi di header respons bisa jadi tidak lengkap. Dalam kasus seperti ini, kembalilah ke Langkah 1 tentang pilihan kata pada pesan error dan Langkah 3 tentang perbandingan dimensi.
Langkah 3: Mencocokkan dengan Dimensi Pembatasan Laju
Setelah mengetahui siapa yang membatasi Anda, Anda juga perlu memahami apa yang dibatasi. Aturan pembatasan laju antarpenyedia tidak seragam. Rangkuman lintas penyedia dari pihak ketiga terhadap 5 vendor menunjukkan: Anthropic terutama membatasi berdasarkan jumlah token per menit, dan token dari cache hit tidak dihitung dalam kuota; DeepSeek terutama membatasi jumlah konkurensi; sedangkan kuota spesifik OpenAI dan Google lebih sering dicek di konsol.
Ini berdampak langsung pada strategi konfigurasi. Pemetaan umumnya adalah sebagai berikut:
- RPM (jumlah permintaan per menit) melebihi batas: gabungkan beberapa permintaan kecil menjadi permintaan batch, atau tambahkan token bucket di sisi klien agar pengiriman merata.
- TPM (jumlah token per menit) melebihi batas: perpendek konteks, aktifkan cache petunjuk, dan bagi tugas dokumen panjang ke jendela waktu yang berbeda.
- Jumlah konkurensi melebihi batas: kurangi jumlah worker, gunakan antrean untuk mengendalikan jumlah permintaan yang sedang berjalan; sekadar backoff efeknya terbatas.
- Kuota harian atau kuota gratis habis: backoff tidak ada gunanya; satu-satunya pilihan adalah menunggu reset, meningkatkan tier, atau beralih ke saluran lain.
Kasus ke-4 adalah satu-satunya 429 yang “backoff pasti tidak efektif”, dan juga kasus yang paling harus dikenali sedini mungkin lalu langsung masuk ke failover.
Bagaimana Mengonfigurasi Strategi Backoff 429
Setelah memastikan bahwa 429 termasuk pembatasan laju (rate limit) yang dapat dipulihkan, kita masuk ke fase backoff. Tujuan backoff bukanlah “mencoba ulang secepat mungkin”, melainkan “pulih secepat mungkin tanpa menambah kepadatan”.
Exponential Backoff dengan Jitter Acak
Skema yang paling umum adalah exponential backoff ditambah jitter acak. Waktu tunggu untuk percobaan ulang ke-n kira-kira “delay dasar × 2 pangkat n”, lalu di atasnya ditambahkan nilai acak, dengan batas atas yang ditetapkan. Fungsi jitter acak adalah menyebarkan titik waktu percobaan ulang dari banyak klien, agar mereka tidak menyerbu secara terpusat pada detik yang sama dan membentuk “badai percobaan ulang”.
Jika respons menyertakan Retry-After, prioritasnya harus lebih tinggi daripada waktu backoff yang kamu hitung sendiri. Server lebih tahu kapan jendela direset; menunggu sesuai sarannya biasanya adalah cara tercepat untuk pulih.
Nilai Parameter Backoff yang Direkomendasikan
Tabel berikut memberikan satu set parameter awal yang cocok untuk sebagian besar skenario percakapan dan pemrosesan batch; dalam penggunaan aktual, nilainya dapat disesuaikan dengan toleransi latensi bisnis.
| Parameter | Nilai Awal yang Direkomendasikan | Keterangan |
|---|---|---|
| Delay dasar | 1 detik | Waktu tunggu sebelum percobaan ulang pertama |
| Pengali backoff | 2 | Waktu tunggu berlipat ganda setiap kali percobaan ulang |
| Waktu tunggu maksimal per percobaan | 30-60 detik | Mencegah waktu tunggu tumbuh tanpa batas |
| Jumlah percobaan ulang maksimal | 3-5 kali | Setelahnya masuk ke failover atau laporan error |
| Jitter acak | 0-100% acak dari waktu tunggu | Disarankan metode “full jitter” untuk menyebarkan percobaan ulang |
| Retry-After | Diprioritaskan jika ada | Menimpa waktu backoff yang dihitung sendiri |
Ada dua detail konfigurasi yang sering diabaikan. Pertama, dalam skenario interaktif (misalnya antarmuka chat), total waktu tunggu tidak boleh terlalu lama; disarankan menetapkan anggaran timeout total, dan setelah terlampaui langsung beralih atau beri tahu pengguna. Kedua, jangan melakukan backoff dan percobaan ulang untuk kesalahan konfigurasi seperti 400, 401, dan 403; seberapa lama pun menunggu, kesalahan itu tidak akan membaik sendiri dan hanya akan membuang waktu serta kuota.
Jika kamu menggunakan SDK resmi, banyak SDK sudah memiliki percobaan ulang otomatis bawaan untuk 429 dan 5xx, biasanya dikendalikan melalui parameter seperti max_retries. Sebelum membungkus lapisan percobaan ulang sendiri, pastikan dulu perilaku default SDK, agar dua lapisan percobaan ulang tidak menumpuk dan membuat jumlah percobaan ulang aktual berlipat ganda secara berlebihan.
Cara mengonfigurasi failover untuk 429
Backoff adalah “menunggu di tempat”, sedangkan failover adalah “mengambil jalur lain”. Keduanya bukan pilihan salah-satu, melainkan berurutan: backoff dulu, kalau tidak berhasil baru beralih.
Kapan failover sebaiknya dipicu
Sebaiknya picu peralihan ketika salah satu kondisi berikut terpenuhi, bukan begitu melihat 429 langsung beralih:
- Jumlah percobaan ulang maksimum sudah tercapai, tetapi 429 masih terus kembali;
- Pesan error secara eksplisit menunjuk kuota harian, kuota gratis yang habis, atau “kapasitas tidak mencukupi”;
- Waktu tunggu yang diberikan
Retry-Aftermelebihi batas atas yang bisa diterima bisnis; - Satu kanal gagal berkali-kali dalam waktu singkat hingga memicu ambang circuit breaker.
Saran pihak ketiga untuk menangani 429 yang sering muncul pada model populer di OpenRouter juga memakai pola yang sama: backoff dulu, lalu failover ke model lain di bawah antarmuka yang sama. Urutan ini membuat kita tetap mendapatkan kualitas output model asli sekaligus menjaga layanan tetap berjalan.
Tiga desain jalur failover
“Rute cadangan” untuk failover punya beberapa tingkatan, dengan biaya peralihan dari rendah ke tinggi:
- Model sama, ganti kanal: model yang sama, tetapi pakai kunci API lain, grup lain, atau penyedia lain. Konsistensi output paling baik, jadi ini pilihan utama.
- Vendor sama, turunkan kelas: misalnya dari model unggulan ke model ringan di seri yang sama; kemampuan sedikit menurun, tetapi gayanya tetap mirip.
- Lintas vendor, ganti model: pindah ke model selevel dari vendor lain; ketersediaan paling tinggi, tetapi efek petunjuk dan format output perlu divalidasi lebih dulu.
Di atas itu, sebaiknya tambahkan satu lapis circuit breaker: setelah sebuah kanal gagal berturut-turut sampai ambang tertentu, lewati saja kanal tersebut selama masa pendinginan; setelah pendinginan berakhir, kirim sedikit permintaan uji, dan jika sudah pulih, tambah trafiknya secara bertahap. Ini mencegah setiap permintaan menabrak dinding yang sama dulu baru beralih, sehingga latensi keseluruhan turun secara signifikan.
Kedua strategi yang dibandingkan pada gambar di atas dapat diverifikasi dalam proyek nyata melalui satu antarmuka terpadu yang sama. Platform yang kompatibel dengan format API OpenAI dan Anthropic seperti APIYI memungkinkan kode yang sama beralih ke model cadangan hanya dengan mengubah parameter model, jauh lebih praktis daripada memelihara SDK terpisah untuk setiap vendor.
Panduan Cepat Menangani Pembatasan Laju 429
Berikut rangkuman dari pembahasan sebelumnya menjadi daftar periksa konfigurasi yang bisa langsung kamu terapkan. Seluruh bagian ini tidak membahas kode, jadi kamu bisa memakainya sebagai checklist saat melakukan code review atau mengatur konfigurasi operasional.
Daftar Periksa 5 Konfigurasi
- Log: Catat isi respons dan header respons secara lengkap, setidaknya mencakup status code, jenis error, pesan error,
Retry-After, serta berbagai fieldratelimit. - Klasifikasi: Di sisi klien, kelompokkan error menjadi tiga kategori: “bisa di-backoff” (429 tipe laju, 529, 503), “perlu ganti” (kuota habis, kegagalan berulang), dan “tidak bisa diulang” (400, 401, 403).
- Backoff: Konfigurasikan exponential backoff plus full jitter sesuai tabel parameter di atas, prioritaskan
Retry-After, dan tetapkan jumlah maksimal percobaan ulang serta anggaran timeout total. - Rantai pergantian: Susun daftar cadangan dengan urutan “model sama ganti channel → vendor sama ganti tier → lintas vendor ganti model”, dan verifikasi lebih dulu efek petunjuk pada setiap model cadangan.
- Pemutus sirkuit dan alarm: Tetapkan ambang kegagalan dan waktu pendinginan untuk setiap channel, sekaligus pasang alarm pada rasio 429. Jika angkanya terus tinggi, artinya perlu mengajukan penambahan kuota atau menyesuaikan konkurensi.
Contoh Rantai Model Cadangan
Tabel berikut adalah ilustrasi rantai pergantian tiga tingkat yang umum. Nama model spesifik mengikuti daftar model platform, dan biaya yang terlibat mengikuti halaman harga; artikel ini tidak mencantumkan harga satuan.
| Tingkat | Pendekatan pemilihan | Format antarmuka | Platform yang tersedia | Dasar harga |
|---|---|---|---|---|
| Utama | Model flagship dengan hasil bisnis terbaik | Format OpenAI atau Anthropic | APIYI apiyi.com, API resmi | Mengikuti docs.apiyi.com/models |
| Cadangan tingkat 1 | Channel atau grup lain untuk model yang sama | Sama dengan utama | APIYI apiyi.com, API resmi | Mengikuti docs.apiyi.com/models |
| Cadangan tingkat 2 | Model ringan dari vendor yang sama atau model setara lintas vendor | Format kompatibel OpenAI | APIYI apiyi.com dan platform agregator lain | Mengikuti docs.apiyi.com/models |
Untuk cara integrasi, jika kamu menggunakan SDK resmi OpenAI atau Anthropic, biasanya cukup mengganti base_url ke alamat yang disediakan platform dan mengganti api_key dengan kunci platform. Untuk alamat antarmuka spesifik dan penjelasan pemanggilan tiap model, sebaiknya mengacu pada pusat dokumentasi APIYI di docs.apiyi.com, jangan menyalin alamat dari internet yang belum terverifikasi.
🚀 Mulai cepat: Saat membangun rantai toleransi 429, sebaiknya mulai dengan menghubungkan model utama dan cadangan lewat APIYI apiyi.com menggunakan satu set kode yang sama. Platform menyediakan pemanggilan API untuk model-model populer yang dibahas di artikel ini, kompatibel dengan format antarmuka OpenAI dan Anthropic, dan pergantian model cukup dengan mengubah parameter
model. Dokumentasi integrasi tersedia di docs.apiyi.com; harga input/output tiap model, harga cache, dan dasar penagihan mengikuti data aktual di halaman harga docs.apiyi.com/models.
FAQ (Pertanyaan Umum)
Q1: Apa itu pembatasan 429?
429 adalah kode status Too Many Requests dalam standar HTTP, yang berarti pemanggil telah melampaui jumlah permintaan, jumlah token, konkurensi, atau kuota total yang diizinkan dalam suatu jendela waktu tertentu. Kode ini menunjukkan “Anda sedang dibatasi”, bukan berarti modelnya sendiri mengalami gangguan.
Q2: Apa perbedaan 429 dengan 529 dan 503?
429 menunjuk pada masalah kuota di sisi pemanggil, tanggung jawabnya ada pada “Anda yang terlalu banyak memakai”; 529 adalah error kelebihan beban (overload) khas Anthropic, sedangkan 503 berarti layanan sementara tidak tersedia, keduanya merupakan tanggung jawab kapasitas di sisi server. Untuk kasus pertama, prioritaskan backoff dan penyesuaian pemakaian; untuk dua kasus terakhir lebih cocok melakukan backoff singkat lalu langsung failover.
Q3: Bagaimana cara tercepat menentukan apakah 429 berasal dari vendor upstream atau dari gateway?
Pertama lihat kalimat di body error: yang membawa tipe error khas vendor biasanya berasal dari upstream, sedangkan yang menyebut konsep seperti akun, grup, atau channel biasanya berasal dari gateway. Lalu lihat header respons: jika muncul field `ratelimit` berprefiks vendor dengan nilai sisa 0, hampir bisa dipastikan upstream yang sedang membatasi.
Q4: Kenapa sudah melakukan backoff berkali-kali tapi 429 tetap tidak pulih?
Penyebab paling umum adalah salah menilai dimensi pembatasannya. Jika kuota harian atau kuota gratis sudah habis, backoff pasti tidak akan berguna; jika yang terlampaui adalah jumlah konkurensi, sementara klien masih mengirim dengan konkurensi tinggi, backoff hanya bisa meredakan. Pada kondisi ini sebaiknya turunkan konkurensi atau langsung masuk ke failover.
Q5: Bagaimana cara cepat membangun rantai failover multi-model?
Disarankan melakukan validasi menggunakan platform yang mendukung antarmuka terpadu untuk berbagai model:
1. Daftarkan akun di APIYI apiyi.com dan dapatkan kunci API;
2. Konfigurasikan `base_url` sesuai dokumentasi docs.apiyi.com, akses dengan format OpenAI atau Anthropic;
3. Konfigurasikan daftar model utama dan cadangan di klien, lalu lakukan peralihan dengan mengubah parameter `model`.
Dengan cara ini model utama dan cadangan memakai satu set kode yang sama, sehingga biaya pengujian rantai failover akan jauh lebih rendah.
Q6: Apakah failover bisa membuat biaya tak terkendali?
Bisa saja. Harga satuan, panjang konteks, dan strategi cache model cadangan bisa berbeda dengan model utama, sehingga peralihan yang sering akan mengubah struktur tagihan. Sebaiknya cocokkan harga setiap model cadangan terlebih dahulu, jadikan data aktual di halaman harga APIYI docs.apiyi.com/models sebagai acuan, dan pasang peringatan untuk rasio peralihan.
Q7: Apa saja keterbatasan yang sudah diketahui dari solusi penanganan 429?
Backoff akan menambah latensi permintaan, sehingga tidak cocok untuk skenario yang menuntut real-time sangat tinggi; peralihan antar vendor bisa menimbulkan perbedaan gaya dan format output, jadi perlu regression test lebih dulu; sebagian vendor hanya menampilkan limit di konsol, informasi pada header respons tidak lengkap, sehingga saat investigasi hanya bisa bergantung pada kalimat error dan data monitoring.
Poin-Poin Inti Penanganan Rate Limit 429
- 429 hanya menandakan kena pembatasan: status ini tidak memberi tahu siapa yang membatasi atau apa yang dibatasi, jadi tidak bisa langsung diartikan sebagai model bermasalah.
- Baca dulu pesan error aslinya: pilihan kata pada body error adalah petunjuk tercepat untuk menebak apakah batasnya datang dari upstream, gateway, atau paket gratis.
- Lalu periksa header respons: field
ratelimitberprefiks vendor danRetry-Afteradalah rantai bukti kedua. - Tangani sesuai dimensinya: RPM → ratakan laju permintaan, TPM → perkecil konteks, konkurensi → kendalikan jumlah worker, kuota habis → langsung ganti.
- Mundur dulu, baru beralih: exponential backoff ditambah full jitter, utamakan
Retry-After, dan retry harus punya batas atas. - Rancang rantai failover berlapis: prioritas ganti channel untuk model yang sama, jaring pengaman ganti model lintas vendor, dipadukan dengan circuit breaker.
- Pakai antarmuka terpadu untuk menekan biaya: lewat APIYI yang kompatibel dengan format OpenAI maupun Anthropic, satu set kode bisa dipakai mengelola model utama dan cadangan.
Ringkasan
Saat menemui 429, urutan yang benar adalah “lokalisasi sumber → tentukan dimensi → backoff → failover”, bukan langsung ganti model:
- Lokalisasi sumber: baca diksi body error plus header respons, lalu bedakan antara vendor upstream, gateway, dan paket gratis.
- Tentukan dimensi: pastikan apakah yang kena batas adalah jumlah permintaan, jumlah token, konkurensi, atau kuota total — ini menentukan apakah backoff akan efektif.
- Konfigurasi toleransi kesalahan: exponential backoff dengan jitter sebagai lapisan pertahanan pertama, failover berlapis plus circuit breaker sebagai lapisan kedua.
Kalau alur ini sudah dibakukan ke dalam log, klasifikasi error, dan konfigurasi klien, 429 berubah dari “alarm tengah malam” menjadi kejadian rutin yang bisa diprediksi dan pulih dengan sendirinya.
Untuk memverifikasi efek failover model utama dan cadangan dengan cepat, disarankan lewat APIYI apiyi.com; panduan integrasi ada di docs.apiyi.com, sedangkan harga model dan dasar perhitungan biaya yang terkait mengacu pada docs.apiyi.com/models.
📚 Referensi
- Rate Limit Reached in Claude Code: What Each 429 Message Means: Memahami arti setiap pesan error 429 di Claude Code
- Tautan:
ofox.ai/blog -
Penjelasan: Menjelaskan cara membedakan pembatasan laju dari Anthropic, gateway, dan paket gratis lewat kalimat asli dari sisi server
-
Claude Code fallbackModel: 3-Tier Failover Setup: Konfigurasi model cadangan di Claude Code
- Tautan:
ofox.ai/blog -
Penjelasan: Menunjukkan bahwa fallbackModel terpicu saat overload 529, maksimal 3 model, bukan pada 429
-
LLM API Rate Limits Compared: Perbandingan aturan pembatasan laju dari 5 vendor Model Bahasa Besar
- Tautan:
ofox.ai/blog -
Penjelasan: Membandingkan berbagai dasar pembatasan laju seperti per token, per konkurensi, dan yang hanya ditampilkan di konsol
-
Pusat Dokumentasi dan Halaman Harga APIYI: Petunjuk integrasi dan penagihan model
- Tautan:
docs.apiyi.comdandocs.apiyi.com/models - Penjelasan: Format antarmuka, konfigurasi base_url, dan harga aktual tiap model mengacu pada halaman ini
Penulis: Tim Teknis APIYI
Diskusi Teknis: Silakan hubungi kami lewat halaman utama APIYI apiyi.com untuk berdiskusi seputar praktik pembatasan laju dan toleransi kesalahan. Materi integrasi lainnya dapat diakses di pusat dokumentasi docs.apiyi.com
