Memahami RPM, ITPM, OTPM: Panduan Rate Limit API

Kebanyakan API AI hanya punya satu rate limit: requests per minute. Neosantara menggunakan sistem rate limiting 3 dimensi (RPM, ITPM, OTPM) yang memberikan kontrol lebih halus atas throughput, mencegah lonjakan biaya tak terduga, dan memastikan alokasi resource yang adil untuk semua user.

Kalau kamu pernah kena error 429 dan bingung kenapa, panduan ini menjelaskan persis arti setiap limit, cara mereka berinteraksi, dan cara memaksimalkan throughput di dalamnya.

#Apa Itu RPM, ITPM, dan OTPM?

Provider API tradisional kasih satu angka: "500 requests per minute." Simpel tapi kasar. Request klasifikasi satu kalimat dan analisis dokumen 100K token sama-sama dihitung satu request, padahal konsumsi resource-nya jauh berbeda.

Neosantara membagi rate limiting ke tiga dimensi independen:

Setiap limit menggunakan algoritma sliding window (RPM) atau token bucket (ITPM/OTPM), di-enforce per-user via Redis. Saat satu dimensi mana pun mencapai batas, request mengembalikan HTTP 429 dengan header yang memberitahu persis limit mana yang kena dan kapan reset.

#Bagaimana Ketiga Limit Berinteraksi

Bayangkan seperti jalan tol dengan tiga gerbang. Request kamu harus lolos ketiganya:

Request Kamu
    │
    ▼
┌─────────┐     ┌─────────┐     ┌─────────┐
│  RPM    │ ──▶ │  ITPM   │ ──▶ │  OTPM*  │ ──▶ Model
│ Check   │     │ Check   │     │ Settle  │
└─────────┘     └─────────┘     └─────────┘
                                 * diselesaikan setelah respons

RPM dicek pertama: apakah jumlah request kamu menit ini sudah melebihi batas?

ITPM dicek kedua: apakah input kamu (system prompt + messages + tools) melebihi budget token untuk menit ini?

OTPM itu spesial: dia diselesaikan setelah respons selesai, karena panjang output belum diketahui saat request masuk. Kalau kumulatif output kamu menit ini melebihi batas OTPM, request berikutnya yang akan diblok sampai window reset.

#Rate Limit per Tier

Neosantara menawarkan beberapa tier, masing-masing dengan limit yang semakin tinggi. Semua tier PAYG (Pay-As-You-Go) menggunakan billing berbasis saldo dalam Rupiah.

#Tier Coding Plan Bekerja Berbeda

Langganan flat-fee Coding Plan (untuk tools seperti Claude Code, Cline, Continue) tidak memakai RPM/ITPM/OTPM sama sekali. Sebagai gantinya, ada 2 mekanisme terpisah:

1. Concurrency limit — jumlah maksimum request yang berjalan bersamaan (in-flight)
2. Kuota prompt — budget rolling 5 jam dan mingguan, di mana setiap prompt bisa memakan 1-3x kuota tergantung load model

Ini mirip pendekatan GLM: bukan hard cap per-menit, plan ini membatasi berapa banyak request yang bisa berjalan bersamaan, lalu hard-stop begitu budget prompt rolling kamu habis. Tidak ada overage, tidak ada potong saldo — Coding Plan tidak pernah menyentuh saldo PAYG kamu.

#Apa yang Terjadi Saat Kena Limit?

Saat limit mana pun terlampaui, Neosantara mengembalikan respons 429 Too Many Requests dengan header detail:

HTTP/1.1 429 Too Many Requests
x-neosantara-ratelimit-requests-limit: 50
x-neosantara-ratelimit-requests-remaining: 0
x-neosantara-ratelimit-requests-reset: 2026-07-06T02:16:00.000Z
x-neosantara-ratelimit-input-tokens-limit: 500000
x-neosantara-ratelimit-input-tokens-remaining: 487231
x-neosantara-ratelimit-output-tokens-limit: 80000
x-neosantara-ratelimit-output-tokens-remaining: 72104

Di contoh ini, RPM mencapai nol sementara ITPM dan OTPM masih punya budget. Kamu tahu persis limit mana yang jadi bottleneck.

#Refund Saldo Otomatis

Kalau kamu pakai billing PAYG dan request kena rate-limit, Neosantara otomatis refund saldo yang sudah di-reserve. Kamu tidak pernah bayar untuk request yang tidak selesai. Refund terjadi instan dengan deskripsi "Refund: Rate Limit Blocked" di history transaksi kamu.

#Cara Optimasi Throughput

#1. Batch request kecil jadi satu

Kalau kamu buat banyak request kecil (klasifikasi, ekstraksi), kamu akan kena RPM sebelum ITPM. Pertimbangkan pakai Batch API untuk submit ratusan request dalam satu panggilan.

#2. Kurangi pemborosan input token

System prompt besar memakan budget ITPM di setiap request. Strategi:

• Gunakan prompt caching untuk menghindari pengiriman ulang konteks berulang
• Trim conversation history ke pesan yang relevan saja
• Pindahkan instruksi statis ke system prompt yang lebih pendek

#3. Kontrol panjang output

Set max_tokens secara tepat. Kalau kamu cuma butuh klasifikasi ya/tidak, set max_tokens: 10 daripada biarkan default model (4.096+). Ini menghemat budget OTPM kamu.

#4. Gunakan model routing secara strategis

Task sederhana yang diroute ke DeepSeek V4 Flash biasanya lebih cepat, artinya respons balik lebih cepat dan utilisasi per-menit kamu tetap rendah.

#5. Implementasi exponential backoff

Saat menerima 429, baca header reset dan tunggu sampai timestamp tersebut. Jangan retry langsung.

import time
from openai import OpenAI, RateLimitError

client = OpenAI(
    base_url="https://api.neosantara.xyz/v1",
    api_key="nst-key-kamu"
)

def call_with_backoff(messages, max_retries=3):
    for attempt in range(max_retries):
        try:
            return client.chat.completions.create(
                model="deepseek-v4-flash",
                messages=messages
            )
        except RateLimitError as e:
            wait = 2 ** attempt  # 1s, 2s, 4s
            print(f"Rate limited. Tunggu {wait}s...")
            time.sleep(wait)
    raise Exception("Max retry terlampaui")

#Monitoring Penggunaan

Dashboard Neosantara menampilkan konsumsi rate limit secara real-time. Setiap respons juga menyertakan sisa budget di header, jadi kamu bisa bangun awareness di sisi client:

response = client.chat.completions.create(
    model="claude-sonnet-4-6",
    messages=[{"role": "user", "content": "Halo"}]
)

# Cek sisa budget dari response header
print(f"RPM tersisa: {response.headers.get('x-neosantara-ratelimit-requests-remaining')}")
print(f"ITPM tersisa: {response.headers.get('x-neosantara-ratelimit-input-tokens-remaining')}")

#Pertanyaan yang Sering Ditanyakan

#Apakah rate limit reset di awal setiap menit?

Tidak. Neosantara menggunakan sliding window untuk RPM dan token bucket untuk ITPM/OTPM. Artinya limit terisi ulang secara kontinu, bukan reset di batas jam. Burst di 12:00:30 tidak akan tiba-tiba unlock di 12:01:00.

#Limit per API key atau per user?

Untuk API PAYG standar, limit diterapkan per API key — setiap key punya budget RPM/ITPM/OTPM sendiri di tier akun kamu. Kalau kamu punya 3 key dan tier-mu mengizinkan 50 RPM, setiap key punya 50 RPM masing-masing, bukan pool bersama. Pengecualiannya adalah endpoint MCP (/v1/mcp), di mana ada limit agregat per-user yang berlaku di atas limit per-key.

#Bisa dapat limit lebih tinggi?

Ya. Upgrade tier kamu lewat dashboard Neosantara. Limit Enterprise (4.000 RPM, 10M ITPM) tersedia untuk aplikasi high-volume.

#Kenapa OTPM diselesaikan setelah respons?

Karena model belum menghasilkan output saat request tiba. Neosantara bisa cek RPM dan estimasi ITPM di awal, tapi OTPM baru diketahui setelah generasi selesai. Kalau OTPM kamu habis, respons yang sedang berjalan tetap selesai (kamu tidak pernah dipotong di tengah stream), tapi request berikutnya akan diblok sampai window terisi ulang.

#Apakah limit Coding Plan bertumpuk dengan PAYG?

Tidak. User Coding Plan beroperasi di bawah concurrency limit dan kuota prompt rolling langganan mereka (bukan RPM/ITPM/OTPM). Kalau kamu juga punya saldo PAYG, itu digunakan untuk model di luar daftar yang diizinkan plan, di bawah rate limit standar tier dasar kamu.

#Kesimpulan

Rate limiting 3 dimensi Neosantara memberikan akses yang predictable dan adil ke model AI:

• RPM mencegah connection storm
• ITPM mencegah penyalahgunaan context window
• OTPM mencegah lonjakan compute generasi berat

Ketiganya memastikan aplikasi kamu scale mulus dari prototipe ke produksi. Monitor penggunaan via response header dan dashboard, implementasi backoff saat 429, dan gunakan Batch API untuk workload yang tidak butuh respons real-time.

Siap mulai? Dapatkan API key →

Sumber:

• Dokumentasi API Neosantara, "Rate Limits", https://docs.neosantara.xyz/en/rate-limits
• Anthropic, "Rate Limits (update Mei 2026)", https://docs.anthropic.com/en/api/rate-limits
• Upstash, "Rate Limiting with Redis", https://upstash.com/docs/oss/sdks/ts/ratelimit