Claude Sonnet 4 artık 1 milyon token bağlamını destekliyor

 (anthropic.com)
2 puan yazan GN⁺ 2025-08-13 | 1 yorum | WhatsApp'ta paylaş
  • Anthropic’in Claude Sonnet 4 modeli artık en fazla 1 milyon token bağlam sunuyor; böylece büyük kod tabanları veya çok sayıda belge tek seferde işlenebiliyor
  • Geliştirilmiş bağlam desteği sayesinde büyük ölçekli kod analizi, çok geniş belge koleksiyonlarının işlenmesi ve bağlamı koruyan ajanların geliştirilmesi gibi çeşitli kullanım alanları mümkün hale geliyor
  • 200 bin tokenı aşan prompt’larda API ücretleri artıyor; ancak prompt caching ve batch processing ile maliyet düşürülebiliyor
  • Gerçek müşteri örnekleri olan Bolt.new ve iGent AI, bu özellikle üretkenliklerini ve yapay zeka yeteneklerini önemli ölçüde artırdı
  • Şu anda Sonnet 4’ün uzun bağlam desteği Anthropic API ve Amazon Bedrock üzerinde beta olarak sunuluyor; yakında Google Cloud’a da gelecek

1 milyon token bağlam desteği

  • Claude Sonnet 4, Anthropic API üzerinden artık en fazla 1 milyon token bağlamı destekliyor
  • Böylece tek bir istekte 75.000 satırdan fazla kodun tamamı veya birden fazla araştırma makalesi bütünlüklü biçimde işlenebiliyor
  • 1 milyon token bağlam beta özelliği şu anda Anthropic API ve Amazon Bedrock üzerinde kullanılabiliyor; Google Cloud’un Vertex AI hizmeti de yakında destekleyecek

Daha uzun bağlam, genişleyen kullanım senaryoları

  • Büyük ölçekli kod analizi: Tüm kod tabanı (kaynak dosyalar, testler ve dokümantasyon dahil) tek seferde yüklenerek proje yapısının anlaşılması, dosyalar arası ilişkilerin kavranması ve sistem tasarımına dayalı kod iyileştirme önerileri mümkün hale geliyor
  • Belgelerin birleşik özeti: Yüzlerce hukuki sözleşme, makale ve teknik spesifikasyon toplu olarak analiz edilip, belgeler arasındaki ilişkiler korunarak kapsamlı içgörüler elde edilebiliyor
  • Bağlamı koruyan ajanlar: Yüzlerce araç çağrısı ve çok adımlı workflow boyunca tam API dokümantasyonu, araç tanımları ve etkileşim geçmişi dahil edilerek tutarlı durumu koruyan konuşma tabanlı ajanlar geliştirilebiliyor

API fiyatlandırması

  • 200 bin token ve altındaki prompt’lar: giriş $3/milyon token, çıkış $15/milyon token
  • 200 bin tokenın üzerindeki prompt’lar: giriş $6/milyon token, çıkış $22.5/milyon token
  • Prompt caching uygulanırsa gecikme ve maliyet azaltılabiliyor
  • 1 milyon token bağlamı batch processing ile birleştirildiğinde ek olarak %50’ye kadar maliyet tasarrufu sağlanabiliyor

Müşteri kullanım örnekleri

  • Bolt.new

    • Bolt.new, Claude’u web tabanlı geliştirme platformuna entegre ederek web geliştirmede yenilik sağlıyor
    • "Sonnet 4’ün 1 milyonluk context window’u sayesinde geliştiriciler artık daha büyük projeleri yüksek doğrulukla ele alabiliyor"

  • iGent AI

    • Birleşik Krallık, Londra merkezli iGent AI; Maestro adlı AI partneri aracılığıyla konuşma içeriklerini çalıştırılabilir koda dönüştürüyor
    • "Daha önce mümkün olmayan otonom yazılım mühendisliği yetenekleri, Sonnet 4’ün 1 milyon token bağlamı sayesinde hayata geçti; böylece gerçek kod tabanları üzerinde günler süren oturumlar yürütülebiliyor"

Kullanım ve gelecek planları

  • Uzun bağlam özelliği, Anthropic API’de Tier 4 ve özel fiyat planı müşterileri için beta olarak sunuluyor; önümüzdeki birkaç hafta içinde daha geniş kullanıcı kitlesine açılması planlanıyor
  • Amazon Bedrock üzerinde de destek mevcut ve Google Cloud Vertex AI desteğinin de yakında sunulması planlanıyor
  • Uzun bağlamın diğer Claude ürün ailesine de getirilmesi planlanıyor
  • Ayrıntılı bilgiye resmi dokümantasyon ve fiyatlandırma sayfasından ulaşılabiliyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-08-13
Hacker News görüşleri

  • Profesyonel yazılım mühendisliği işlerinde LLM’lerin gerçekten güçlü bir bağlam koruma yeteneğine sahip olması çok gerekli gibi geliyor; yeni modelin biraz daha iyi olduğuna dair duyurular pratikte çok ilgi çekici değil. Asıl belirleyici unsur fiyat. Kod tabanımın yeterince büyük bir kısmını bağlam penceresine sığdırabilmek güzel ama fiyat ciddi biçimde arttığı için şu an bağlamı daha iyi yönetmenin daha doğru olduğunu düşünüyorum. Bağlam penceresini yoğun kullanmam servis sağlayıcı için avantajlı olabilir, ancak Sonnet’in odağı gerçekte ne kadar iyi koruduğu ayrıca değerlendirilmeli; bu yüzden gerçek değerinden emin olmak zor.

    • Bağlam repo’nun içinde ve LLM’in ihtiyaç duyduğu tüm bağlama her zaman sahip olamayacağını kabul etmek gerekiyor. Özellikle büyük repo’lar tek bir makineye bile sığmıyor. Belirli bir işi tamamlamak için odaklanabilmek adına gereksiz bilgileri ayıklamak gerekiyor; her şeyi yüklemek odak kaybına yol açıyor. Eskiden pencere boyutu çok küçüktü ve bence hâlâ küçük, ama nihayetinde doğru sorularla repo’yu anlayabilme yeteneği gerekiyor.

    • Bağlama fazla şey koyarsanız LLM’in kendi kendini karıştırma riski artar. Uzun bağlam yüzünden sıfırlamadan ilerledikçe odağı dağılır.

    • Yapay zekanın tüm kod tabanı yerine yalnızca soyutlanmış bilgilerle çalışacak şekilde eğitilmesi gerektiğini düşünüyorum. Gerçek insanlar da bütün kodu kafasında tutarak çalışmıyor; bu yüzden LLM’in de buna ihtiyacı yok.

    • Son birkaç haftadır Claude Code ile çalıştıktan sonra, ajan tipi yapay zekanın pratik değerinin hatta negatif olduğu sonucuna vardım. Yine de 6-8 ay sonra tekrar deneyeceğim.

    • Kullanım amacının sadece tek seferde daha fazla kodu bağlama koymak olduğunu düşünmüyorum. Bazı görevlerde asgari gerekli bağlam vardır ama 1M bağlamlı model, veriyi nasıl vereceğimize dair yeni yaklaşımlar gerektiriyor. Bu modelin asıl gücü; uzun ufuklu yinelemeli keşif, in-context learning ve yeniden yapılandırma gibi derinlemesine işlerde. Örneğin API değişikliğini 100 dosyaya uygulamak gibi genişlik odaklı işler var; ama 15 farklı yol deneyerek çözüm bulduğunuz derinlik odaklı işlerde de güçlü. Sonnet 1M özellikle ikincisinde benzersiz bir yetenek gösteriyor.

  • Claude Code ve token kullanımı konusunda endişeli olan kullanıcılar için birkaç ipucu öneriliyor

    1. İş için gereken bağlamı toplayıp kod tabanından bolca içerik yükleyin
    2. Her mantıksal duraklama noktasında çift escape’e basarak bağlamı dolu bir checkpoint’e geri dönün (böylece o token’ları yeniden harcamazsınız)
    3. Claude’a “geliştirici X görevini tamamladı” deyip bunu bağlama ekleyerek geri bildirim isteyin (başkasının yazdığı koddaki sorunları, kendi yazdığına göre daha çok işaret ediyor) Birden fazla sohbeti paralel kullanmak için /resume ile aynı iş parçacığını çağırıp bağlamın zengin olduğu noktaya çift escape ile sıfırlayabilirsiniz.

    • Claude’a “başka bir oturumda X işini sen yazmıştın” deyip, o bağlamı kullanarak soru sorma veya değişiklik isteme yöntemini kullanıyorum.

    • Ben de bunu sık yapıyorum ama her zaman iyi sonuç vermiyor. Bazen Claude’u tüm konuşma bağlamıyla kullanmak daha faydalı oluyor.

    • Gecikme süresi ciddi biçimde azalıyor. Yeni bir Claude’un bağlamı baştan yüklemesini beklemeye gerek kalmıyor.

    • Bu süreç programcılar için astroloji gibi hissettiriyor; söylemezseniz ajan kod tabanında çalışırken neler olacağını kestiremiyorsunuz.

    • İlginç olan, koddan sanki başka bir geliştirici yazmış gibi söz ettiğinizde Claude’un neden daha fazla sorun bulduğunu merak etmem.

  • Şimdiye kadar Claude Code’daki en faydalı kullanım biçimi, doğrudan “mevcut diff içinde bug var mı?” diye sormak oldu. Böylece sohbet botu değişiklikleri dikkatle analiz edip normalde uzun zaman ve çok sayıda dağıtım gerektirecek incelikli hataları hızla yakalıyor; ayrıca kodun doğruluğunu artırmak için dikkat edilmesi gereken noktaları tek tek sıralıyor.

    • Özellikle “daha derin düşün” diye ayrıca istemeden, bunu zaten istenen şekilde yapması şaşırtıcı.

    • Kodlama dışı işlerde de kullandım; yaratıcılığı zayıf ama eleştirel ve titiz editörlük yeteneği çok güçlü.

    • Bunun Claude Code için bir hook olarak somut biçimde uygulanabileceğini önerenler de var.

    • Ben de bunu yarından itibaren denemeye karar verdim.

  • Mevcut araçlara dair deneyimim şöyle

    1. Yeni bir dil, framework, yardımcı araç ya da greenfield proje başlatırken büyük fayda sağlıyor. Sonrasında kodu ayrıştırırken gerçekten güvenilip güvenilemeyeceğini sorguluyorum ama zaten kendim yorumlamaya üşendiğim için çoğu zaman “çalışıyorsa tamamdır” diye kabul ediyorum.
    2. Zaten iyi bildiğim dil veya framework’lerde ise verimlilik düşüyor. Prompt için uygun bağlamı yazmaya harcanan süre, doğrudan kendim yazmaktan benzer hatta daha fazla olabiliyor. Bazı durumlarda işe yarıyor ama biraz junior işi gibi duran muğlak kod üretme eğilimi var; deneyimsiz biri sorunu hemen fark etmeyebilir. Typescript, Kotlin, Java, C++ ile web siteleri, ESPHome bileşenleri, backend API’leri, node script’leri gibi çeşitli ortamlarda kullandım. Sonuç: hobi, script ve prototip için iyi ama kurumsal seviye kod için hâlâ yetersiz.

    • Benim deneyimim de benzerdi (1 yıl boyunca Cline + Sonnet & Gemini). Sonra Claude Code’u kullandım ve özellikle “bağlamı gerçekten temiz yönetmeyi” öğrendikten sonra gerçek bir kırılma yaşadım. Kilit nokta, yapay zekaya kod üretici gibi değil mimar ve uygulayıcı gibi davranmak. Son dönemde her zaman önce CC’ye yapmak istediğimiz iş için bir tasarım dokümanı yazdırıyorum; sonra da koda ve dokümana başvurmasını söylüyorum. Ben bunu gözden geçirip istenen yönün netleştiğini doğruladıktan sonra işi parçalara bölüyor, her parçayı da daha küçük alt parçalara ayırıyorum. İlk tanım tamamlanınca bağlamı temizliyorum; ardından her adımda dokümanı okutuyor ve uygulamayı yaptırıyorum. Gerekirse düzeltme yönü veriyor ya da dokümanı düzenleyip sadece o adımı yeniden başlatıyorum. Her adım için commit, bağlam temizliği, sonra sonraki adım. Böyle yaptığımda eskiden 2-3 gün süren bir özelliği bir gün içinde çıkarabiliyorum. Sonuçta doğrulanmış dokümantasyon, unit test, Storybook, erişilebilirlik (arai vb.) gibi yönleri de iyi ele alınmış çıktılar elde ediyorum. En sonda da başka bir modelle code review yaptırıyorum. Henüz baş döndürücü bir hız olmasa da, gelişen araçlara hazırlık olarak bunun geleceğe dönük bir beceri yatırımı olduğunu düşünüyorum.

    • Bana göre bu araç, eski Ruby on Rails dönemindeki rails new scaffolding hissine benziyor. LLM, araçların resmi dokümantasyonunu iyi kavramasının yeterli olduğu alanlarda, yani projenin ilk iskeletini kurmakta çok iyi. Buna karşılık legacy sistemlerde veya dış gereksinimi fazla olan projelerde daha az faydalı. Databricks gibi hızlı değişen araçlarda ise neredeyse işe yaramıyor. Eğitim verisinden sonra isim, sözdizimi ya da özellikler değiştiyse, ancak güncel dokümantasyonu prompt içinde yoğun kullanırsanız bir ihtimal doğuyor.

    • Benim iş akışım Claude masaüstü uygulamasıyla mcp sunucusunun dosya sistemini birlikte kullanıyor. İlgili dosya yollarını Claude’a verip görevi çözmesini söylüyorum. Claude dosyaları doğrudan okuyup analiz ediyor, sonra gerekli düzenleme ve eklemeleri yapıyor. Genelde birkaç build hatasını ben yapıştırınca tekrar düzeltmesini sağlıyorum. Yeni kodu mevcut kod stilini koruyarak yazması da etkileyici. Bunu Typescript ve C# ile kullandım; benim deneyimime göre çıkan sonuçlar hobi düzeyinde kalmıyor.

    • Ben programcı değilim ama Python ve bash kodu gerektiren işler yapıyorum. Ayrıca birkaç kişisel proje ve web sitesi yürütüyorum. Claude Code sayesinde eskiden yetkinlik eksikliği ve zaman yetersizliği yüzünden yapamadığım küçük projeleri hayata geçirebildim. Artık emacs ortamımı da kendim geliştirebiliyorum; lisp fonksiyonlarını da çok rahat yazdırabiliyorum. Benim için mükemmel bir araç. Eskiden tıkandığım işleri çözüyor ve hayatı kolaylaştırıyor.

    • Bunu Typescript, Go, SQL ve Rust ile kullandım. Rust fazla karmaşık olduğu için hata doluydu; projeyi bir an önce bitirmek istiyorum (ama projenin kendisi de zaten çok zor). Go dili çok basit olduğu için inanılmaz verimli; hız 2 katına çıkıyor. Typescript, React bileşenleri/animasyonlarında gayet iyi. SQL/PostgreSQL de benzer. Stored procedure boilerplate’inden nefret ediyorum ama LLM bunu azaltıyor, böylece bilek ağrım da azalıyor.

  • Bu kadar çok seçeneğin artması kesinlikle iyi ama aynı zamanda çok fazla bağlam yüklendiğinde LLM çıktısının kalitesi düşebilir. Çünkü LLM’in dikkati daha kolay dağılır. Kullanıcılar bu trade-off’u anlamadan sadece otomatik moda güvenirse, Claude Code ile yazılan kodun kalitesi konusunda endişeliyim.

    • Referans alınabilecek birkaç yazı bağlantısı da veriliyor

    • Şu an için uzun bağlam Claude Code’a entegre edilmiş değil. “Uzun bağlamı diğer ürünlere de uygulamanın yollarını değerlendiriyoruz” denmiş. Bence bunu zaten bir sorun olarak görüyor ve çözüm üzerinde çalışıyor olmalılar. Kullanıcılar pahalı planlarda ek maliyet üretmeye başlamadan önce bir çözüm sunmak istiyor gibiler.

    • Alternatif olarak ne önerirsiniz diye soruluyor. Claude Code’a alışmaya başlıyorum ama en iyi uygulamalarda hâlâ zayıfım.

    • Chroma ekibinin bu sorunu araştırdığı ve sayısal verilerin yakında geleceği söyleniyor.

  • “Opus daha iyi değil mi?” diye soruluyor; token bitip zorunlu olarak Sonnet’e geçildiğinde büyük fark hissedildiği söyleniyor. Deneyim kazanmış, fikri bol ama kodlama kısmında zorlanan biri olarak Claude’dan sonra fikirleri hayata geçirme, test etme ve bug düzeltme konusunda adeta uçtuğunu anlatıyor.

    • Ama sürekli Claude Code’a dayanmanın, kişinin gerçek geliştirme becerilerini köreltmesinden endişe eden bir tarafı da var.

  • Sohbet uygulamalarının (ChatGPT, Claude.ai) büyük sorunu, bağlam penceresiyle ilgili garip davranışlar göstermesi: ani kesilmeler, özetleme, “hayalet snippet”lerin yeniden eklenmesi vb. Kullanıcının bağlamı sürdürüp sürdürmeyeceğine ya da yeni sohbet başlatıp başlatmayacağına kendisinin karar vermesi daha rahat olurdu; ama pratikte plan ve hesaplama sınırları yüzünden bu mümkün olmuyor. Gerçekte tam bağlamı eksiksiz gönderebilmek için geliştirici araçları (Google AI Studio) ya da API sarmallı sohbet uygulamaları kullanmak gerekiyor. Özel bir sohbet uygulaması yaparsanız her mesaja zaman damgası ekleyip LLM’e “her 10 dakikada bir Markdown tablosuna yeni satır olarak o zaman aralığını özetle” talimatı da verebilirsiniz.

    • Zaman aralığı yerine “mesaj bazlı”, örneğin “her 10. mesajda blah-blah.md’ye özet çıkar” yaklaşımının daha iyi olabileceği de öneriliyor.

  • Bu planın, token sayısı arttıkça maliyetin adeta “karesel” biçimde yükseldiğini ilk kez açıkça kabul eden örnek olduğu düşünülüyor. Sanki LLM sağlayıcıları ilk kez doğrusal olmayan fiyat yapısını yansıtmaya başladı. Bu yaklaşım, zaten bildiğimiz inference scaling yasalarına benziyor.

  • İlgili bir tartışmaya da yönlendirme yapılıyor

  • Bu özellik harika ama çıkarım hızını iyileştirmenin yolu ne olur merak ediyorum. Bana göre 200K bağlam yeterli; keşke yanıtlar daha hızlı olsa. Bence birçok kişi, bağlam boyutu daha küçük kalsa bile ajan çok daha hızlı çalışıyorsa memnun olurdu (şu anda prompt başına 2-3 dakika bekleniyor).