
Jendela Konteks GPT-6.1 Sol: 1.050.000 Token, Garis 922.000, dan Jurang 272.000
- openaiBARUOpenAI: GPT-6.1 Sol2026-09-2952Kecerdasan
- anthropicBARUAnthropic: Claude Sonnet 5.52026-09-2856Kecerdasan
- typesafeTypeSafe: Jev 1.132026-09-24$0.04 / $0.00 per 1 juta token · 111 tok/s
- OpenAIOpenAI: GPT-6 Luna2026-09-2238Kecerdasan
- OpenAIOpenAI: GPT-6 Sol2026-09-2248Kecerdasan
- AnthropicAnthropic: Claude Opus 5.52026-09-2258Kecerdasan
- xAIGrok 4.72026-09-2146Kecerdasan
- OrcaOrca: OrcaCyber Zero 1.02026-09-17$3.00 / $7.50 per 1 juta token · 55 tok/s
- OrcaOrca: OrcaVerify Text 1.02026-09-16$2.00 / $0.00 per 1 juta token · 347 tok/s
- DeepSeekDeepSeek: DeepSeek V4.1 Flash2026-09-1040Kecerdasan
- OpenAIOpenAI: GPT-6 Astra2026-09-0453Kecerdasan77Koding
- GoogleGoogle: Gemini 3.8 Flash2026-09-0241Kecerdasan76Koding
- AlibabaQwen: Qwen3.8 Max (0902)2026-09-0245Kecerdasan76Koding
- AnthropicAnthropic: Claude Fable 5.12026-09-0153Kecerdasan82Koding
- TencentTencent: Hy4 preview2026-08-28$0.83 / $2.50 per 1 juta token · 60 tok/s
- AlibabaQwen: Qwen3.8 Flash2026-08-26$0.15 / $0.47 per 1 juta token · 377 tok/s
- z-aiZ.ai: GLM 5.3 Flash2026-08-2642Kecerdasan72Koding
- DeepSeekDeepSeek: DeepSeek V4 Flash Vision (Exp)2026-08-21$0.22 / $0.66 per 1 juta token · 231 tok/s
- z-aiZ.ai: GLM 5.32026-08-1845Kecerdasan75Koding
- obsidianQwen3.8 27B2026-08-1534Kecerdasan68Koding
Halaman model vendor untuk GPT-6.1 Sol, dibaca pada 7 Oktober 2026, menyatakan jendela konteks 1.050.000 token dan output maksimum 128.000 token. Halaman yang sama, dalam bentuk yang dapat dibaca mesin yang Anda peroleh dengan menambahkan .md ke URL-nya, memuat angka ketiga yang tidak pernah dicetak oleh halaman yang dirender: maksimum 922.000 token masukan. GPT-6 Sol, model yang hendak digantikan oleh 6.1 yang dirilis pada 2026-09-29, menerbitkan pasangan angka batas atas yang identik di halamannya sendiri, dan baris 922.000 yang sama dalam bentuk markdown-nya sendiri. Kartu model kami sendiri untuk openai/gpt-6-sol melaporkan jendela sebagai 1.050.000 token dan batas output sebagai 128.000, menampilkan angka pertama sebagai "1M" di strip spesifikasinya, dan mencetak "1.1M" untuk model yang sama dalam tabel perbandingan yang lebih ke bawah di halaman yang sama.
Jadi halaman-halamannya memang tidak sepakat, dan penting untuk tepat mengenai bagaimana. strip spesifikasi yang dirender vendor memberikan sebuah jendela dan plafon output dan tidak ada plafon input. dokumentasi markdown vendor untuk model yang sama memberikan ketiganya. Siapa pun yang menentukan ukuran permintaan berdasarkan halaman yang dirender bekerja dengan satu batasan lebih sedikit daripada yang diterbitkan vendor, dan yang hilang adalah angka yang menentukan apakah suatu permintaan muat.
Tiga angka, tiga sumber, dan satu pengurangan yang tidak dituliskan siapa pun
Berikut adalah setiap nomor beserta dokumen asalnya, semuanya dibaca pada 7 Oktober 2026.
• jendela konteks 1,050,000 — halaman model vendor untuk gpt-6.1-sol, dalam strip spesifikasi yang dirender dan dalam bentuk markdown-nya, dan angka yang sama di halaman untuk gpt-6-sol. Itu juga yang dikembalikan katalog kami untuk openai/gpt-6-sol dan openai/gpt-6-luna, di mana bidang tersebut dituliskan sebagai 1,050,000 alih-alih dibulatkan.
• maksimal 128.000 token keluaran — halaman yang sama, dua formulir yang sama, untuk kedua generasi. Kolom di kartu kami menyebutkan 128.000; tampilannya dibulatkan menjadi "128K".
• maksimum 922.000 token input — bentuk markdown dari halaman model gpt-6-sol milik vendor dan halaman gpt-6.1-sol-nya. Itu tidak ada di strip yang dirender dari kedua halaman tersebut, dan tidak ada di bidang katalog kami untuk model tersebut, yang berhenti pada jendela dan batas output.
Ketiga angka tersebut konsisten secara aritmetika satu sama lain: 922.000 ditambah 128.000 sama persis dengan 1.050.000. Panduan penalaran milik vendor itu sendiri menjelaskan mekanisme yang membuat kesamaan itu bermakna tanpa pernah melakukan penjumlahan di halaman model — token penalaran, katanya, "masih menempati ruang di jendela konteks model", dan jika token yang dihasilkan "mencapai batas jendela konteks atau nilai max_output_tokens yang Anda tetapkan", respons yang dikembalikan ditandai tidak lengkap. Jendela yang dibagi antara apa yang masuk dan apa yang keluar adalah jendela yang batas atas inputnya adalah jendela dikurangi reservasi output.
Pembacaan itu didukung, bukan dibuktikan, dan ada baiknya kedua hal itu dipisahkan. Yang terdokumentasi adalah jendela 1.050.000, batas keluaran 128.000, dan masukan maksimum 922.000. Yang disimpulkan adalah mana di antara itu yang menjadi kendala yang berlaku lebih dulu. Inferensi tersebut berlaku untuk setiap permintaan yang mencadangkan seluruh jatah keluarannya dan tidak berlaku untuk permintaan mana pun yang tidak melakukannya — setel max_output_tokens ke 4.000 dan 1.046.000 token masukan tidak secara jelas ditolak. Sampai vendor menuliskan pengurangan itu ke halaman tempat angka-angka itu berada, perlakukan pasangan tersebut sebagai bentuk anggaran, bukan sebagai aturan penerimaan yang ketat, dan validasi terhadap endpoint penghitungan, bukan terhadap pos blog.
Konteks bukan harga: langkah 272.000 token
Jendela yang lebih besar adalah klaim kapasitas. Itu bukan klaim biaya, dan pada keluarga ini keduanya berpisah pada garis yang terdokumentasi. Halaman harga vendor menyatakan aturan itu dalam satu kalimat: prompt dengan lebih dari 272K token masukan dikenakan harga 2x tarif input dan cache serta 1,5x output untuk keseluruhan permintaan. Definisi halaman yang sama untuk kedua kolomnya sendiri adalah "Konteks pendek: ≤272K token masukan. Konteks panjang: >272K token masukan."
Baca kata full dengan saksama. Tingkat tersebut tidak mengenakan pajak pada token yang melewati garis — tingkat tersebut menetapkan ulang harga untuk semuanya, termasuk token pertama. Dan ini bukan perubahan 6.1: aturan yang identik, dengan ambang batas yang identik, berlaku untuk GPT-6 Sol, itulah sebabnya jurang harus dikaitkan dengan tingkat dan bukan dengan rilis.
Kerjakan satu pekerjaan konteks panjang melalui kedua sisi, berdasarkan tarif yang dipublikasikan GPT-6.1 Sol, dengan prefiks sudah berada di cache sehingga biaya penulisan cache tidak mengaburkan perbandingan:
• 240,000 token masukan (200,000 di-cache, 40,000 baru), 6,000 keluaran — masukan baru 40,000 dengan $2.00 per juta adalah $0.080; masukan di-cache 200,000 dengan $0.10 adalah $0.020; keluaran 6,000 dengan $10.00 adalah $0.060. Total, $0.160.
• 300.000 token masukan (260.000 di-cache, 40.000 baru), 6.000 keluaran — permintaan kini berada di atas ambang, jadi setiap tarif berubah: masukan baru 40.000 dengan $4,00 adalah $0,160; masukan di-cache 260.000 dengan $0,20 adalah $0,052; keluaran 6.000 dengan $15,00 adalah $0,090. Total, $0,302.
Dua puluh lima persen lebih banyak token masukan menghasilkan tagihan 89 persen lebih besar. Jalankan pasangan yang sama pada GPT-6 Sol dan polanya tetap berlaku dengan kemiringan yang lebih curam — $0,180 di bawah garis versus $0,354 di atasnya, karena tarif cache kartu lama sebesar $0,20 berada di posisi yang sama dengan tarif cache konteks panjang milik 6.1. Titik persilangannya adalah lompatan, bukan kemiringan, dan cara termurah untuk melihatnya adalah melintasinya dengan selisih sangat tipis. Permintaan 271.000 token yang sepenuhnya tanpa cache dengan 1.000 token keluaran berbiaya $0,552; pada 273.000 token, biayanya $1,107. Tujuh persepuluh persen lebih banyak token masukan, 2,01 kali biayanya. Pangkas 2.000 token dari permintaan itu dan tagihannya turun dari $1,107 menjadi $0,552 — kurang dari satu persen masukan untuk separuh biaya.
Tidak ada apa pun di bagian ini yang membahas tentang besarnya jendela GPT-6.1 Sol. Ini tentang jendela yang cukup besar untuk mencapai batas yang biayanya melebihi apa yang dapat diperoleh dari ukuran jendela tersebut.

Apa yang sebenarnya mengisi 1.050.000 token
Anggaran konteks terdiri dari enam hal, dan tidak semuanya dapat di-cache secara setara. Perkiraan porsi dari contoh permintaan agentic sebesar 240.000 token; proporsinya milik kami sendiri, aturan kemampuan cache-nya milik vendor, yang diambil dari panduan prompt caching-nya yang dibaca pada hari yang sama.
• Konten sistem yang disuntikkan oleh penyedia dan pemformatan permintaan — dirender sebelum pesan Anda, ditagih sebagai input, dan secara eksplisit dikecualikan dari panjang minimum yang dapat di-cache. Bukan Anda yang mengendalikannya, dan bukan Anda yang memangkasnya.
• Instruksi pengembang dan sistem Anda, sekitar 6.000 token. Dapat di-cache. Ini adalah bagian depan dari prefiks, jadi perubahan di sini membatalkan semua yang ada di belakangnya.
• Definisi dan skema alat, sekitar 14.000 token untuk permukaan alat yang dihosting beserta fungsi Anda. Dapat di-cache, dan bagian paling rapuh dari prefiks: panduan ini mencantumkan nama alat, deskripsi, skema, urutan, dan instruksi khusus alat sebagai hal-hal yang menggeser batas prefiks.
• Korpus yang diambil, sekitar 180.000 token. Dapat di-cache, dan sejauh ini merupakan baris terbesar. Layak di-cache hanya jika stabil secara byte antar panggilan — korpus yang dirakit ulang per permintaan adalah korpus dengan harga penuh.
• Transkrip yang terakumulasi — giliran percakapan dan hasil alat sebelumnya — sekitar 30.000 token dan terus bertambah. Dapat di-cache hingga perubahan terbaru; hasil alat yang tiba pada giliran ini adalah input baru dengan tarif penuh.
• Token penalaran — dihasilkan, tidak pernah di-cache, ditagih sebagai output. Mereka mengonsumsi jendela dan tidak terlihat di badan respons.
Dua catatan operasional langsung muncul dari daftar itu. Pertama, entri cache disimpan pada masing-masing mesin: panduan menyatakan bahwa sebuah permintaan dapat menggunakan kembali sebuah prefiks "hanya jika permintaan itu mencapai mesin yang menyimpan entri yang cocok yang belum kedaluwarsa", dan bahwa perutean overflow dimulai di atas sekitar 15 permintaan per menit. Prefiks yang stabil di kode Anda tetap dapat mengalami cache miss di produksi. Kedua, prefiks minimum yang dapat di-cache adalah 1.024 token input yang terlihat, dan token sistem tersembunyi tidak diperhitungkan ke dalamnya — jadi prompt sistem yang kecil bukan prefiks yang dapat di-cache, tidak peduli seberapa besar permintaan di sekitarnya.
Plafon keluaran adalah anggaran terpisah, bukan porsi tambahan.
128.000 token output maksimum tidak berarti 128.000 token jawaban. Panduan penalaran secara eksplisit menyatakan bahwa max_output_tokens membatasi total yang dihasilkan model, "termasuk token penalaran, token output yang terlihat, dan token pemformatan yang tidak terlihat", dan bahwa token penalaran ditagih sebagai output sekaligus menempati ruang dalam jendela.
Hal itu menjadikan pemotongan sebagai keputusan desain, bukan kasus tepi, karena cara kegagalannya. Saat generasi mencapai batas, respons dikembalikan dengan status incomplete dan alasan berupa max_output_tokens — dan panduan memperingatkan bahwa hal ini "dapat terjadi sebelum ada token output yang terlihat dihasilkan, yang berarti Anda dapat menanggung biaya untuk token masukan dan penalaran tanpa menerima respons yang terlihat." Anggaran yang menghabiskan seluruh jendela untuk masukan dan membiarkan reservasi output bergantung pada keberuntungan adalah anggaran yang dapat menagih permintaan konteks panjang penuh dan tidak mengembalikan apa pun yang dapat diurai oleh pemanggil. Rekomendasi awal dari vendor itu sendiri adalah menyisihkan setidaknya 25.000 token untuk penalaran dan output selagi Anda masih mengukur apa yang sebenarnya dibutuhkan oleh sebuah prompt.
GPT-6.1 Sol mempertajam hal ini, dan ini adalah salah satu dari sedikit baris yang benar-benar spesifik untuk 6.1 dalam rilis tersebut. Tangga upaya penalarannya meliputi low, medium, high, xhigh, dan max, sedangkan pengaturan none dan minimal tidak didukung. GPT-6 Sol menerima keenamnya. Karena itu, tidak ada pengaturan di 6.1 yang mematikan pengeluaran penalaran, bawaannya adalah medium, dan sisi keluaran dari anggaran tersebut tidak pernah gratis.
Pemotongan separuh input yang di-cache, dibaca di mana jendelanya paling lebar.
Satu-satunya tarif pada kartu GPT-6.1 Sol yang bergerak berlawanan dengan GPT-6 Sol adalah input cache: dari $0,20 turun menjadi $0,10 per juta token, yang dinyatakan halaman model sebagai 5% dari tarif input tanpa cache, dan yang disebutkan secara eksplisit oleh panduan caching vendor sebagai kasus 0,05x dibandingkan 0,1x yang dibaca oleh sebagian besar model GPT-5.6 dan yang lebih baru. Input, penulisan cache, dan output identik pada kedua kartu, dan pengali konteks panjang juga identik.
Untuk beban kerja yang persis dibahas di halaman ini, itulah meter yang tepat untuk digerakkan, dan alasannya adalah komposisi permintaan yang panjang, bukan ukurannya. Pada pekerjaan 300.000 token di atas, 260.000 dari token masukan adalah prefiks yang di-cache — 87 persen dari semua yang dikirim permintaan. Karena itu, baris yang di-cache adalah meter masukan tunggal terbesar dalam tagihan, yang merupakan sifat umum pekerjaan konteks panjang: makin panjang jendela yang Anda gunakan, makin besar bagiannya yang berupa prefiks yang sudah Anda kirim. Memangkas separuh meter itu bernilai $0,052 pada permintaan tersebut.
Dan tebing itu mengambil kembali lebih banyak daripada yang diberikan oleh pemotongan setengah, pada permintaan yang sama. Jika dihargai dengan tarif konteks pendek yang akan dibayarkannya di bawah garis, pekerjaan 300.000 token yang sama pada GPT-6.1 Sol akan berbiaya $0.166 alih-alih $0.302 — biaya penyeberangan sebesar $0.136, atau sekitar 2,6 kali nilai dari satu meter yang diubah dalam rilis ini. Di atas garis, tarif cache terbaca $0.20, yang bukan angka baru pada keluarga ini: itu dua kali lipat dari harga utama pada kartu 6.1 dan persis seperti yang dikenakan GPT-6 Sol untuk pembacaan cache di bawah garis sebelum rilis ini. Beban kerja cache konteks panjang mengumpulkan perubahan harga utama dan kemudian mengembalikannya di batas, dan batas — bukan model — adalah penyebabnya.

Cara menentukan ukuran anggaran konteks
Sebagai prosedur, dalam urutan kendala-kendala yang mengikat:
• Hitung permintaan itu, jangan mengestimasinya. POST payload persisnya — alat, gambar, berkas, dan semuanya — ke endpoint penghitungan token input di Responses API. Panduan itu blak-blakan tentang alasannya: penghitungan mencakup token pemformatan untuk peran pesan dan batas yang tidak pernah muncul dalam teks yang dapat Anda tokenkan secara lokal, dan estimasi lokal seperti karakter dibagi empat tidak akurat untuk gambar, berkas, dan skema.
• Cadangkan sisi output terlebih dahulu. Pilih max_output_tokens dengan mengingat bahwa itu mencakup penalaran, output yang terlihat, dan pemformatan sekaligus, lalu mulailah dari buffer 25.000 token milik vendor, bukan dari nol. Anggaran input Anda adalah jendela dikurangi reservasi tersebut, dan angka sembilan ratus dua puluh dua itu adalah versi vendor dari pengurangan yang sama.
• Hitunglah permintaan di kedua sisi 272.000 sebelum Anda mengirimkannya. Lompatan ini cukup besar sehingga permintaan yang dirancang untuk mendarat tepat di bawah garis dan permintaan yang dirancang untuk mendarat tepat di atasnya adalah produk yang berbeda.
• Urutkan prefiks berdasarkan stabilitas. Instruksi, lalu skema alat, lalu korpus, lalu transkrip. Apa pun yang berubah antar panggilan sebaiknya diletakkan di akhir, di mana itu hanya mengorbankan kecocokan prefiks, bukan keseluruhan cache.
• Lampaui 1.024 token input yang terlihat sebelum mengharapkan cache.Di bawah minimum itu tidak ada yang di-cache, dan token penyedia yang tersembunyi tidak dihitung ke dalamnya.
• Periksa apakah penggunaan ulang masuk akal. Sebuah prefiks harus digunakan kembali dalam masa aktif cache 30 menit dan harus berada di mesin yang menyimpan entri tersebut; keduanya dijelaskan dalam panduan dan tidak satu pun merupakan properti dari kode Anda.
• Ukur ulang setelah setiap perubahan model atau pengaturan. Beralih ke GPT-6.1 Sol menghapus posisi penalaran nonaktif, yang mengubah jumlah token penalaran dan karenanya sisi keluaran dari anggaran — dan perubahan pada upaya penalaran, alat, skema keluaran terstruktur, atau manajemen konteks juga dapat menggeser batas prefiks dan membuat Anda kehilangan tarif cache sepenuhnya.
• Putuskan apa yang terjadi ketika pekerjaan tidak akan menyusut. Compaction adalah jalan keluar yang didokumentasikan: permintaan Responses dapat menetapkan context_management dengan ambang batas compact, dan server menggantikan konten percakapan sebelumnya dengan item compaction buram yang membawa status penting ke depan dalam token yang lebih sedikit. Ini adalah keputusan anggaran, bukan pemangkasan gratis, karena panduan mencatat bahwa compaction "dapat mencegah penggunaan ulang dari token yang berubah pertama dan seterusnya" — satu proses compaction membatalkan prefiks di belakangnya.

Aritmetika di halaman ini dimulai dari generasi yang digantikan oleh GPT-6.1 Sol, dan tingkat itulah yang dapat dipanggil hari ini: kartu kami untuk openai/gpt-6-sol melaporkan jendela konteks 1.050.000 token dengan output maksimum 128.000 token pada tarif daftar OpenAI tanpa markup atau 0% — harga dari vendor adalah harga yang tertera di halaman, dan perubahan dari vendor langsung berlaku di sana pada hari yang sama, bukan pada saat perpanjangan. Kartu kami tidak mencantumkan bidang input maksimum tersendiri, sehingga angka 922.000 token untuk model tersebut harus bersumber dari dokumentasi vendor itu sendiri, dan itulah yang digunakan halaman ini secara konsisten. Kegunaan kartu ini adalah untuk penetapan ukuran: jendela konteks dan plafon output yang diterbitkannya adalah dua angka yang saling dikurangkan dalam prosedur anggaran di atas, dan tingkat di bawahnya adalah yang benar-benar dapat Anda jalankan prosedur tersebut terhadapnya selagi 6.1 masih baru. Alamatnya ada di https://www.orcarouter.ai/models/openai/gpt-6-sol.
Dibandingkan dalam artikel ini1
Terdeteksi dari artikel ini · Benchmark: Artificial Analysis · diperbarui setiap hari
