Pemikiran adaptif dan prakiraan biaya
Diperbarui September 1, 2026 · pertama terbit September 1, 2026
Anggaran penalaran dulu berupa angka yang Anda tetapkan sendiri. Anda mengirim thinking: {type: "enabled", budget_tokens: N}, dan N sekaligus berfungsi sebagai kendali dan prakiraan: dalam skenario terburuk, setiap permintaan menghabiskan N token penalaran, sehingga tim keuangan bisa mengalikannya.
Parameter itu sudah usang di Opus 4.6 dan Sonnet 4.6, dan di model terbaru — Fable 5 dan 5.1, Sonnet 5, Opus 5, 4.8 dan 4.7 — mengirimkannya mengembalikan 400. Penggantinya adalah thinking: {type: "adaptive"}, di mana model memutuskan sendiri seberapa dalam berpikir berdasarkan tingkat kesulitan permintaan.
Secara rata-rata, ini menghasilkan output yang lebih baik per dolar. Namun ini juga berarti batas atas dihapus, dan jika prakiraan Anda dibangun di atas batas itu, prakiraan tersebut kini keliru dengan cara yang baru terlihat setelah bulan ditutup.
Apa yang berubah pada angka
Rata-rata biaya per permintaan biasanya turun, karena permintaan yang mudah tidak lagi membayar penalaran yang tidak mereka butuhkan. Varians naik, karena permintaan yang sulit tidak lagi terpotong di batas Anda. Keduanya bergerak berlawanan arah, dan anggaran yang dinyatakan sebagai maksimum per permintaan tidak lagi punya pijakan.
Kegagalan yang nyata bukan pada rata-rata, melainkan pada ekor distribusi: perubahan prompt, jenis dokumen baru, atau pengguna yang mulai mengajukan pertanyaan lebih sulit akan menggeser sebagian trafik ke penalaran yang lebih dalam, dan tidak ada yang di konfigurasi Anda membatasinya.
Perkirakan distribusinya, bukan batasnya
Tiga perubahan, diurutkan dari manfaat terbesar.
Lacak token penalaran sebagai seri tersendiri. Token itu sudah ada di objek usage pada setiap respons. Pisahkan dari input dan output di telemetri Anda, maka Anda bisa melihat pergeseran pada hari terjadinya, bukan pada akhir bulan.
Anggarkan berdasarkan persentil. Ganti "N token per permintaan" dengan p50 dan p99 per rute. P50 memberi tahu berapa biaya beban kerja Anda; selisih antara p50 dan p99 memberi tahu seberapa rentan Anda terhadap minggu yang buruk.
Beri peringatan pada rasio, bukan total. Token penalaran sebagai porsi dari total token per rute adalah angka tunggal yang bergerak paling awal ketika perubahan prompt membuat model bekerja lebih keras. Peringatan total biaya baru berbunyi berhari-hari kemudian, setelah volume menumpuk.
Di mana batas masih perlu ada
Menghapus kendali per permintaan tidak berarti menghapus semua batasan. Batas pengeluaran di tingkat rute dan tenant tetap berfungsi, tetap menangkap loop yang lepas kendali, dan kini di sanalah pagar pengaman seharusnya berada — di batas yang Anda miliki, bukan di dalam parameter permintaan yang sudah tidak ada. Untuk jalur yang sensitif terhadap latensi, di mana penalaran mendalam tidak pernah sepadan, tuasnya adalah pemilihan model, bukan batas token.
Terkait
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 →