Bisakah permintaan Opus 5.5 dilayani oleh Opus 4.8?

Bisa. Catatan rilis Anthropic memuat catatan kaki yang menyatakan bahwa sebagian permintaan Opus 5.5 dapat dialihkan ke Opus 4.8 selama jendela transisi. Endpoint model adalah alias, bukan jaminan versi.

Bagaimana cara mengetahui model mana yang sebenarnya melayani permintaan?

Baca field model di badan respons API. Catat pada setiap panggilan dan pecah semua metrik biaya berdasarkan model yang di-resolve, bukan model yang diminta.

Apakah ini juga berlaku untuk model OpenAI?

Ya. Praktik alias dan transisi yang sama berlaku di semua penyedia, termasuk rilis GPT-6 Sol dan Luna pada 22 September 2026. Kunci ID model bertanggal untuk apa pun yang Anda anggarkan atau evaluasi.

Mengapa penghematan biaya per tugas saya lebih kecil dari klaim 40%?

Kemungkinan besar karena pencampuran versi. Klaim "40% lebih murah" adalah rata-rata beban kerja tipikal yang mengasumsikan pengurangan jumlah token. Jika model yang lebih murah tapi lebih lama menghasilkan jawaban lebih panjang, penghematan gabungan akan menyusut.

Downgrade model diam-diam dan model biaya

Diperbarui September 27, 2026 · pertama terbit September 27, 2026

Pada 23 September 2026, sebuah thread di r/GroundTruthAINews menunjuk catatan kaki yang terselip di catatan rilis Opus 5.5 dari Anthropic: permintaan Opus 5.5 bisa dilayani oleh Opus 4.8. Anthropic dan OpenAI sama-sama merilis pemotongan harga di sore hari yang sama. Kedua lab menjual gagasan yang sama: pertahankan kemampuan, belanjakan jauh lebih sedikit. Catatan kaki itulah yang penting bagi FinOps.

Apa yang sebenarnya terjadi

Claude Opus 5.5 diluncurkan dengan harga $4/$20 per juta token, sekitar 20% di bawah Opus 5, dengan pembacaan cache dipotong 60% menjadi $0.20. Anthropic menyatakan bahwa token yang lebih sedikit per tugas dan keluaran 30% lebih cepat membuat beban kerja tipikal sekitar 40% lebih murah. Sekitar 90 menit kemudian, OpenAI merilis GPT-6 Sol di $2/$10 dan Luna di $0.10/$0.50, keduanya setengah dari harga GPT-5.6.

Setiap pengumuman rilis dari periode ini memuat jenis catatan kaki yang sama: endpoint yang Anda panggil adalah sebuah alias, dan alias itu diseimbangkan bebannya ke beberapa versi model selama jendela transisi. Itu praktik kapasitas yang normal. Namun itu juga masalah untuk pemodelan biaya.

Mengapa ini merusak angka

Biaya per tugas bergeser. Prakiraan Anda mengasumsikan harga keluaran Opus 5.5. Jika sebagian panggilan jatuh ke 4.8, harga satuan dan jumlah token sama-sama berubah, dengan arah yang berlawanan.
Evaluasi mengukur campuran. Suite evaluasi yang dijalankan selama jendela transisi memberi skor pada gabungan beberapa versi. Skornya tidak bisa direproduksi nanti.
Pemotongan harga salah diatribusikan. Jika penghematan 40% hanya terlihat 15%, selisihnya biasanya karena pencampuran versi, bukan optimisasi yang rusak.
Baseline latensi menjadi usang. 4.8 tidak secepat 5.5. Setiap p50 yang Anda catat di tengah transisi bukan p50 kondisi tunak Anda.

Cara mendeteksi pergantian

Setiap penyedia besar mengembalikan model yang sudah di-resolve di badan respons. Catat. Satu field, empat baris kode:

resolved = response.model  # e.g. "claude-opus-4-8-20260115"
assert resolved.startswith(EXPECTED_PREFIX) or resolved in ALLOWED_FALLBACKS

Lalu pecah setiap metrik biaya berdasarkan model yang di-resolve, bukan model yang Anda minta. Begitu satu kelompok mulai bergeser, Anda sudah punya jawabannya: alias mencampur versi dan biaya per tugas Anda adalah rata-rata berbobot dari dua produk yang berbeda.

Implikasi untuk anggaran

Selama transisi, rencanakan berdasarkan biaya gabungan, bukan angka utama. Jika 20% panggilan turun ke model yang lebih lama, tarif input efektif Anda bukan $4.00 per juta — melainkan angka yang dihasilkan oleh campuran tersebut. Logika yang sama berlaku untuk klaim penghematan: "40% lebih murah" adalah rata-rata beban kerja tipikal yang sudah mengasumsikan pengurangan jumlah token, dan asumsi itu bisa tidak berlaku jika model yang lebih murah tapi lebih lama justru yang menghasilkan jawaban lebih panjang.

Aturan yang perlu dipegang

Jangan pernah memodelkan berdasarkan alias. Kunci ID model bertanggal untuk apa pun yang Anda anggarkan atau evaluasi.
Catat model yang di-resolve pada setiap permintaan. Wajib jika Anda pernah menjalankan ulang evaluasi.
Susun ulang baseline setelah jendela transisi. Durasinya biasanya minggu, bukan kuartal, tetapi pastikan.
Hitung transisi sebagai campuran. Minta penyedia Anda rasio yang diharapkan, atau ukur sendiri.

Kesimpulan

Pemotongan harga dan downgrade diam-diam bisa datang di sore hari yang sama. Pemotongan adalah judulnya; downgrade adalah catatan kaki yang diam-diam membatalkan prakiraan bulan lalu. Catat model yang di-resolve, kunci ID bertanggal, dan hitung campurannya.

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 →

Kembali ke finopsllm.com