Model Context Window ve Maliyet: Uzun Belgeler İçin Nasıl Seçim Yapılır

Uzun belge çalışmaları için bir model seçmek, sadece manşetlerdeki bağlam penceresi boyutlarını karşılaştırmak değil, giriş token'ı başına düşen fiyat ile o belgenin her çağrıda ne kadarının aktif bağlamda tutulması gerektiğini tartmak anlamına gelir. Daha büyük bir pencere sunduğunu iddia eden bir model, tekrarlanan maliyetleri düşürmek için önbelleğe alma (caching) veya parçalama (chunking) kullanmak yerine her istekte tam giriş token'ı fiyatı ödüyorsanız, otomatik olarak daha ucuz bir çalışma seçeneği değildir.

Önemli Çıkarımlar

• Bağlam penceresi boyutu ve token başına maliyet ayrı değişkenlerdir. Yüksek token başına giriş fiyatına sahip büyük bir pencere, önbelleğe alma veya parçalama ile kullanılan daha küçük bir pencereden belge geçişi başına daha maliyetli olabilir.
• OpenRouter'ın en iyi uygulamalar kılavuzunda açıklandığı gibi prompt caching, önbellek isabeti (cache-hit) token'larında indirim sağlayarak tekrarlanan uzun bağlamlı çağrıların maliyetini düşürebilir; ancak indirim oranları ve önbellek ömürleri sağlayıcıya ve modele göre değişir, bu nedenle harcama tahmini yapmadan önce güncel şartları doğrulayın.
• Uzun belge iş yükleri için, bir model ailesine karar vermeden önce TokenLab'in Model Veri Merkezi'ndeki (/models/data) hem belirtilen bağlam penceresini hem de güncel giriş/çıkış fiyatlandırmasını kullanarak adayları karşılaştırın.
• Gemini 3.5 Flash veya DeepSeek V4 Flash gibi hızlı ve düşük maliyetli modeller, yüksek hacimli özetleme veya ayıklama işlemleri için makul varsayılanlardır; Claude Opus 4.8 veya GPT-5.5 gibi amiral gemisi modeller ise sadece daha fazla bağlam değil, uzun bağlam üzerinde daha derin muhakeme gerektiren görevler için daha uygundur.

Bağlam penceresi ve maliyet aynı kaldıraç değildir

"Bağlam penceresini" tek bir satın alma kararı gibi ele almak caziptir: en uzun belgenize uyan modeli seçin ve ardından fiyata bakın. Bu yaklaşım, pencere boyutu ve maliyetin bağımsız eksenler olduğunu gözden kaçırır.

Pencere boyutu, tek bir çağrıya nelerin sığabileceğini söyler. Fiyat ise, o içeriği her gönderdiğinizde ne kadara mal olduğunu belirtir. Çok büyük bir pencereye sahip bir model, parçalamayı (chunking) önlemenizi sağlar ve bu da mühendisliği basitleştirir; ancak token başına giriş fiyatı yüksekse ve bir konuşmanın her adımında aynı 50.000 token'lık belgeyi gönderiyorsanız, bu kolaylık gerçek bir maliyete dönüşür. Buna karşılık, daha küçük bir pencere parçalamayı veya getirmeyi (retrieval) zorunlu kılar; bu da mühendislik iş yükünü artırır ancak gönderdiğiniz parçalar küçükse ve model ucuzsa toplam harcamayı düşürebilir.

Uzun belge ürünleri için doğru soru "hangi modelin en büyük pencereye sahip olduğu" değil, "uygulamamın modeli gerçekte çağırma şekliyle bu belgeyi işlemenin maliyeti nedir" sorusudur. Bu, sadece belge uzunluğuna değil, çağrı düzenine bağlıdır.

Uzun belgeler gönderdiğinizde maliyeti asıl ne belirler?

Uzun belge iş yükleri için ham pencere boyutundan daha önemli üç faktör vardır:

Giriş token'ları baskındır. Özetleme, ayıklama, sınıflandırma ve getirme destekli üretim (RAG) için belgenin kendisi neredeyse her zaman faturalandırılan token'ların çoğunluğunu oluşturur. Çıktı, karşılaştırmalı olarak genellikle kısadır. Bu, optimize edilecek ilk sayının çıktı fiyatlandırması değil, giriş fiyatlandırması olduğu anlamına gelir.

Tekrar maliyeti katlar. Çok turlu konuşmalar, ajan döngüleri veya aynı belge bağlamını her çağrıda yeniden gönderen herhangi bir iş akışı, bu bağlam için tekrar tekrar ödeme yapar. Uzun bir belge üzerinde on turluk bir konuşma, tekrarlanan maliyeti azaltan bir şey olmadıkça tek bir geçişin on katına yakın maliyete neden olabilir.

Önbelleğe alma birim ekonomisini değiştirir. Bir sağlayıcı prompt caching'i destekliyorsa ve uygulamanız aynı öneki (uzun bir belge, bir sistem istemi, bir araç şeması) çağrılar arasında yeniden kullanıyorsa, önbelleğe alınmış token'lar taze token'lardan farklı şekilde faturalandırılabilir. Bu, model seçimini değiştirmeden uzun belge maliyetini düşürmek için en büyük kaldıraçtır.

Prompt caching hesaplamayı nasıl değiştirir?

OpenRouter'ın prompt caching hakkındaki belgeleri (openrouter.ai/docs/guides/best-practices/prompt-caching, 2026-07-14 tarihinde gözlemlenmiştir), önbelleğe almayı, bir istemin tekrarlanan kısımlarının (genellikle sistem mesajı veya bağlamın başında yer alan uzun bir belge gibi kararlı bir önek) sağlayıcı tarafından önbelleğe alınabildiği ve aynı öneki yeniden kullanan sonraki çağrılarda farklı bir oranda faturalandırılabildiği bir mekanizma olarak tanımlar. Kılavuz, bir önbelleğin nasıl yazıldığı, ne kadar süre kalıcı olduğu ve bir önbellek isabetinin maliyeti taze bir okumaya göre ne kadar indirdiği dahil olmak üzere önbelleğe alma davranışının sağlayıcıya ve modele göre değiştiğini belirtir.

Bu değişkenlik, uzun belge kararları için önemlidir. Özdeş bağlam pencerelerine ve benzer liste fiyatlarına sahip iki model, önbelleğe alma hesaba katıldığında çok farklı efektif maliyetler üretebilir; çünkü bir sağlayıcının önbellek TTL'si (yaşam süresi) istek düzeninizi rahatça kapsayabilirken, diğeri çağrılar arasında sona erebilir. Belge ağırlıklı bir iş yükü için maliyet tahmini yapmadan önce şunları kontrol edin:

• Hedeflediğiniz sağlayıcının, istediğiniz model için önbelleğe almayı destekleyip desteklemediği.
• Neyin önbellek yazma işlemini tetiklediği ve neyin önbellek isabetini tetiklediği (istemdeki içeriğin sırası genellikle önemlidir).
• Bir önbellek girişinin yeniden yazılması gerekmeden önce ne kadar süre kalıcı olduğu.
• İndirimin sadece giriş token'ları için mi geçerli olduğu, yoksa çıktı fiyatlandırmasını da etkileyip etkilemediği.

Bu detayların hiçbirinin sağlayıcılar arasında aynı olduğunu varsaymak güvenli değildir. OpenRouter'ın kılavuzunu ve ilgili sağlayıcının kendi belgelerini, genel beklentilere göre tahminde bulunmak yerine gerçek bilgi kaynağı olarak kabul edin.

Karar çerçevesi: Modeli belge iş yüküyle eşleştirin

İş yükü düzeni	En önemli olan	Makul başlangıç noktası
Tek geçişli özetleme veya ayıklama, tek belge, tek çağrı	Giriş token fiyatı, belgeyi parçalamadan sığdıracak kadar büyük pencere	Gemini 3.5 Flash, DeepSeek V4 Flash veya /models/data üzerinden başka bir düşük maliyetli yönlendirme modeli
Tek bir uzun belge üzerinde çok turlu sohbet	Önbelleğe alma desteği ve önbellek TTL'si, sadece pencere boyutu değil	Prompt caching özelliği doğrulanmış bir model; taahhüt etmeden önce güncel önbelleğe alma şartlarını doğrulayın
Aynı külliyatı tekrar tekrar işleyen ajan iş akışı	Tekrarlama durumunda çağrı başına maliyet, önbellek isabeti fiyatlandırması	TokenLab'in ajanlar için düşük maliyetli modeller karşılaştırmasındaki gibi ajan dostu düşük maliyetli modeller
Uzun, karmaşık belgeler üzerinde derin muhakeme (hukuki, teknik inceleme)	Uzun bağlam muhakemesinde model kalitesi, ham maliyetten sonra gelir	Claude Opus 4.8, Claude Fable 5 veya GPT-5.5 gibi amiral gemisi modeller, önce görev doğruluğuna göre değerlendirilmelidir
Birçok belge genelinde yüksek hacimli toplu işleme	Ölçekteki toplam maliyet, sadece çağrı başına maliyet değil	Seçim yapmadan önce /models/data üzerinden toplam maliyet projeksiyonlarını karşılaştırın
Ucuz ve premium modeller arasında yönlendirme içeren karma iş yükü	Yönlendirme mantığı ve yedek maliyeti, tek bir modelin fiyatı değil	AI model yönlendirme karşılaştırması analizine bakın

Bu tabloyu nihai bir cevap olarak değil, başlangıç filtresi olarak kullanın. Her iki rakam da zamanla değişebileceğinden, herhangi bir model için güncel pencere boyutunu ve fiyatlandırmayı TokenLab'in Model Veri Merkezi'nde doğrulamadan seçim yapmayın.

Pratik bir istek yapısı örneği

Aşağıdaki yapı, önbelleğe alma dostu bir isteğin, kararlı ve yeniden kullanılabilir bir öneki (uzun belge) değişken bir sonekten (kullanıcının sorusu) nasıl ayırdığını gösterir; böylece belge kısmı çağrılar arasında önbelleğe alınabilir. Tam alan adları ve önbelleğe alma kontrolleri sağlayıcıya ve API'ye göre değişir, bu nedenle bunu açıklayıcı bir sözde kod (pseudocode) olarak kabul edin ve uygulamadan önce ilgili sağlayıcının güncel belgeleriyle doğrulayın.

{
  "model": "example-model-id",
  "messages": [
    {
      "role": "system",
      "content": "You are a document analysis assistant. Answer only from the provided document."
    },
    {
      "role": "user",
      "content": "<<LONG_DOCUMENT_TEXT_HERE>>"
    },
    {
      "role": "user",
      "content": "Summarize section 3 and list any obligations with deadlines."
    }
  ]
}

Uzun belge ve çok sorulu iş yükleri için pratik yöntem, belge metnini tekrarlanan çağrılar boyunca kararlı bir konumda tutmak (böylece sağlayıcı önbelleğe alınmış öneki tanıyabilir) ve sadece sondaki soruyu veya talimatı değiştirmektir. Sağlayıcınızın önbelleğe alma uygulaması açık bir önbellek işareti veya ayrı bir önbellek kontrol alanı gerektiriyorsa, yukarıdaki yapının eksiksiz olduğunu varsaymak yerine o sağlayıcının güncel belgelerine göre ekleme yapın.

Taahhüt etmeden önce kontrol listesi

• Hafızaya veya eski karşılaştırmalara güvenmek yerine, modelin güncel bağlam penceresini ve giriş/çıkış fiyatlandırmasını /models/data üzerinden doğrulayın.
• Sadece tek bir çağrı için değil, beklenen çağrı sıklığınızda belge geçişi başına maliyeti tahmin edin.
• Hedef sağlayıcınızın istediğiniz model için prompt caching'i belgeleyip belgelemediğini ve önbellek isabeti indirimi ile TTL'nin gerçekte ne olduğunu kontrol edin.
• Gerçek tekrarlama düzeninizi göz önüne alarak, parçalamanın daha ucuz bir modelle birleşmesinin, daha pahalı bir modelde tek bir büyük pencere çağrısından daha iyi olup olmadığına karar verin.
• İş yükünüz ucuz yüksek hacimli çağrılar ile ara sıra yapılan derin muhakeme çağrılarını karıştırıyorsa, tek bir model yerine bir yönlendirme stratejisi düşünün; maliyet tabanlı bir karşılaştırma için AI model yönlendirme karşılaştırmasına bakın.
• Uzun bağlama sürekli erişen ajan ağırlıklı hatlar için, bir amiral gemisi modele varsayılan olarak geçmeden önce ajanlar için düşük maliyetli modeller bölümündeki seçenekleri inceleyin.

Sınırlamalar

Bağlam penceresi rakamları ve fiyatlandırma sağlayıcılar arasında sık sık değişmektedir ve bu makalede adı geçen modeller için belirli sayılar, bu metinden varsayılmak yerine okuma anında /models/data ile doğrulanmalıdır. İndirim oranları ve TTL'ler dahil olmak üzere prompt caching davranışı sağlayıcıya özeldir ve burada tam olarak detaylandırılmamıştır; bir üretim iş yükü için bütçe yapmadan önce OpenRouter'ın kılavuzuna ve ilgili sağlayıcının kendi belgelerine başvurun. Bu makale, uzun belge muhakemesi konusunda hiçbir model için görev doğruluğu kıyaslaması yapmamaktadır; maliyet ve pencere boyutu, model seçimi için gerekli ancak yeterli olmayan girdilerdir.

SSS

Daha büyük bir bağlam penceresi, uzun belgeler için her zaman daha düşük maliyet anlamına mı gelir? Hayır. Pencere boyutu tek bir çağrıya neyin sığacağını belirler; token başına fiyatı belirlemez. Yüksek giriş fiyatına sahip büyük pencereli bir model, parçalama veya önbelleğe alma ile kullanılan daha küçük pencereli bir modelden belge geçişi başına daha maliyetli olabilir.

Prompt caching her model için mevcut mu? Mutlaka değil ve mevcut olduğu durumlarda indirim oranı ve önbellek ömrü sağlayıcıya ve modele göre değişir. OpenRouter'ın prompt caching kılavuzunu ve kullanmayı düşündüğünüz model için ilgili sağlayıcının belgelerini kontrol edin.

Lansman öncesinde uzun belge ürünü için modelleri nasıl karşılaştırmalıyım? TokenLab'in Model Veri Merkezi'ndeki (/models/data) güncel pencere boyutu ve fiyatlandırma ile başlayın, ardından önbelleğe almayı (varsa) hesaba katarak beklenen çağrı hacminiz ve tekrarlama düzeninizdeki maliyeti tahmin edin. Seçimi tamamlamadan önce /models/rankings ve yukarıda bağlantısı verilen yönlendirme ve ajan maliyeti karşılaştırmaları ile çapraz kontrol yapın. Belge iş yükünüz için kendi maliyet tahmininizi oluşturmak üzere /models/data üzerindeki güncel model verilerini inceleyerek başlayın.