OpenAI, Codex modelinin bağlam boyutunu 372k’dan 272k’ya düşürdü

 (github.com/openai)
1 puan yazan GN⁺ 1 일 전 | 1 yorum | WhatsApp'ta paylaş
  • OpenAI Codex’in paketli model meta verilerini güncellerken model bağlam boyutunu 372k’dan 272k’ya düşüren değişikliği release/0.144 dalına backport etti
  • PR #33972, değişiklikleri agent/hotfix-0.144-model-metadata dalından Codex 0.144 sürümüne taşıdı
  • Değişiklik kapsamı 1 JSON dosyası; diff istatistikleri 64 satır ekleme ve 54 satır silme
  • Ayrı bir konuşma veya inceleme içeriği olmadan 1 commit ve 36 kontrol sonrasında birleştirildi
  • Sağlanan sayfada dosya diff’i yüklenmediği için bağlam küçültme dışındaki belirli meta veri değişiklikleri doğrulanamıyor

Değişikliğin amacı ve kapsamı

  • PR başlığı, güncellenmiş paketli model meta verilerini Codex 0.144’e backport etme işi
  • Hacker News başlığına göre model bağlam boyutu 372k’dan 272k’ya düşürüldü
  • Hedef dal openai:release/0.144, kaynak dal ise sayan-oai:agent/hotfix-0.144-model-metadata

Birleştirme sonucu

  • PR #33972, 1 commit’ten (b06f4fa) oluşuyor
  • Commit başlığı Backport refreshed bundled model metadata
  • 18 Temmuz 2026’da birleştirildi; 36 kontrol ve 1 dosya değişikliği gösteriliyor
  • Değişiklik miktarı 64 satır ekleme ve 54 satır silme; dosya biçimi JSON

Doğrulanabilen sınırlamalar

  • Sayfadaki dosya ve yorum alanları yükleme hatası gösterdiği için asıl JSON diff’i sağlanan metinde doğrulanamıyor
  • Yeniden üretme adımları, değişiklik nedeni, uyumluluk etkisi ve inceleme geri bildirimleri gibi bilgiler metinde yer almıyor

İlgili okumalar

1 yorum

 
GN⁺ 1 일 전
Hacker News görüşleri

  • Sıkıştırmanın çözüm olduğu söyleniyor ama benim yaptığım işlerde sıkıştırmayla kaybolan ayrıntı fazlasıyla fazla
    Plan basitse ya da çok ayrıntılı tartışmalar yoksa sorun olmayabilir ama uzun bağlam eksikliği yüzünden sonunda yine Anthropic kullanmaya devam ediyorum
    Birden çok makaleyi ya da büyük ve karmaşık materyalleri eksiksiz hatırlaması gerektiğinde bağlam hep %16'da kalıyor. Yaklaşık 5 dakika konuşunca sıkıştırılıyor, sonra materyalleri tekrar okutup yeniden %16'ya ulaşma süreci tekrarlanıyor
    372k bağlam da kusursuz değildi ama %12~20 olan boşluğu yaklaşık %40'a çıkararak çok yardımcı oluyordu

    • Otomatik sıkıştırmayı kapatamıyor ve sıkıştırma öncesi sohbet geçmişine de dönemiyoruz; bu yüzden 5 binden fazla satırı olan kod tabanlarında Codex kullanılamıyor
      Kalan bağlam %10~20 iken rastgele çalıştığı için 272k'nin fiilen yalnızca %80'i kullanılabiliyor. Sıkıştırma sonrası halüsinasyonlar öyle artıyor ki en baştan başlamaktan beter oluyor ve kod tabanını yeniden okurken tekrar sıkıştırılma döngüsüne giriyor
    • Benim tasarım sürecim farklı. Defalarca revize edilen plan.md belleğin kendisi ve oturumu yeniden başlatıp planı tekrar okuyup gözden geçirmek yeni bakış açıları kazanmak için iyi oluyor
    • Sıkıştırma o kadar kötü ki LLM'in bağlamın bazı kısımlarını seçerek silmesine ve gerektiğinde geri yüklemesine izin veren bir araç yaptım. Otomatik sıkıştırma sınırına sık sık geliyorsanız context bonsai denemeye değer
      https://github.com/Vibecodelicious/context-bonsai-agents
    • Anthropic modelleri 1 milyon token bağlam sunuyor. Gelecek ay OpenAI'a geçmeyi planlıyordum ama hâlâ yaklaşık 300k civarında kaldığını görmek, sanırım yeni gerçeğe uyum sağlamam gerekeceği anlamına geliyor
    • Genelde ajanın ara sıra .md dosyaları oluşturup güncelleyerek yeni ortaya çıkan önemli bilgileri hatırlamasını tavsiye ediyorum. Ama neyin gerçekten önemli olduğunu ajan doğru biçimde biliyorsa /compact da iyi çalışmalı

  • Büyük bağlam penceresi yüzünden neyi ekleyeceğimi seçmemeye başladım ve sıkıştırma tümüne bir anda kayıplı sıkıştırma uygulayarak gereken ayrıntıları bile yok ediyor
    Bence asıl temel sorun, her seferinde tüm konuşmanın yeniden gönderilmesi. Yaptığım bellek ve bağlam eklentisiyle her turda bağlamı temizleyip yalnızca ilgili bilgileri yeniden enjekte edince model 200 bin tokenlık konuşma geçmişi yerine seçilmiş birkaç bin tokenlık durumu okuyor; bu yüzden küçük bağlam sorun olmadı
    Kodlama ajanlarında bunu henüz çözemedim ama iş tamamlamak ya da bir sonraki görev için gerekenleri tutup geri kalanını atmaya dayalı saklama politikası gerçek çözüm ve bunun özel bir LLM ile uygulanabileceğini düşünüyorum

    • LSTM ve GRU gibi yapıları araştırmış birçok doğal dil işleme uzmanı da tüm konuşmanın yeniden gönderilmesini temel sorun olarak görüyordu ama ampirik olarak Transformer kazandı
      Gelecekteki model mimarilerinin bu sorunu yeniden ele alıp almayacağını görmek ilginç olacak. İnsanı ölçüt alırsak hâlâ eksik olan, bilgiyi kısa süreli bellekten uzun süreli belleğe verimli biçimde taşıma yeteneği; ince ayar da ilke olarak benzer bir şey yapıyor ama verimli değil

  • Sebebin bu değişiklik olup olmadığını bilmiyorum ama zaten bundan daha büyük bağlam kullanmanın çoğu durumda hata olduğunu düşünüyorum
    Bağlam büyüdükçe model performansının ne kadar düştüğü ve token maliyetinin ne kadar arttığı hafife alınıyor. Claude 300k üstünü kullanmak yerine sıkıştırıyor ve işi parçalara ayırıyor; belgeleri ve modüler kod tabanını da özlü tutuyor
    Tek seferlik işlerde büyük bağlam yararlı olabilir ama sürekli 300k üstüne çıkıyorsanız çok şey kaybediyor olabilirsiniz ya da kod tabanı tasarımınız iyi değildir

    • Ben de 250k'de sıkıştırıyor ya da yeniden başlatıyorum. Gereken bağlam boyutu proje ölçeğiyle orantılı olduğundan, daha büyük pencereye ihtiyaç duyanlar muhtemelen sadece daha büyük projelerle uğraşıyor
    • Benim hissiyatım da aynı ama sınırı daha çok 100~150k olarak koyardım. Model uzun bağlamı desteklese bile gerçek performans iyi olmuyor
    • Bağlam büyüdükçe modelin gözle görülür biçimde aptallaştığı kısmı benim deneyimimle uyuşmuyor. Yavaşlayıp pahalılaştığı doğru ama karmaşık işler için katlanılması gereken bedel bu
      Ana ajan, alt ajanlara gerekli konuları araştırttırıp plan yazdırıyor; sonra başka alt ajanlar bunu karşıt bir gözle inceleyip güçlendiriyor. İş bitince 1 milyon token pencerenin %30~40'ı dolmuş oluyor ve bu akış 272k'de mümkün değil
      5.6 Sol'da bu süreci ciddi biçimde küçültmek zorunda kaldım ve sonucun daha kötü olmasının nedeni de muhtemelen bu

  • Bu değişiklik olduğunda Tibo bunu açıklayan bir gönderi de paylaşmıştı: https://x.com/thsottiaux/status/2076543065045795309

    • Yanıtlar burada görülebilir: https://xcancel.com/thsottiaux/status/2076543065045795309
      Bağlantı verilen tweet, Tibo'nun resmî bilgisine verilmiş gayriresmî bir yanıttı ve Tibo yanıtlarında içeriği düzeltti
    • Bu grafiği anlamıyorum. Sıkıştırma oluyorsa çizginin neden yükselmeye devam ettiğini ya da “overall trajectory size” ifadesinde benim bilmediğim başka bir anlam mı saklı olduğunu merak ediyorum
    • Akıl yürütme yoğunluğu farklıyken toplam yörünge uzunluğunun aynı olabilmesini anlayamıyorum. Akıl yürütme tokenlarını yörünge uzunluğundan çıkarsak bile mümkün görünmüyor

  • Bu bağlam sıkıştırmasını sevmiyorum; artık en az 1 milyon token sunmaları gerektiğini düşünüyorum.
    GPT 5.5 ve 5.6 her sıkıştırıldığında yeniden toparlanana kadar tökezliyor ve sıkıştırılmış bağlamda kalan eski talimat mesajlarına aşırı odaklanabiliyor.

    • GPT-5.6-Sol, Opus/Fable'a göre token verimliliğinde yaklaşık 2 kat daha iyi; bu yüzden en fazla 258k, Claude'un yaklaşık 516k'sına denk geliyor.
      Bağlam bozulması hâlâ bir sorun[1][2] ve ajan görevlerinde sıkıştırmanın uzun bağlama eşdeğer ya da ondan daha iyi olduğuna dair kanıtlar da var[3]. Modelin 256k'de yaptığı gibi 1 milyonluk bağlamda da akıl yürütebilmesi en iyisi olurdu, ama bu henüz mümkün değil.
      [1] https://arxiv.org/abs/2605.12366
      [2] Opus 4.8 System Card'daki GraphWalks 256K ve 1M F1 karşılaştırması: https://www-cdn.anthropic.com/0b4915911bb0d19eca5b5ee635c80f...
      [3] https://context-folding.github.io/
    • Diğer kodlama araçlarının aksine otomatik sıkıştırmayı devre dışı bırakamamak sinir bozucu. Kalan bağlam %10-20 seviyesindeyken düzensiz biçimde devreye girdiği için garanti edilen kapasite, 272k'nin yalnızca %80'i.
      Büyük bir kod tabanında iş neredeyse bitmişken ve yanıtta sadece yaklaşık 2 bin token kalmışken %20'nin altına düşünce uzun süre işlem yapıp ardından Context compacted görünüyor. Sıkıştırma öncesine dönemediğim için kod tabanını yeniden incelemeye başlıyor, sonra tekrar sıkıştırılıyor ve sonunda tüm tokenlar tükeniyor.
    • Token azaltmanın kullanımı artırmaya yönelik dolaylı bir yöntem değil de daha çok maliyet düşürme amaçlı olmasını umuyorum. Şirkette de maliyet sorumluları bağlamı aşırı kısıtlayıp başta işe yarayan dahili LLM'leri neredeyse kullanışsız hâle getirdi.
      Sanki yöneticilerin kendi aralarında en kötü uygulamaları paylaştığı bir kulüp var.
    • Çalışma belleği Markdown dosyalarında tutulabilir; büyük bağlama gerek yok. Bağlam arttıkça attention dağıldığı için LLM performansı düşüyor, bu yüzden küçük tutmak kalite açısından daha iyi.

  • Günlük olarak Opus kullanıyor ve sık sık /clear çalıştırıyorum. 1 milyonluk bağlam bile %50'ye yaklaştığında performansı hızla düşüyor; bu yüzden genelde %30-40 seviyesinde sıfırlayınca çok daha iyi sonuç alıyorum.
    Sıkıştırmak yerine taze başlayıp gereken bağlamı en baştan vermek daha iyi çalışıyor. Özellik bazlı Markdown belgelerini birkaç teknik koleksiyonda düzenlemek ve ilk yüklemede işe ilişkin bilgilerin nerede bulunacağını söylemek etkili oluyor.

  • Codex'te bağlam boyutunun sorun olduğunu hiç hissetmedim. Nasıl sıkıştırdığını bilmiyorum ama sınır yokmuş gibi ilerlemeye devam ediyor.

    • Görünüşe göre Codex'i yakın zamanda kullanmaya başlamışsın. İlk zamanlarda sıkıştırmayla da toparlanmayan model context size exceeded hatası çok ciddiydi ve daha birkaç ay öncesine kadar vardı.
      Şimdi çok daha iyi ama sıkıştırma sonrası concise summary içinde ne olduğunu göstermediği için önemli şeylerin korunup korunmadığını anlamak zor.
      Codex, kullanıcıdan olabildiğince çok şeyi gizleme yönünde ilerliyor gibi; yakın zamanda ajan ve alt ajan arasındaki prompt'ları şifrelediği gibi, tüm oturum günlüğünü de şifreleyebilir gibi görünüyor. Üzücü ama şimdiye kadar kullandıklarım arasında hâlâ en iyi araç-model kombinasyonu.
    • Codex, sıkıştırma olduğunda son işi tamamlamayı sık sık unutuyor; özellikle de sıkıştırmadan hemen önce mesaj gönderdiğinde bu daha belirgin.
    • Çoğu sorun böl ve yönet ile çözülebiliyor; bu yüzden 300k ile 400k arasındaki fark pek sorun olmuyor. Kodlama ajanı sonsuz bir sohbet değil.

  • Sıkıştırma ne kadar iyi olursa olsun, büyük projelerde çok sayıda dosya okumak gerekiyor. İlk 200 bin token çok hızlı tükeniyor, sonrasında ise hız yavaşlıyor.
    Fable oturumları çoğunlukla 500 bin tokenı geçmediği için sıkıştırma gerekmiyor, ama Codex'te tek bir oturum içinde sürekli sıkıştırma yapmak gerekiyor.

    • Çok dosya okunmasının nedeni bence agents.md'nin zayıf olması. Gerçek çalışma dosyalarıyla birkaç ilgili dosyayı okumak yeterli; geri kalanı belgelerde düzenli olmalı.

  • Benim işim için oldukça küçük bir boyut. 200k'nın altında tutmaya çalışıyorum ama DeepSeek ve MiMo oturumlarında son yinelemeli işi zorlarsam 350k token'a kadar çıkıp sonra sıkıştırdığı da oluyor.
    OpenAI'nin, yayımlanan makalelerde yer alan DeepSeek'in K/V cache tekniğini benimseyip maliyeti ciddi biçimde düşürüp düşüremeyeceğini merak ediyorum.

    • DeepSeek kadar iyi cache yapan başka yer yok; uygulama farkı çok büyük olduğu için taklit etmesi zor gibi görünüyor.
      DeepSeek'i Reasonix ile birlikte kullandığında, cache yapısına uyan ek özel bir yöntem sayesinde uzun oturumlarda tokenların %97-98'i cache'leniyor. Zaten ucuz olan model daha da ucuz hâle geliyor.
    • llamacpp tabanlı yerel açık modellerde ajan yönlendirip 55k~85k arasında sıkıştırma yaptırıyorum; karmaşık log takibi gibi gerçekten büyük bağlam gerektiren durumlar yoksa 120k'ya çıkmak nadir.
      Ajanın, llamacpp'nin çıkarım bütçesine ve mesajlarına göre alt ajanlar oluşturup içeriği sıkıştırması için sistem prompt'unu da ayarladım. opencode'un dinamik bağlam budamasını kullanarak hacmi büyütmeden yönü koruyor ve birden çok alt bileşeni yinelemeli geliştirmede genel olarak iyi çalışıyor.

  • Son iki aydır benim kullanımım için çok daha iyi olduğu için Claude'dan OpenAI'ye geçtim. Bu değişiklikle çıktı kalitesindeki farkın hissedilip hissedilmeyeceğini merak ediyorum.