OpenAI memperkecil ukuran konteks model Codex dari 372k menjadi 272k

 (github.com/openai)
1 poin oleh GN⁺ 19 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • OpenAI mem-backport perubahan yang mengurangi ukuran konteks model dari 372k menjadi 272k ke branch release/0.144 saat memperbarui metadata model bundle OpenAI Codex
  • PR #33972 memindahkan perubahan dari branch agent/hotfix-0.144-model-metadata ke rilis Codex 0.144
  • Cakupan perubahan hanya 1 file JSON, dan statistik diff adalah 64 baris ditambahkan · 54 baris dihapus
  • Perubahan digabungkan tanpa percakapan atau ulasan terpisah, melalui 1 commit dan 36 pemeriksaan
  • Pada halaman yang diberikan, file diff tidak dimuat sehingga detail perubahan metadata selain pengurangan konteks tidak dapat dipastikan

Tujuan dan cakupan perubahan

  • Judul PR menunjukkan bahwa pekerjaan ini adalah mem-backport metadata model bundle yang diperbarui ke Codex 0.144
  • Menurut judul di Hacker News, ukuran konteks model diperkecil dari 372k menjadi 272k
  • Branch tujuan adalah openai:release/0.144, dan branch sumber adalah sayan-oai:agent/hotfix-0.144-model-metadata

Hasil penggabungan

  • PR #33972 terdiri dari 1 commit, b06f4fa
  • Judul commit adalah Backport refreshed bundled model metadata
  • Digabungkan pada 18 Juli 2026, dengan 36 pemeriksaan dan 1 file yang diubah
  • Besar perubahan adalah 64 baris ditambahkan dan 54 baris dihapus, dengan format file JSON

Batasan yang dapat dikonfirmasi

  • Area file dan komentar pada halaman menunjukkan galat pemuatan, sehingga diff JSON yang sebenarnya tidak dapat diperiksa dari isi yang diberikan
  • Langkah reproduksi, alasan perubahan, dampak kompatibilitas, dan umpan balik ulasan tidak disertakan dalam isi

Bacaan terkait

1 komentar

 
GN⁺ 19 jam lalu
Opini Hacker News

  • Banyak yang bilang ini bisa diatasi dengan kompresi, tetapi untuk pekerjaan yang saya lakukan, detail yang hilang karena kompresi terlalu banyak
    Mungkin tidak masalah jika rencananya sederhana atau tidak ada pembahasan yang sangat rinci, tetapi karena kurangnya konteks panjang, pada akhirnya saya tetap memakai Anthropic
    Saat harus mengingat sepenuhnya banyak paper atau materi besar dan kompleks, konteks selalu mentok di 16%. Setelah ngobrol sekitar 5 menit, konteks dikompresi, lalu proses memasukkan ulang materi hingga mencapai 16% terulang lagi
    Konteks 372k juga tidak sempurna, tetapi sangat membantu karena menambah ruang longgar dari 12~20% menjadi sekitar 40%

    • Kompresi otomatis tidak bisa dimatikan dan juga tidak bisa kembali ke riwayat percakapan sebelum kompresi, jadi Codex tidak bisa dipakai pada codebase yang lebih dari 5 ribu baris
      Ini berjalan secara acak saat sisa konteks 10~20%, jadi secara efektif hanya 80% dari 272k yang bisa dipakai. Setelah kompresi, halusinasinya makin parah hingga lebih buruk daripada mulai dari awal, lalu terjebak dalam siklus membaca ulang codebase dan dikompresi lagi
    • Proses desain saya berbeda. plan.md yang direvisi berkali-kali itulah memorinya, dan me-restart sesi lalu membaca ulang serta meninjau rencana itu bagus untuk mendapatkan sudut pandang baru
    • Karena kompresinya buruk, saya membuat alat yang memungkinkan LLM menghapus sebagian konteks secara selektif lalu memulihkannya saat dibutuhkan. Jika Anda sering mencapai batas kompresi otomatis, context bonsai layak dicoba
      https://github.com/Vibecodelicious/context-bonsai-agents
    • Model Anthropic menyediakan konteks 1 juta token. Saya berencana pindah ke OpenAI bulan depan, tetapi ternyata masih bertahan di sekitar 300k, jadi sepertinya harus menyesuaikan diri dengan kenyataan baru
    • Biasanya saya menyarankan agar agen sesekali membuat atau memperbarui file .md supaya bisa mengingat informasi penting yang baru muncul. Tetapi jika agen benar-benar tahu apa yang penting, /compact juga seharusnya bekerja dengan baik

  • Karena jendela konteks besar, saya jadi tidak lagi menyeleksi apa yang dimasukkan, dan kompresi menerapkan kompresi lossy ke semuanya sekaligus sehingga detail yang dibutuhkan ikut hilang
    Menurut saya, masalah dasarnya adalah harus mengirim ulang seluruh percakapan setiap kali. Dengan plugin memori·konteks yang saya buat, saya mengosongkan konteks setiap giliran lalu menyuntikkan kembali hanya informasi yang relevan, sehingga model tidak membaca riwayat percakapan 200 ribu token melainkan hanya status terpilih beberapa ribu token, dan konteks kecil pun tidak menjadi masalah
    Untuk coding agent saya masih belum menyelesaikannya, tetapi kebijakan retensi yang hanya menyimpan hal yang diperlukan untuk menyelesaikan tugas atau tugas berikutnya dan membuang sisanya adalah solusi sebenarnya, dan menurut saya bisa diimplementasikan dengan LLM khusus

    • Banyak pakar NLP yang meneliti LSTM dan GRU juga menganggap pengiriman ulang seluruh percakapan sebagai masalah mendasar, tetapi secara empiris Transformer menang
      Menarik melihat apakah arsitektur model masa depan akan mempertimbangkan kembali masalah ini. Jika dibandingkan dengan manusia, yang masih kurang adalah kemampuan memindahkan informasi secara efisien dari memori jangka pendek ke memori jangka panjang, dan fine-tuning pada prinsipnya melakukan hal serupa tetapi tidak efisien

  • Saya tidak tahu apakah ini alasan perubahan ini, tetapi sejak awal saya menganggap memakai konteks yang lebih besar dari ini umumnya adalah kesalahan
    Banyak yang meremehkan seberapa besar kinerja model menurun dan biaya token meningkat ketika konteks membesar. Claude tidak memakai lebih dari 300k dan alih-alih mengompresi, ia membagi pekerjaan serta menjaga dokumentasi dan codebase modular tetap ringkas
    Untuk pekerjaan sekali jalan, konteks besar bisa berguna, tetapi jika secara konsisten melebihi 300k, kemungkinan Anda kehilangan banyak hal atau desain codebase Anda kurang baik

    • Saya juga mengompresi atau me-restart di 250k. Karena ukuran konteks yang dibutuhkan sebanding dengan skala proyek, orang yang membutuhkan jendela lebih besar tampaknya hanya menangani proyek yang lebih besar
    • Kesan saya juga sama, bahkan saya akan menaruh batas di 100~150k. Walaupun model mendukung konteks panjang, performa nyatanya tidak bagus
    • Bagian bahwa model jadi terasa jauh lebih bodoh saat konteks membesar tidak sesuai dengan pengalaman saya. Memang jadi lebih lambat dan mahal, tetapi untuk tugas kompleks itu biaya yang harus diterima
      Agen utama membiarkan sub-agen meneliti hal-hal yang diperlukan dan menulis rencana, lalu sub-agen lain meninjaunya secara adversarial untuk memperkuatnya. Setelah selesai, 30~40% dari jendela 1 juta token terisi, dan alur seperti ini mustahil di 272k
      Di 5.6 Sol, proses ini harus sangat diperkecil, dan mungkin itulah sebabnya hasilnya lebih buruk

  • Saat perubahan ini terjadi, Tibo juga mengunggah penjelasan: https://x.com/thsottiaux/status/2076543065045795309

    • Balasannya bisa dilihat di sini: https://xcancel.com/thsottiaux/status/2076543065045795309
      Tweet yang ditautkan adalah tanggapan tidak resmi terhadap informasi resmi dari Tibo, dan Tibo mengoreksi isinya di balasan
    • Saya tidak paham grafik ini. Saya penasaran mengapa garisnya terus naik walaupun ada kompresi, atau apakah ada makna tertentu dalam “overall trajectory size” yang tidak saya ketahui
    • Saya tidak tahu apakah panjang lintasan total bisa sama walaupun kekuatan penalarannya berbeda. Bahkan jika token penalaran dikeluarkan dari panjang lintasan, rasanya tetap tidak mungkin

  • Saya tidak suka pemadatan konteks seperti ini, dan menurut saya sekarang mereka harus menyediakan setidaknya 1 juta token
    GPT 5.5 dan 5.6 jadi tersendat setiap kali dikompresi sebelum kembali menemukan ritmenya, dan juga cenderung terlalu fokus pada pesan instruksi lama yang tersisa dalam konteks terkompresi

    • GPT-5.6-Sol sekitar 2x lebih efisien token dibanding Opus/Fable, jadi maksimum 258k setara dengan sekitar 516k milik Claude
      Kerusakan konteks masih menjadi masalah[1][2], dan ada juga bukti bahwa dalam pekerjaan agen, kompresi setara atau bahkan lebih baik daripada konteks panjang[3]. Akan paling baik jika model bisa bernalar pada konteks 1 juta seperti pada 256k, tetapi itu masih belum memungkinkan
      [1] https://arxiv.org/abs/2605.12366
      [2] Perbandingan F1 GraphWalks 256K dan 1M di Opus 4.8 System Card: https://www-cdn.anthropic.com/0b4915911bb0d19eca5b5ee635c80f...
      [3] https://context-folding.github.io/
    • Tidak seperti alat coding lain, kompresi otomatis tidak bisa dinonaktifkan, jadi sangat menjengkelkan. Karena dijalankan tidak menentu saat konteks tersisa 10~20%, kapasitas yang terjamin hanya 80% dari 272k
      Di codebase besar, ketika pekerjaan hampir selesai dan hanya tersisa respons sekitar 2.000 token, jika turun di bawah 20% maka setelah memproses cukup lama akan muncul Context compacted. Tidak bisa kembali ke sebelum kompresi, jadi harus menyelidiki ulang codebase lalu terkompresi lagi, dan akhirnya semua token habis
    • Saya harap pengurangan token ini bukan akal-akalan untuk meningkatkan penggunaan, melainkan terutama demi penghematan biaya. Di perusahaan juga, orang-orang yang menangani biaya membatasi konteks secara berlebihan sampai LLM internal yang awalnya lumayan berguna menjadi nyaris tidak berguna
      Rasanya seperti ada pertemuan antar eksekutif untuk saling berbagi praktik terburuk
    • Memori kerja bisa disimpan di file Markdown, jadi tidak perlu konteks besar. Saat konteks bertambah, perhatian jadi terpecah dan performa LLM menurun, jadi menjaganya tetap kecil justru lebih baik untuk kualitas

  • Saya memakai Opus setiap hari dan sering menjalankan /clear. Bahkan pada konteks 1 juta, performanya cepat menurun saat mendekati 50%, jadi biasanya hasilnya jauh lebih baik jika di-reset pada 30~40%
    Daripada kompresi, memulai ulang dan memasukkan konteks yang diperlukan dari awal bekerja lebih baik. Menata dokumen Markdown per fitur ke dalam beberapa kumpulan pengetahuan teknis, lalu saat pemuatan awal memberi tahu di mana informasi terkait pekerjaan bisa ditemukan, adalah pendekatan yang efektif

  • Di Codex, saya belum pernah merasa ukuran konteks menjadi masalah. Saya tidak tahu cara kompresinya, tetapi ia terus berjalan seolah tidak ada batasan

    • Sepertinya Anda baru mulai memakai Codex belakangan ini. Di awal, error model context size exceeded yang bahkan tidak bisa dipulihkan dengan kompresi sangat parah, dan baru hilang beberapa bulan lalu
      Sekarang jauh lebih baik, tetapi setelah kompresi ia tidak menunjukkan apa yang masuk ke concise summary, jadi sulit mengetahui apakah hal penting benar-benar dipertahankan
      Codex tampaknya bergerak ke arah menyembunyikan sebanyak mungkin dari pengguna; seperti baru-baru ini mereka mengenkripsi prompt antara agen dan subagen, rasanya seluruh log sesi juga bisa dienkripsi. Disayangkan, tetapi dari semua yang pernah saya pakai, ini tetap kombinasi alat·model terbaik
    • Codex sering lupa menyelesaikan pekerjaan terakhir saat kompresi terjadi, terutama ketika pesan dikirim tepat sebelum kompresi
    • Sebagian besar masalah bisa diselesaikan dengan divide and conquer, jadi perbedaan antara 300k dan 400k hampir tidak menjadi masalah. Agen coding bukan percakapan tanpa akhir

  • Sebagus apa pun kompresinya, pada proyek besar tetap harus membaca banyak file. 200 ribu token pertama cepat sekali habis, tetapi setelah itu lajunya melambat
    Sesi Fable kebanyakan tidak melewati 500 ribu token sehingga tidak perlu kompresi, tetapi di Codex harus terus melakukan kompresi dalam satu sesi

    • Saya kira alasan harus membaca banyak file adalah karena agents.md kurang memadai. Cukup membaca file kerja yang sebenarnya dan beberapa file terkait, sedangkan sisanya harus dirangkum dalam dokumentasi

  • Untuk pekerjaan saya, ini ukuran yang cukup kecil. Saya berusaha menjaganya di bawah 200k, tetapi saat mendorong iterasi terakhir pada sesi DeepSeek dan MiMo, kadang naik hingga 350k token lalu dikompresi
    Saya penasaran apakah OpenAI tidak bisa mengadopsi teknologi cache K/V milik DeepSeek yang dipublikasikan dalam paper dan menurunkan biaya secara besar-besaran

    • Tidak ada yang melakukan caching sebaik DeepSeek, jadi perbedaan implementasinya tampaknya besar dan sulit ditiru
      Jika memakai DeepSeek bersama Reasonix, ada metode tambahan khusus yang disesuaikan dengan struktur cache, sehingga pada sesi panjang 97~98% token tercache. Model yang sudah murah jadi makin murah
    • Pada model terbuka lokal berbasis llamacpp, agen memberi instruksi untuk mengompresi di kisaran 55k~85k, dan kecuali benar-benar butuh konteks besar seperti pelacakan log yang rumit, jarang sampai 120k
      Saya juga menyesuaikan system prompt agar agen membuat subagen lalu memadatkan isinya sesuai anggaran inferensi dan pesan llamacpp. Dengan dynamic context pruning dari opencode, arahnya tetap terjaga tanpa membesarkan volume, dan ini umumnya bekerja baik untuk pengembangan berulang berbagai subkomponen

  • Selama dua bulan terakhir, ini jauh lebih cocok untuk kebutuhan saya, jadi saya beralih dari Claude ke OpenAI. Saya penasaran apakah perubahan kali ini akan terasa pada perbedaan kualitas output