Panduan Integrasi & Dokumentasi API

Semua cache tetap dipotong. Gateway menyesuaikan posisi cache sesuai kontrak usage provider agar cache tidak hilang dan tidak dihitung dua kali. Sebagai contoh, pada model promo ber-multiplier 0.8x, 1.000 billable token memotong 800 token dari kuota.

Mitos "1 Kata = 1 Token" pada Model AI Modern

Banyak pengguna berasumsi bahwa prompt sesingkat 1+1 hanya mengonsumsi 1 hingga 3 token. Pada kenyataannya, model LLM modern (terutama model penalaran/reasoning dan keluarga GLM), setiap permintaan dibungkus oleh instruksi format sistem yang tidak terlihat di antarmuka obrolan biasa.

Komponen pembentuk token input (prompt tokens) meliputi:

• Chat Template Delimiter (ChatML / Jinja): Tag perpesanan khusus seperti <|im_start|>system, <|im_start|>user, dan token penutup percakapan.
• Upstream System Prompt & Safety Guardrail: Pada model enterprise seperti GLM-4/GLM-5 (Zhipu AI) atau Claude, server model otomatis menyuntikkan arahan identitas asisten, tanggal sistem, instruksi keselamatan, dan pedoman pemformatan secara native. Injeksi ini menghasilkan baseline context overhead ~100 hingga 140 token untuk setiap sesi baru sebelum teks pengguna diproses.
• Reasoning & Tool Schema: Model dengan kapabilitas tool-calling atau chain-of-thought otomatis menyertakan definisi skema fungsi ke dalam konteks awal.

Masalah Industri: Tokenizer Mismatch & Inflasi Kuota

Mayoritas gateway pihak ketiga (seperti agregator berbasis One API atau New API) menggunakan estimasi tokenizer tunggal tiktoken (OpenAI BPE) untuk seluruh model yang mereka layani. Ketika memproses model non-OpenAI (GLM, Qwen, DeepSeek), tokenizer OpenAI memecah karakter dan template khusus secara tidak efisien, menyebabkan token input dihitung membengkak 20% hingga 37% lebih boros di log dashboard mereka (misal: prompt yang aslinya 132 token dicatat menjadi 181 token).

Praktik ini sering dimanfaatkan untuk mengklaim harga murah di awal, namun kuota pelanggan dipotong lebih cepat melalui penggelembungkan metrik token dasar.

Standar Akuntansi ruster9: Native Pass-Through

ruster9 memegang prinsip keterbukaan data tanpa manipulasi angka dasar:

• Native Pass-Through (Default): Gateway menangkap objek usage resmi langsung dari stream inference provider asli. Jika engine model melaporkan 132 token input dan 23 token output, angka riil tersebut yang tercatat di log tanpa mark-up fiktif.
• Multiplier Terbuka: Biaya komputasi upstream diakomodasi melalui pengali (multiplier) resmi di katalog model, bukan dengan menggelembungkan jumlah token pengguna secara diam-diam.
• Provider-Level Accounting: Mode prompt dapat memakai usage native atau BPE lokal. Semantik cache diatur sebagai termasuk dalam prompt, terpisah, atau tidak tersedia. Semua cache tetap dipotong sesuai kontrak provider tanpa double counting. Saat failover, aturan mengikuti provider yang benar-benar mengeksekusi request.

Prinsip Evaluasi & Skenario:

• Evaluasi Simultan (Logika AND): RPM dan TPM diperiksa bersamaan. Jika salah satu batas terlewati, gateway mengembalikan response HTTP 429 Too Many Requests beserta header atau pesan retry_after (detik tunggu sampai kuota sel terisi kembali).
• Skenario Prompt Besar (Kena Limit TPM): Mengirim serangkaian prompt besar secara beruntun dapat menghabiskan jatah 500.000 TPM. Request berikutnya akan ditolak sementara sampai kuota token terisi kembali (refill 8.333 token/detik), meskipun jatah RPM baru terpakai sebagian.
• Skenario Spam Prompt Pendek (Kena Limit RPM): Mengirim 60 pesan singkat dalam 15 detik menghabiskan jatah RPM. Request ke-61 akan ditolak sementara sampai sel request terisi kembali (refill 1 detik/request), meskipun pemakaian token baru ~3.000 dari jatah 500.000 TPM.
• Skenario Batas Concurrent Stream: Jika 2 request inferensi sedang berlangsung secara simultan pada satu API Key, koneksi ke-3 wajib menunggu hingga salah satu stream menyelesaikan output pertamanya.

Kebijakan Penyimpanan Data & Privasi (ZDR Policy):

1. Zero Payload Logging: ruster9.id tidak menyimpan, tidak merekam, dan tidak menggunakan prompt pengguna maupun teks balasan AI untuk pelatihan model (no training on user data). Seluruh pemrosesan berjalan secara in-memory streaming langsung ke upstream compute engine tanpa jejak payload di database atau disk.
2. Operational Metadata: Data yang dicatat terbatas pada: ID Kunci API, stempel waktu (timestamp), ID Model/Provider, jumlah token (input, output, cache), latensi jaringan (ms), dan kode status HTTP guna perhitungan saldo, penagihan faktur, dan deteksi anomali jaringan.
3. Transit Encryption: Seluruh data dalam transit dienkripsi menggunakan protokol standar industri (TLS 1.3 / HTTPS) dengan enkripsi end-to-end baik pada layer klien maupun koneksi ke upstream provider.