Lewati ke isi

AI & Otomasi

Membatasi Kuota dan Biaya API AI per Tim atau Aplikasi

Cara memisahkan dan membatasi biaya API AI per tim atau aplikasi lewat workspace, project, rate limit, dan gateway seperti LiteLLM.

Terbit 6 menit baca

Jawaban singkat

Pisahkan pemakaian per tim atau aplikasi dengan workspace atau project dan API key masing-masing, pasang batas belanja dan rate limit di konsol penyedia, lalu tambahkan gateway seperti LiteLLM bila butuh anggaran per key yang benar-benar memblokir.

Daftar isi
  1. Kenapa satu API key untuk semua itu berbahaya?
  2. Fitur pembatas yang sudah ada di konsol penyedia
  3. Anthropic (Claude API): workspace
  4. OpenAI: project
  5. Kapan perlu gateway seperti LiteLLM?
  6. Perbandingan cara membatasi biaya
  7. Langkah praktis menyusun kebijakan kuota
  8. Bagaimana dengan batas untuk pengguna akhir?
  9. Pertanyaan yang sering diajukan

Cara paling aman membatasi biaya API AI adalah memberi setiap tim atau aplikasi "dompet" sendiri: workspace atau project terpisah, API key terpisah, lalu batas belanja dan batas laju (rate limit) di masing-masing. Kalau fitur bawaan penyedia belum cukup, pasang gateway di tengah yang bisa memblokir permintaan begitu anggaran habis.

Kenapa ini penting? Satu API key yang dipakai bersama oleh tim marketing, chatbot pelanggan, dan skrip uji coba developer membuat tagihan sulit dibaca. Saat biaya melonjak, kamu tidak tahu siapa penyebabnya. Lebih buruk lagi, satu skrip yang berputar tanpa henti bisa menghabiskan anggaran seluruh perusahaan dalam semalam.

Kenapa satu API key untuk semua itu berbahaya?

Ada tiga masalah yang biasanya muncul bersamaan:

  • Tidak ada atribusi biaya. Dasbor hanya menampilkan total, sehingga kamu tidak bisa menagih balik biaya ke divisi atau menilai aplikasi mana yang boros.
  • Satu kebocoran, semua kena. Kalau key bocor di repositori atau file .env, kamu harus mencabutnya dan semua aplikasi ikut mati. Pencegahannya dibahas di mencegah bocornya file .env dan API key.
  • Rate limit diperebutkan. Batas permintaan per menit berlaku untuk organisasi atau project. Skrip batch yang rakus bisa membuat chatbot pelanggan kena error 429 di jam sibuk.

Prinsipnya sederhana: satu tim atau satu aplikasi, satu wadah, satu key (atau beberapa key milik wadah itu).

Fitur pembatas yang sudah ada di konsol penyedia

Sebelum memasang alat tambahan, manfaatkan dulu yang disediakan penyedia. Penamaannya berbeda, tetapi konsepnya mirip.

Anthropic (Claude API): workspace

Per dokumentasi resmi yang dicek 7 November 2026, organisasi di Claude Console bisa membuat beberapa workspace. Setiap workspace punya anggota, API key, dan batasnya sendiri:

  • Spend limit: batas belanja bulanan per workspace, plus peringatan saat pemakaian mencapai ambang tertentu. Diatur dari halaman Workspaces di Console.
  • Rate limit: batas permintaan per menit, token input per menit, dan token output per menit, per model, untuk workspace yang dipilih.

Catatannya, spend limit tidak bisa dipasang di Default Workspace. Jadi buat workspace baru untuk setiap tim atau aplikasi, jangan menaruh semuanya di workspace bawaan.

OpenAI: project

Di platform OpenAI, wadahnya bernama project. Per panduan resmi mereka (dicek 7 November 2026), setiap project bisa diberi rate limit per model, misalnya jumlah permintaan per menit, dengan nilai yang tidak boleh melebihi batas organisasi. Project juga bisa diberi spend alert bulanan yang mengirim email saat ambang dolar tercapai.

Perhatikan bahwa panduan itu menyebut spend alert sebagai notifikasi, bukan penghenti otomatis. Artinya, alert memberi tahu kamu, tetapi permintaan tetap jalan. Kalau kamu butuh rem yang benar-benar menghentikan pemakaian, kombinasikan rate limit yang ketat dengan pemantauan, atau pakai gateway. Tampilan dan nama menu di konsol bisa berubah, jadi cek pengaturan terbaru di akunmu.

Kapan perlu gateway seperti LiteLLM?

Fitur bawaan cukup bila kamu hanya memakai satu penyedia dan jumlah timnya sedikit. Gateway mulai masuk akal bila:

  • Kamu memakai beberapa penyedia sekaligus (Claude, GPT, Gemini, model lokal) dan ingin satu tempat untuk mengatur semuanya.
  • Kamu butuh anggaran per API key atau per pengguna, bukan hanya per workspace.
  • Kamu ingin batas yang memblokir permintaan begitu anggaran habis.

Konsep gateway dijelaskan lebih lengkap di apa itu AI gateway. Salah satu pilihan open-source yang populer adalah LiteLLM Proxy. Menurut dokumentasinya, kamu bisa membuat tim dengan anggaran dan rate limit seperti ini:

curl -X POST 'http://localhost:4000/team/new' \
  -H 'Authorization: Bearer <master-key>' \
  -H 'Content-Type: application/json' \
  -d '{
    "team_alias": "tim-marketing",
    "max_budget": 50,
    "budget_duration": "30d",
    "tpm_limit": 100000,
    "rpm_limit": 60
  }'

Lalu buat virtual key untuk aplikasi milik tim tersebut:

curl -X POST 'http://localhost:4000/key/generate' \
  -H 'Authorization: Bearer <master-key>' \
  -H 'Content-Type: application/json' \
  -d '{"team_id": "<id-tim>", "max_budget": 20, "budget_duration": "30d"}'

max_budget dalam USD, dan budget_duration menentukan kapan anggaran direset (contoh 30d). Tanpa budget_duration, anggaran tidak pernah direset. Saat key melewati anggarannya, permintaan ditolak. Ada juga max_parallel_requests untuk membatasi permintaan serentak.

Perbandingan cara membatasi biaya

CaraTingkat pembatasanMemblokir saat habis?Cocok untuk
Workspace Anthropic + spend limitPer workspaceYa, sesuai batas bulananTim yang hanya memakai Claude
Project OpenAI + rate limitPer project, per modelRate limit ya, spend alert hanya notifikasiTim yang hanya memakai GPT
Gateway (contoh LiteLLM)Per tim, pengguna, atau keyYa, saat anggaran key atau tim habisBanyak penyedia, banyak aplikasi
Batas di kode aplikasiPer fitur atau per pengguna akhirTergantung implementasiAplikasi yang dipakai pelanggan

Langkah praktis menyusun kebijakan kuota

  1. Petakan pemakai. Daftar semua tim dan aplikasi yang memanggil API AI, termasuk skrip kecil dan alur otomasi.
  2. Buat wadah terpisah. Satu workspace atau project per tim atau aplikasi produksi. Pisahkan juga lingkungan uji coba dari produksi.
  3. Tentukan anggaran awal. Lihat pemakaian satu sampai dua bulan terakhir, lalu beri batas sedikit di atasnya. Mulai ketat, longgarkan bila perlu.
  4. Pasang rate limit. Aplikasi yang melayani pelanggan diberi prioritas, skrip batch diberi batas lebih rendah agar tidak merebut kapasitas.
  5. Atur alert bertingkat. Misalnya pada 50, 80, dan 100 persen anggaran, dengan penerima yang jelas di setiap tim.
  6. Tinjau bulanan. Bandingkan biaya dengan hasil. Fitur yang mahal tetapi jarang dipakai layak dioptimasi atau dihentikan.

Selain membatasi, kurangi juga kebutuhan tokennya. Caching prompt, memilih model yang lebih kecil untuk tugas ringan, dan memotong konteks yang tidak perlu sering memberi penghematan besar. Tekniknya ada di cara menghemat biaya token API AI.

Bagaimana dengan batas untuk pengguna akhir?

Kalau aplikasimu dipakai pelanggan (misalnya chatbot di website), batas per tim belum melindungi dari satu pengguna yang menyalahgunakan layanan. Tambahkan batas di sisi aplikasi: jumlah pesan per pengguna per hari, panjang input maksimal, dan batas max_tokens untuk jawaban. Simpan juga log pemakaian per pengguna agar pola yang aneh cepat terlihat.

Pertanyaan yang sering diajukan

Apakah spend alert sama dengan batas belanja?

Tidak selalu. Alert hanya memberi tahu saat ambang tercapai. Batas belanja (hard limit) menghentikan permintaan. Cek dokumentasi penyedia untuk tahu mana yang kamu pasang.

Perlukah gateway kalau hanya memakai satu penyedia?

Belum tentu. Bila workspace atau project bawaan sudah memberi batas yang kamu butuhkan, gateway hanya menambah satu komponen yang harus dirawat. Gateway berguna saat penyedia banyak atau butuh anggaran per key.

Apa yang terjadi pada aplikasi saat anggaran habis?

Permintaan akan ditolak dengan pesan error. Siapkan penanganan di aplikasi, misalnya pesan ramah ke pengguna atau beralih ke model cadangan yang lebih murah, supaya layanan tidak terlihat rusak.

Sumber & referensi

Baca juga