Tingkat API OpenAI dijelaskan: Build, Launch, Grow dan batas belanja
Diperbarui October 7, 2026 · pertama terbit October 7, 2026
OpenAI menyederhanakan tingkat API berbayarnya menjadi Build, Launch, dan Grow pada 6 Oktober 2026. Organisasi naik tingkat secara otomatis saat pembelian kredit kumulatif melewati setiap ambang, yang umumnya membuka batas laju (rate limit) yang lebih tinggi. Tingkat adalah sinyal kapasitas dan kuota penggunaan bulanan; ia terpisah dari batas belanja proyek atau organisasi, yang harus dikonfigurasi sebagai kontrol anggaran.
Apa yang berubah pada tingkat penggunaan API OpenAI?
Changelog 6 Oktober dari OpenAI menyatakan bahwa platform API berpindah dari lima tingkat berbayar menjadi tiga: Build, Launch, dan Grow. Panduan batas laju saat ini mencantumkan level kualifikasi berikut: Build pada total pembelian kredit $5, Launch $100, dan Grow $500. Panduan itu juga menyebut batas penggunaan $100 per bulan untuk pengguna tingkat gratis yang memenuhi syarat. OpenAI menyatakan bahwa tingkat yang lebih tinggi umumnya mendapat batas laju model yang lebih tinggi.
Jumlah pembelian adalah ambang kumulatif untuk menentukan kelayakan tingkat. Itu bukan harga langganan bulanan, dan bukan janji bahwa organisasi Anda akan membelanjakan jumlah tersebut setiap bulan. Panduan yang dipublikasikan menggambarkannya sebagai total pembelian kredit. Periksa dasbor organisasi Anda untuk tingkat aktual, batas penggunaan bulanan yang disetujui, dan batas per model; status organisasi itulah yang penting untuk perencanaan operasional.
Apa yang diberikan tingkat yang lebih tinggi kepada tim?
Batas laju dapat membatasi permintaan per menit (RPM), token per menit (TPM), volume harian, throughput gambar, atau pekerjaan Batch yang antre. Sebuah job bisa berada di bawah batas penggunaan bulanannya namun tetap mencapai batas per menit. Panduan saat ini menunjukkan perbedaan menurut model: untuk GPT-6 Astra, Sol, dan Terra, contoh RPM/TPM standarnya naik dari 5.000 RPM dan 1 juta TPM di Build menjadi 10.000 RPM dan 4 juta TPM di Launch, lalu 15.000 RPM dan 40 juta TPM di Grow. Batas standar yang tercantum untuk GPT-6 Luna berbeda lagi. Ini adalah nilai referensi yang dipublikasikan, bukan pengganti batas yang ditampilkan untuk organisasi, model, dan proyek Anda.
Perbedaan ini penting saat peluncuran. Tim bisa memperkirakan kuota bulanan yang cukup namun tetap ter-throttle ketika beban kerja baru mengirim trafik terlalu cepat atau melampaui throughput permintaan atau tokennya. Batas laju juga dapat berlaku di tingkat organisasi dan proyek, dan model yang berbeda mungkin berbagi satu batas. Baca header respons dan dasbor sebelum menganggap nama tingkat sebagai jaminan kapasitas.
Apakah tingkat penggunaan adalah cara membatasi belanja bulanan?
Tidak. OpenAI mendokumentasikan batas penggunaan bulanan yang disetujui secara terpisah dari batas belanja organisasi atau proyek yang dapat dikonfigurasi. Peringatan belanja mengirim notifikasi sementara trafik API tetap berjalan. Batas belanja keras memblokir permintaan API yang terdampak dengan respons 429 saat jumlah yang dikonfigurasi tercapai. Pilih batas keras ketika penegakan itu penting; peringatan hanya memberi visibilitas, bukan pemutus sirkuit.
Ini juga berarti bahwa membeli kredit untuk melewati ambang tingkat bukanlah kebijakan kontrol biaya yang aman dengan sendirinya. Tingkat dapat meningkatkan throughput, tetapi tidak menggantikan kepemilikan per proyek, perutean peringatan, perkiraan penggunaan, atau batas keras yang disengaja. Tim engineering yang membutuhkan kapasitas peluncuran lebih besar sebaiknya memodelkan dua hal: ambang pembelian yang diperlukan untuk memenuhi syarat, dan batas belanja bulanan yang terpisah yang ingin ditegakkan oleh Finance.
Bagaimana Finance dan engineering sebaiknya mengatur kenaikan tingkat?
- Inventarisasi organisasi dan proyek. Catat tingkat, kuota penggunaan bulanan, RPM/TPM per model, batas bersama, dan pemilik untuk setiap proyek produksi.
- Tetapkan kontrol belanja yang eksplisit. Konfigurasikan batas keras di tingkat proyek di tempat trafik harus berhenti pada anggaran tetap, dan peringatan di tempat tim membutuhkan peringatan dini. Jangan berasumsi bahwa kuota tingkat menyediakan kontrol ini.
- Perkirakan kenaikan beban kerja. Proyeksikan permintaan dan token per menit serta belanja token bulanan. Sebuah layanan bisa mencapai batas throughput jauh sebelum mencapai plafon dolar bulanan.
- Atur pembelian yang terkait tingkat. Perlakukan pembelian kredit tambahan yang memajukan ambang kumulatif sebagai keputusan akses dan kapasitas. Minta prakiraan beban kerja, pemilik, dan tinjauan kontrol yang ada sebelum mengajukannya.
- Amati respons yang sebenarnya. Gunakan header batas laju dan log untuk membedakan habisnya batas permintaan, token, atau batas lainnya. Terapkan backoff pada respons batas laju sementara, bukan memicu badai percobaan ulang.
Misalnya, secara hipotetis, sebuah tim produk memperkirakan kampanye peluncuran akan meningkatkan permintaan per menit menjadi tiga kali lipat, tetapi tetap menjaga penggunaan token bulanan di bawah batas Finance. Pertanyaan operasionalnya adalah apakah RPM dan TPM model proyek mampu menangani kenaikan itu. Pertanyaan keuangannya adalah apakah batas belanja keras ditetapkan pada anggaran kampanye yang disetujui. Keduanya adalah tinjauan yang terkait, tetapi merupakan kontrol yang berbeda.
Bagaimana tim sebaiknya memutuskan pindah dari Build ke Launch?
Mulailah dari bukti beban kerja, bukan dari label tingkat. Jika log produksi menunjukkan habisnya batas yang berulang pada tingkat saat ini, perkirakan headroom RPM dan TPM yang dibutuhkan, identifikasi batas model dan proyek yang berlaku, dan konfirmasi efek tingkat di dasbor. Kemudian bandingkan pembelian kredit yang diperlukan untuk memenuhi syarat dengan nilai bisnis dan kebijakan anggaran. Jika batas saat ini sudah cukup, meningkatkan tingkat hanya karena tingkat berikutnya ada tidak memberi manfaat operasional.
OpenAI mencatat bahwa tingkat yang lebih tinggi umumnya menaikkan batas, dan ambang yang dipublikasikan dapat berubah. Periksa ulang panduan batas laju dan dasbor sebelum siklus anggaran atau perubahan trafik yang material. Jaga tinjauan peringatan belanja dan batas keras dalam rutinitas FinOps bulanan yang sama dengan bauran model, percobaan ulang, dan biaya per tugas yang berhasil.
Apa kesimpulan praktisnya?
Build, Launch, dan Grow menjawab pertanyaan kapasitas: batas dan kuota penggunaan apa yang mungkin berlaku saat pembelian kumulatif organisasi meningkat. Kontrol belanja Anda menjawab pertanyaan anggaran: kapan tim harus diperingatkan, dan kapan permintaan harus dihentikan. Lacak keduanya. Kenaikan tingkat dapat membuka throughput, tetapi hanya batas keras yang dikonfigurasi secara terpisah yang menegakkan batas biaya bulanan.
Riset terkait apa yang sebaiknya dibaca tim?
- Batas laju adalah kontrol biaya
- Belanja berkomitmen adalah taruhan pada prakiraan Anda
- Runbook produksi untuk lonjakan biaya LLM
Terkait
Ingin menerapkannya pada stack Anda? Bawa tagihan penyedia, log gateway, dan alur kerja utama; kami akan memetakan pendorong biaya dan jalur penghematan. Pesan audit gratis →