Batas Laju Muse Wonder: 3.000 RPM dan 4M TPM, Dibagikan ke Seluruh Tim

Batasan kecepatan Muse Wonder pada Meta Model API adalah 3.000 permintaan per menit dan 4.000.000 token per menit. Keduanya berlaku per model dan per tim, bukan per kunci API: setiap kunci yang dibuat organisasi Anda diambil dari pool yang sama. Respons latar belakang mendapat tunjangan terpisah sebesar 600 kiriman baru per menit. Tidak ada tingkatan penggunaan yang dipublikasikan dan tidak ada cara terdokumentasi untuk meminta lebih banyak. Ketika Anda melebihi batas, Anda mendapatkan HTTP 429, dan panduan Meta adalah backoff eksponensial dengan jitter mulai sekitar 500 ms, serta mematuhi Retry-After jika ada.

Coba Apidog hari ini

Empat fakta ini menentukan cara merancang sistem apa pun yang memanggil muse-wonder-1.0 dalam skala besar. Pos ini mencakup arti batas tersebut dalam praktik, bagaimana konteks 1M token menghabiskan anggaran 4M TPM, cara membaca header, cara membangun dan menguji jalur percobaan ulang, serta apa yang harus dilakukan ketika 3.000 RPM tidak cukup. Untuk dasar-dasar API, mulailah dengan panduan Muse Wonder API.

Batas

Batas	Nilai	Cakupan
Permintaan per menit	3.000	Per tim, per model
Token per menit	4.000.000	Per tim, per model
Kiriman latar belakang	600 per menit	Per tim, di atas batas utama
Jendela konteks	1.048.576 token	Per permintaan
Tingkatan penggunaan	Tidak ada yang dipublikasikan
Peningkatan batas	Tidak ada proses terdokan	Permintaan per menit sebelum TPM mengikat
---	---:	---:
Giliran obrolan pendek	3.000	1.333
Tinjauan dokumen	50.000	80
Giliran agen panjang, konteks 400K	400.000	10
Permintaan jendela penuh	1.000.000	4

Tim yang menjalankan beberapa agen dengan konteks besar dapat mencapai 4M TPM hanya dengan selusin permintaan bersamaan. Input yang di-cache tetap dihitung dalam TPM; diskon cache adalah diskon penagihan, bukan diskon batas laju. Token penalaran dihitung dalam max_output_tokens dan tagihan Anda, dan token output juga dihitung dalam TPM.

Konsekuensi praktisnya: anggarkan TPM berdasarkan ukuran konteks, bukan jumlah permintaan. Agen yang mengirim ulang percakapan 300K token setiap giliran adalah permintaan 300K token setiap kali, dan sepuluh agen seperti terberat Anda sebelum menerapkan.

Agen	Token per giliran	Giliran per menit masing-masing	TPM yang dibutuhkan	Ruang sisa
4	150.000	2	1.200.000	70%
8	250.000	1	2.000.000	50%
12	300.000	1	3.600.000	10%
20	300.000	1	6.000.000	Melebihi batas

Sisakan setidaknya 40% ruang sisa. Giliran agen bersifat bursty, badai percobaan ulang setelah kesalahan sementara dapat menggandakan permintaan selama satu menit, dan orang lain di tim mengambil dari pool yang sama. Baris ketiga terlihat baik di atas kertas, tetapi gagal dalam praktik begitu dua agen mencoba ulang sekaligus.

Dua tuas dapat memperkecil sisi kiri persamaan. Kompaksi menjaga token per giliran agar tidak tumbuh tanpa batas: ringkas atau buang hasil alat lama setelah proses melewati ambang batas, seperti yang dijelaskan pos jendela konteks. Replay terenkripsi tanpa status pada Responses API memungkinkan Anda mengontrol persis apa yang dikirim ulang, sementara riwayat yang dikelola server dengan previous_response_id mengirim ulang semuanya.

Satu Pool untuk Semua Kunci

Meta menetapkan batas per tim. Kunci untuk staging, kunci untuk produksi, dan kunci di laptop rekan satu tim semuanya diambil dari pool 3.000 RPM/4M TPM yang sama. Ini punya dua konsekuensi.

Pertama, uji beban dari satu pengembang dapat membatasi produksi. Pisahkan eksperimen dalam waktu, atau gunakan tim terpisah jika organisasi Anda mengizinkannya. Kedua, pemantauan per kunci tidak akan menunjukkan gambaran lengkap. Agregasi header x-ratelimit-* di setiap pemanggil, atau Anda akan melihat 429 pada kunci yang tampaknya masih jauh di bawah batasnya.

Baca Header

Respons berbasis token membawa header x-ratelimit-*. Catat header tersebut pada setiap panggilan. Pola pentingnya adalah kapasitas tersisa menurun menuju nol di semua pemanggil dalam satu menit—itulah sinyal untuk memperlambat sebelum 429 tiba. Respons transkripsi tidak membawa header ini; respons Wonder membawa.

Saat 429 tiba, dokumentasi Meta spesifik: lakukan backoff eksponensial dengan jitter mulai sekitar 500 ms, dan jika Retry-After ada, tunggu setidaknya selama itu. Loop percobaan ulang yang mengabaikan Retry-After dan menghantam API pada interval tetap akan membuat pemadaman lebih lama untuk semua orang di tim Anda.

Bangun Jalur Percobaan Ulang

import os
import random
import time

from openai import OpenAI, RateLimitError

client = OpenAI(
    base_url="https://api.meta.ai/v1",
    [REDACTED CREDENTIAL],
)

def call(input_text, attempts=6):
    delay = 0.5

    for _ in range(attempts):
        try:
            return client.responses.create(
                model="muse-wonder-1.0",
                input=input_text,
                reasoning={"effort": "medium"},
                max_output_tokens=4096,
            )
        except RateLimitError as error:
            retry_after = error.response.headers.get("retry-after")

            if retry_after:
                wait = float(retry_after)
            else:
                wait = delay + random.uniform(0, delay)
                delay = min(delay * 2, 30)

            time.sleep(wait)

    raise RuntimeError("rate limited after retries")

Tiga poin desain penting. Batasi backoff eksponensial agar pemadaman panjang tidak berubah menjadi tidur 20 menit. Jaga percobaan ulang tetap idempoten: panggilan Responses yang tidak membuat apa pun di sisi Anda aman diulang, tetapi jika panggilan alat agen Anda memiliki efek samping, coba ulang panggilan model, bukan alatnya. Terakhir, tampilkan percobaan ulang dalam trace agar Anda bisa membedakan model lambat dari model yang dibatasi; panduan pelacakan panggilan alat mencakup apa yang harus dicatat.

Gunakan Respons Latar Belakang untuk Ekor Panjang

Pekerjaan panjang tidak perlu menahan koneksi. background: true mengantrekan respons, mengembalikan "status": "queued", dan memungkinkan Anda polling GET /v1/responses/{id}?stream=true untuk peristiwa siklus hidup. Kiriman latar belakang memiliki tunjangan sendiri sebesar 600 per menit di luar batas utama, sehingga memindahkan pekerjaan bergaya batch ke sana membebaskan RPM untuk lalu lintas interaktif.

Batasiannya jelas: tidak ada stream: true pada POST, batas isi 1 MiB, dan pembatalan dilakukan dengan POST /v1/responses/{id}/cancel.

Ketika 3.000 RPM Tidak Cukup

Meta tidak mempublikasikan tangga tingkatan atau formulir untuk menaikkan batas. Opsi Anda hari ini:

• Kurangi token per permintaan. Prompt caching mengurangi tagihan Anda tetapi tidak mengurangi TPM; memangkas konteks melakukan keduanya. Pos jendela konteks membahas pemangkasan hasil alat.
• Sebar ke model lain. Spark 1.3 memiliki pool 3.000 RPM/4M TPM sendiri dengan sepertiga harga. Rutekan pekerjaan yang tidak membutuhkan kualitas Wonder ke sana.
• Gunakan gateway. Vercel AI Gateway dan Cloudflare Workers AI menyajikan meta/muse-wonder-1.0. Apakah itu memberi Anda tunjangan terpisah bergantung pada cara gateway disediakan; periksa dengan penyedia gateway sebelum mengandalkannya.
• Antrean dan haluskan. Pembatas token-bucket di depan API yang mengetahui seluruh anggaran tim akan lebih baik daripada enam layanan yang masing-masing menebak.

Uji Penanganan Batas di Apidog

Jangan menemukan bug percobaan ulang Anda pada permintaan ke-3.001. Di Apidog:

1. Bangun permintaan Responses dengan MODEL_API_KEY sebagai variabel rahasia, lalu tambahkan post-processor yang membaca header x-ratelimit-* ke variabel lingkungan. Skenario kemudian dapat menyatakan bahwa kapasitas tersisa tidak pernah turun di bawah ambang batas.
2. Buat mock /v1/responses dengan ekspektasi yang mengembalikan 429 dan header Retry-After: 2 saat permintaan membawa header seperti X-Test-Scenario: throttle. Arahkan klien Anda ke mock, lalu nyatakan bahwa ia menunggu setidaknya dua detik dan berhasil pada percobaan berikutnya.
3. Jalankan tes performa yang menaikkan volume permintaan terhadap mock untuk mengonfirmasi bahwa pembatas Anda aktif sebelum API melakukannya.
4. Masukkan skenario ke CI dengan Apidog CLI agar perubahan pada kode percobaan ulang tidak bisa dikirim tanpa lulus.

Unduh Apidog untuk menyiapkan mock dan asersi dalam satu proyek.

Pertanyaan yang Sering Diajukan

Apakah batas laju Muse Wonder per kunci atau per akun?

Per tim. Semua kunci dalam satu tim berbagi satu pool 3.000 RPM/4M TPM per model.

Apakah input yang di-cache dihitung dalam TPM?

Ya. Caching menurunkan harga token tersebut, bukan bobotnya terhadap batas token per menit.

Bisakah saya meminta batas lebih tinggi?

Halaman harga dan batas laju Meta tidak mencantumkan tingkatan atau prosesnya. Periksa halaman tersebut untuk perubahan; peluncuran frontier sering menambahkan tingkatan dalam beberapa minggu.

Kode status dan header apa yang saya dapatkan?

HTTP 429, opsional dengan Retry-After, ditambah header x-ratelimit-* pada respons berbasis token.

Langkah Berikutnya

Ukur token per permintaan dari giliran agen terberat Anda, kalikan dengan tingkat konkurensi, lalu bandingkan dengan 4.000.000. Jika hasilnya sudah mendekati batas, bangun pembatas dan tes mock minggu ini—sebelum seluruh tim berbagi pool yang sama dengan produksi.