Veresiye Kota: Yapay Zekada Zaman Adaletine Doğru

Claude ve Gemini’nin kota mimarileri üzerine bir inceleme ve bir öneri

Aydın Tiryaki

Giriş

2026 yılı, büyük dil modeli platformlarının kullanım sınırlandırma mantığında sessiz ama köklü bir dönüşüme sahne oldu. Hem Anthropic’in Claude’u hem de Google’ın Gemini’si, sabit günlük mesaj sayılarından vazgeçip “hesaplama tabanlı” (compute-based) bir kota mimarisine geçti: kullanım artık mesaj sayısıyla değil, prompt’un karmaşıklığı, seçilen model, konuşmanın uzunluğu ve kullanılan özelliklere göre ölçülüyor. İlginç bir tesadüf değil bu — iki şirket de neredeyse aynı ay içinde (Mayıs 2026), neredeyse aynı iskelete yakınsadı: kısa vadeli bir “beş saatlik dilim” ve bunun üzerine binen bir “haftalık tavan.”

Ama aynı iskeletin altında iki farklı felsefe yatıyor. Bu makale, önce bu iki mimariyi olabildiğince ayrıntılı biçimde ortaya koyacak, ardından kullanım sırasında ortaya çıkan somut bir sorunu tarif edecek ve son olarak bu soruna yönelik, “Veresiye Kota” adını verdiğim bir çözüm önerisini detaylandıracaktır.

Bölüm 1: Mevcut Kota Mimarisi — Claude ve Gemini

1.1 Beş Saatlik Dilim: İki Farklı Felsefe

Her iki platformda da kısa vadeli kullanım, beş saatlik bir pencereyle sınırlanıyor. Ancak bu pencerenin nasıl başladığı konusunda iki platform taban tabana zıt bir mantık izliyor.

Claude’da pencere tamamen reaktif. Sabit bir saat ızgarası yok. Pencere, o oturumdaki ilk mesajı gönderdiğiniz dakikada başlıyor ve tam beş saat sonra kapanıyor. Saat 09:47’de ilk mesajınızı atarsanız pencereniz 14:47’de kapanır. Önceki pencere kapandıktan sonra yeni bir mesaj göndermediğiniz sürece hiçbir pencere “açık” değildir — sistem sizi beklemede tutmaz. Örneğin 14:47’de kapanan bir pencereden sonra 15:15’te ilk mesajınızı atarsanız, yeni pencere 14:47’den değil, 15:15’ten itibaren başlar; aradaki 28 dakika hiçbir pencereye dahil olmadan sistemden düşer. Kısacası: sistem sizi değil, siz sistemi tetikliyorsunuz.

Gemini’de ise pencere yarı-sabit bir ızgaraya oturuyor. Kullanıcıya özel bir “faz” (örneğin dakika: 37) atanmış durumda ve pencereler bu faza göre kesintisiz, art arda ilerliyor: 09:37 → 14:37 → 19:37 → 00:37 → 05:37 → 10:37… Kullanıcı ne zaman girerse girsin, sistem onu bu sabit ızgaraya “yakalıyor” — siz 14:00’te çalışmaya başlasanız bile, kullanımınız bir sonraki ızgara noktasına (14:37) kadar eski pencerede sayılır, yeni pencere ancak 14:37’de açılır. Yani burada siz pencereyi bekliyorsunuz, pencere sizi değil.

Bu iki felsefe de aynı mühendislik hedefine (sunucu yükünü zaman içine yayıp “thundering herd” — aynı anda gelen istek dalgası patlamasını önlemek) farklı yollarla ulaşıyor: Claude kullanıcı-tetiklemeli doğal dağılıma güveniyor, Gemini ise merkezi olarak atanmış bir faz + günlük kaymaya (aşağıda açıklanacak) dayanıyor.

1.2 Haftalık Sınır: Sabit Faz

Beş saatlik dilimin aksine, haftalık tavan her iki platformda da sabit bir mantıkla çalışıyor. Hesabınıza (ya da hesabın aktivasyon anına) bir kez atanmış bir gün ve saat var, ve bu “faz” kullanıcının davranışından bağımsız olarak sabit kalıyor — kullanıcı ne zaman, ne kadar çalışırsa çalışsın, haftalık sıfırlama hep aynı gün ve dakikada gerçekleşiyor. Test ettiğimiz örnekte Gemini’de bu sabit an her Salı sabahı yaklaşık 09:37, Claude’da ise her Perşembe gecesi yaklaşık 02:xx civarında gözlemlenmiştir.

Böylece her iki platformda da aynı anda iki farklı zaman rejimi birlikte işliyor: kısa pencere davranışa duyarlı (Claude’da tamamen, Gemini’de kısmen), haftalık pencere ise davranıştan tamamen bağımsız, sabit bir ızgaraya kilitli.

1.3 24’ün 5’e Bölünmemesi: Kayma Matematiği

Gemini’nin yarı-sabit ızgara sisteminde ilginç bir matematiksel sonuç ortaya çıkıyor. Bir gün 24 saat, ama pencereler 5’er saatlik bloklar halinde ilerliyor — ve 24, 5’e tam bölünmüyor. Sonuç: kullanıcının “sabah dilimi” her gün tam bir saat ileri kayıyor. Örneğin bugün 09:37’de başlayan dilim, yarın 10:37’de, ertesi gün 11:37’de başlayacaktır. Hesap şöyle işliyor: 5 saatlik blok sırasıyla 09:37 → 14:37 → 19:37 → 00:37 → 05:37 → 10:37 şeklinde ilerliyor; bu son noktaya ulaşmak tam 5 blok, yani 25 saat sürüyor. 25 saat = 24 saat + 1 saat; işte bu fazla 1 saat, her gün kapanmadan birikiyor ve dilimi ileri kaydırıyor. Bu kayma 5 gün sonra (5 gün × 1 saat = 5 saat = tam bir blok) tam bir tur atıp baştan başlıyor — yani kullanıcının günlük dilim düzeni 5 günlük bir döngüyle tekrarlanıyor.

Bu yapının, muhtemelen kasıtlı olmasa da, faydalı bir yan etkisi var: sabit bir ızgarada bile hiçbir kullanıcı, günün hep aynı saatinde (örneğin hep en yoğun saatte) kilitli kalmıyor; herkes zamanla iyi ve kötü saatleri sırayla paylaşıyor. Ayrıca kullanıcıya atanan başlangıç fazının kendisi de muhtemelen bir “jitter” (kasıtlı rastgele ofset) ile belirleniyor — bu da milyonlarca hesabın kotasının aynı anda sıfırlanıp sunucularda ani yük patlaması yaratmasını (thundering herd) önlemenin bir başka yolu.

Önemle belirtelim: bu iki ayrı çark (beş saatlik dilimler ve haftalık sınır) birbirinden tamamen bağımsız ilerliyor. Haftalık sıfırlama anında bile beş saatlik dilimlerin rotasyonu kesilmiyor, sadece o an itibarıyla kota sıfırlanıyor; dilimin kendisi aynı yerinden dönmeye devam ediyor.

1.4 Model Bazlı Farklılaşma

Kota tüketimi tek boyutlu bir “zaman” meselesi değil; en az üç boyutlu işliyor: zaman dilimi × model seçimi × düşünme derinliği.

Claude’da Opus, Sonnet’e göre kotayı çok daha hızlı tüketiyor — bu fark o kadar belirgin ki, Max planlarında Anthropic bu iki modeli birbirinden bağımsız haftalık havuzlara ayırmış durumda; Opus kotanız tükendiğinde Sonnet’e geçip çalışmaya devam edebiliyorsunuz. Pro planında ise böyle bir ayrım yok, tüm modeller (Fable hariç) tek bir “All models” havuzunda toplanıyor.

Gemini’de de benzer bir ayrım var: Flash ve Flash-Lite günlük işler için tasarlanmış, hızlı ve kotayı az tüketen modeller; Pro ise karmaşık akıl yürütme için tasarlanmış ve kotayı çok daha hızlı tüketen bir model. Kotanız tükendiğinde sistem sizi otomatik olarak Flash-Lite’a düşürebiliyor.

“Standart” ile “Extended/Deep Think” düşünme modları arasındaki fark da her iki platformda gerçek: uzatılmış düşünme (extended thinking) açıkken kota tüketimi belirgin biçimde artıyor.

Ayrıca aynı işlem, farklı abonelik kademelerinde çok farklı hissedilebiliyor. Google I/O 2026’da tanıtılan yapıya göre, Gemini’nin “AI Ultra” planı aslında tek bir kademe değil, aynı isim altında iki ayrı kademeden oluşuyor: yaklaşık $100/ay karşılığında AI Pro’nun 5 katı kota, yaklaşık $200/ay karşılığında ise 20 katı kota. Bu yüzden örneğin bir Gem Fabrikası güncellemesi, 20 kata kadar geniş bir havuzda kotanın yalnızca %8-10’unu tüketirken, aynı işlem daha dar bir kademede kotanın çok daha büyük bir kısmını, hatta neredeyse tamamını götürebiliyor. Yani “bir işlem kotanın yüzde kaçını yer” sorusunun cevabı, yalnızca işin kendisine değil, kullanıcının hangi kademede olduğuna da bağlı.

1.5 Fable Örneği: Yeni Modellerin Kota Rejimi

Claude Fable 5’in (Haziran 2026’da tanıtılan, ihracat kontrolleri nedeniyle kısa süre askıya alınıp Temmuz’da geri gelen üst düzey model) kota sayfasında kendine özgü bir satır olarak (“Fable only”) ayrı takip edilmesi, yeni modellerin farklı ticari/erişim rejimleriyle kotaya nasıl yeni kategoriler eklediğini gösteren güncel bir örnek. Fable, haftalık kotanın belirli bir yüzdesine kadar dahil, bu sınırı aştığında ise kullanım kredisiyle devam ediyor — diğer modellerden (Sonnet, Haiku) tamamen ayrı bir mantıkla.

Bölüm 2: Sorunun Tanımı

2.1 Zaman/İş Yükü Uyumsuzluğu

Yukarıda tarif edilen mimarinin pratikteki sonucu şudur: kota, zamana göre değil işin ağırlığına göre tükeniyor, ama pencerenin kendisi zamana göre sabit. Bu ikisi arasındaki uyumsuzluk, kullanıcıyı işlerini kotaya göre planlamaya zorluyor. Yoğun bir iş (uzun bağlam, ağır model, kapsamlı bir güncelleme) beş saatlik dilimin daha ilk saatinde kotayı tüketebiliyor; geriye kalan üç-dört saat tamamen “ölü zaman” olarak kayboluyor — ne kullanıcıya ne de sisteme bir fayda sağlamadan.

Bunun tersi de sorun yaratıyor: haftalık kotanın büyük bir kısmı (örneğin %70’i) dururken, o anki beş saatlik dilimde kilitlenip küçük bir iş için bile kota bulamamak mümkün. Yani sistemde toplamda bolca “bütçe” var, ama bu bütçe zaman dilimlerine öyle sert bölünmüş ki, kullanıcı cebinde parası olan ama o an elinde bozuk para bulunmayan biri durumuna düşüyor.

2.2 Yarım Kalan İş Kaybı

Sorunun en ciddi boyutu, sadece kullanılamayan zaman değil, yarım kalan işin kaybıdır. Kota bir işin ortasında tükendiğinde, iş otomatik olarak kaldığı yerden devam etmiyor; kota yenilendiğinde bazen baştan ya da yakın bir noktadan tekrar başlamak gerekiyor. Bu durumda, o ana kadar harcanmış olan kota nihayetinde hiçbir işe yaramamış oluyor — hem kullanıcının kotası hem de sistemin hesaplama kaynağı gerçek anlamda israf edilmiş oluyor.

2.3 Somut Örnekler

Bu sorun, özellikle kapsamlı, kota-yoğun işlerde belirginleşiyor:

Gem Fabrikası güncellemesi (Gemini): Sıradan bir Gem güncellemesi kotanın yaklaşık %2-3’ünü tüketirken, Fabrika’nın kendisinin (kapsamlı bir Gem olması nedeniyle) güncellenmesi yaklaşık %8-10’unu, bunun İngilizce çevirisi de ayrıca %8 civarını götürüyor. Tek bir “kararlı sürüm” döngüsü (güncelleme + çeviri) tek başına beş saatlik kotanın %16-18’ini tüketebiliyor.
ATG Gem/GPT Proje Dağarcığı (Claude): 60’ın üzerinde Gem ve GPT’yi kategorili biçimde kataloglayan bu kapsamlı proje üzerinde çalışırken, iki büyük işlem bir dilimi tamamen tüketebiliyor; o sırada başka işler de yapılmışsa işin tamamlanma şansı kalmıyor ve bazen yarım kalan iş kayboluyor.
Talimat dışı işlem: Aynı süreçte, sistemin (bu örnekte Gemini’nin) talimat verilmemiş bir işi (Türkçe güncelleme bitmeden önce planlanmamış bir İngilizce çeviriyi) kendiliğinden üstlenmesi, zaten kıt olan kotayı kullanıcının izni ve planı dışında tüketmiş, planlanan işleri aksatmıştır. Bu, kıt bir kaynağın kullanıcı kontrolü dışında harcanması açısından ayrıca ele alınması gereken bir konudur.

Bölüm 3: Öneri — Veresiye Kota

3.1 Temel İlke

Önerinin adı Veresiye Kota — Türkçedeki geleneksel alışveriş kavramından ödünç alınmış bir isim: “hesabına yaz, ödemen zaten var, sadece zamanlaması farklı.” Bu, Anthropic’in veya Google’ın şu an sunduğu “ekstra kota/kredi satın alma” mekanizmasından tamamen farklıdır — çünkü kullanıcı, sisteme ekstra yük bindirmiyor; kendi zaten hak ettiği, sadece henüz “sırası gelmemiş” bir payını öne çekiyor.

Temel ilke iki unsuru kesin biçimde ayırıyor:

Toplam tavan (haftalık kota): Dokunulmaz, hiçbir zaman aşılmıyor.
Zamansal dağılım (kotanın dilimlere nasıl bölündüğü): Şu an tamamen sistem tarafından katı biçimde belirleniyor; öneri, bunun bir kısmını kullanıcının kendi lehine esnetebilmesini sağlıyor.

3.2 Kurallar ve Güvenceler

Hedef sınırlaması: Transfer yalnızca o an aktif olan dilime yapılabilir; henüz başlamamış, gelecekteki bir dilime doğrudan transfer yapılamaz.
Kaynak seçenekleri:
- Yakın vade hakkı: Önümüzdeki 24 saat içindeki herhangi bir gelecek dilimden.
- Haftalık ufuk hakkı: Kullanıcının, o hafta içinde seçtiği herhangi bir günden (örneğin bilinen yoğun bir gün için önceden pay ayırmak amacıyla).
- Hafta arası hakkı: Eğer bu haftanın kotası da tükenmişse, gelecek bir haftanın (örneğin bir veya iki hafta sonrasının) henüz zamanı belirlenmemiş genel toplamından — belirli bir gün/saate değil, o haftanın soyut bütününe karşılık gelen bir miktar düşülerek.
Miktar tavanı: Herhangi bir kaynak dilimin/haftanın en fazla belirli bir oranı (örneğin ⅔’ü) transfer edilebilir; hiçbir kaynak asla tamamen boşaltılamaz — böylece kullanıcı gelecekte o dilime ulaştığında en az bir taban kota garantili kalır. Hafta-arası transferlerde bu tavanın, öngörülemezlik ufku daha uzun olduğu için daha temkinli (örneğin ⅓ veya ¼) belirlenmesi makul olur.
Parça parça, blok değil: Transfer tek seferlik büyük bir paket olarak değil, ihtiyaç çıktıkça küçük miktarlarla gerçekleşir; bu parça parça transferlerin toplamı yine de madde 3’teki tavana çarpar — damla damla dolan ama belirli bir seviyede duran bir kap gibi işler.
Çoklu kaynak, tek hedef: Büyük işler (bir dilimin tamamının bile yetmeyeceği kapsamlı bir çalışma) için, aynı aktif dilime birden fazla kaynak dilimden/günden parça parça transfer yapılabilir.
Zincirsiz transfer: Ödünç alınan bir dilimden başka bir dilime tekrar aktarım yapılamaz — zincirleme borçlanma yok.
Şeffaflık: Her transfer öncesi kullanıcıya net gösterilir: hangi kaynaktan ne kadar çekiliyor, o kaynakta geriye ne kadar kalacak.
Kendiliğinden sınırlanan sıklık: Mekanizmanın öngörülebilirliği korumak için ayrıca keyfi bir “haftada şu kadar kez” sınırına ihtiyacı yoktur — sıklık zaten madde 3 ve 6’dan (her kaynağın en fazla belirli bir oranının çekilebilmesi, zincirsiz transfer) doğal olarak kendini sınırlar. Kullanıcı, o an erişilebilir kaynakların tavanına ulaştığında zaten çekecek payı kalmaz; yeniden çekebilmek için ilgili kaynağın kendisinin yenilenmesini beklemesi gerekir. Böylece sistem, gerçekten yoğun ve tekrarlayan bir iş yükü olan kullanıcıyı keyfi bir sayıyla cezalandırmadan, kendi iç mantığıyla dengede kalır — bu da önerinin asıl amacına (gerçek uyumsuzluğu gerçek ölçüde gidermek) çok daha uygundur.

3.3 Üç Tetikleyici Kanal

Mekanizma, üç farklı yoldan devreye girebilir:

Kullanıcı talebi (reaktif): Kullanıcı ihtiyaç hissettiği anda kendisi talep eder — “şu dilimden şu kadar istiyorum.”
Sistem gözlemi (proaktif): Kullanım, önceden belirlenmiş bir eşiğe (örneğin %90) ulaştığında, sistem kullanıcının geçmiş kullanım desenini (hangi dilimleri hiç kullanmadığını, örneğin gece 03:00 dilimini) değerlendirerek kendiliğinden teklif sunar: “Şu kullanmadığın dilimden sana bir miktar aktarabilirim, ister misin?”
Sistem ön-hesabı (önleyici): Kapsamlı bir işe başlamadan önce, sistem o işin tahmini kota maliyetini kullanıcının o dilimde kalan kotasıyla kıyaslar; iş tamamlanamayacaksa, işe hiç başlamadan uyarır ve bir transfer önerir: “Bu iş şu anki kotanla bitmez; şuradan şu kadar aktaralım mı, yoksa sonraki dilimi mi bekleyelim?” Bu kanal, “yarım kalan iş kaybı” sorununu kökünden önlüyor.

Her üç kanalda da nihai miktar statik bir hak değil, gerçek zamanlı bir müzakeredir: kullanıcı azami tavana kadar talep eder, sistem o anki gerçek altyapı yüküne göre verebileceği miktarı belirler — talep her zaman tam karşılanmayabilir.

3.4 İki Kademe: Gün İçi ve Haftalar Arası

Öneri, aynı ilkenin iki farklı ölçekte fraktal biçimde tekrarıdır:

Kademe 1 (mikro): Beş saatlik dilimler arası transfer, aynı hafta içinde.
Kademe 2 (makro): Haftalık kota, gelecek bir haftanın kotasından belirlenmiş, daha temkinli bir oranla öne çekilebilir — örneğin iki hafta sonra planlanan bir tatil öncesi yoğun bir çalışma dönemi için.

Her iki kademede de aynı üç güvence geçerlidir: toplam asla aşılmaz (sadece zaman içinde kayar), zincirleme transfer yok, işlem şeffaf.

Bölüm 4: Adalet Dengesi

4.1 Kullanıcı Açısından

Öneri, kullanıcının zaten toplu olarak satın aldığı ama zaman dilimlerine sabit biçimde dağıtılmış olan bir hakkı, daha verimli ve kullanıcı-odaklı biçimde kullanmasını sağlıyor. Bu, ekstra bir hak talep etmek değil, mevcut hakkın zamanlamasını esnetmek.

4.2 Sistem Açısından

Sistemin de kaybetmemesi için tasarım şu ilkeleri gözetiyor: toplam haftalık tüketim değişmez (sistem sadece “ne zaman” tüketildiğini yeniden düzenler, “ne kadar” tüketildiğini değil); zincirsiz transfer hesaplama karmaşıklığını sınırlar; her kaynağın kendi tavanı (madde 3), keyfi bir sıklık kısıtlamasına gerek kalmadan sistemi doğal olarak dengede tutar. Sistemin makul bir itirazı da var: mevcut sabit-pencere modelinin en büyük avantajı öngörülebilirlik ve basitliktir; esnek transfer, altyapı kapasite planlamasına ek bir tahmin katmanı ekler. Bu itiraz meşrudur — öneri, şirketin bunu tamamen reddetme hakkını da kabul eder; asıl amaç, iki meşru çıkarı (şirketin basitlik/öngörülebilirlik tercihi ile kullanıcının hak ettiği kotayı verimli kullanma talebi) aynı masada görünür kılmaktır.

4.3 Ekonomik Gerilim ve Etik Duruş

Bu sistemin hiçbir aşamasında yapay zeka şirketinden ek bir kaynak talep edilmiyor; sadece kullanıcının zaten hak ettiği kotanın zamansal dağılımı değişiyor. Bu açıkça, mevcut “kilitlen, bekle ya da ekstra kredi/plan satın al” modelinin barındırdığı bir gelir kaynağını (darlık anındaki upsell) zayıflatabilir. Bunu görmezden gelmek yerine açıkça söylemek gerekir: işini tamamlayamamış ve bu yüzden ek kota satın almak zorunda kalmış bir kullanıcıdan kazanç sağlamaya çalışmak, iyi niyetli bir yaklaşım olarak görülemez. Kullanıcının zaten ödediği bir hakkı zaman içinde esnetmesine izin vermemek, sonra da darlık anında ona ek satış yapmak, hizmet sunmak ile darlığı fırsata çevirmek arasındaki çizgiyi bulanıklaştırır.

Karşı tarafta da bir denge var: daha az sinirlenen, kilitlenmeyen, kotayı zorlamak için gayrı resmi yöntemlere (örneğin pencereyi erken açmak için otomatik “ısıtma” istekleri göndermek gibi) başvurmak zorunda kalmayan bir kullanıcı kitlesi, uzun vadede marka güveni ve müşteri sadakati açısından şirkete de fayda sağlayabilir. Kısa vadeli gelir ile uzun vadeli güven arasındaki bu denge, önerinin şirkete sunuluş biçiminde açıkça ele alınmalıdır.

Sonuç olarak bu öneri, yapay zeka şirketi merkezli değil, kullanıcı merkezli bir sistemdir — ama aynı zamanda şirketin altyapısal gerçekliğini ve haklarını da gözeten, iki tarafı da memnun etmeyi hedefleyen bir denge arayışıdır.

Bölüm 5: Daha Geniş Bağlam

5.1 Düzenleyici Çerçeve — Temkinli Bir Not

Bu tür bir adalet mekanizmasının, mevcut tüketici hakları ilkeleriyle (örneğin Avrupa Birliği’nin tüketici hakları ve haksız ticari uygulamalara ilişkin düzenlemeleri) tutarlı olduğu söylenebilir: “satın alınan bir hizmeti yapısal engeller yüzünden kullanamamak” ilkesel olarak bu çerçevelerin ilgi alanına girer. Ancak şunu açıkça belirtmek gerekir: şu an yürürlükte hiçbir düzenleme, burada tarif edilen türde spesifik bir mekanizmayı zorunlu kılmıyor. Bu tür ürün-seviyesi adalet kuralları genellikle önce piyasa rekabetiyle (bir platform uygularsa diğerleri de uygulamak zorunda kalır), ardından biriken kullanıcı şikâyetleriyle düzenleyici ilgiye dönüşür — yasadan önce gelir. Bu makale, bir öngörüden çok, mevcut ilkelerle tutarlı bir yönü işaret etmektedir.

5.2 Diğer Sektörlerle Karşılaştırma

“Kullanılmayan hakkın kaybolması” sorunu, yapay zekaya özgü değildir. Mobil veri kotalarında bir ayın kullanılmayan kısmı genellikle sıfırlanırken, aşım anında fatura anında yansır; bazı operatörlerin geçmişte sunduğu “devreden veri” (rollover data) uygulamaları, bu tür bir esnekliğin ticari olarak da uygulanabilir olduğunu gösteriyor. Yıllık limitini kullanmayan kredi kartı hakları ve havayolu millerinde de benzer tartışmalar yaşanmıştır. Yapay zeka kotaları, bu ailenin en yeni ve en az düzenlenmiş üyesidir.

5.3 Neden Öncülük Yapay Zekadan Gelmeli

Telekomünikasyon şirketinin sistemi statiktir: sabit kurallarla işler, kullanıcıyla gerçek zamanlı “pazarlık” edemez; esneklik için insan müşteri temsilcisi, form ya da ayrı bir talep süreci gerekir. Yapay zeka ise tam tersine, zaten kullanıcıyla gerçek zamanlı konuşan, onun ne yapmak istediğini anlayan ve kendi anlık yükünü değerlendirebilen bir taraftır. Bu nedenle “bu işin maliyeti şu, senin kotan şu, transfer yapalım mı” türünden dinamik bir müzakere, yapay zeka için herhangi bir ekstra insan müdahalesi gerektirmeden, konuşmanın doğal bir parçası olarak gerçekleşebilir — çünkü platformun kendisi zaten “akıllı taraf”tır.

Bu, önerinin bugün için özellikle yapay zekaya özgü, idealize edilmiş bir sistem olduğu anlamına gelir. Ancak zaman içinde diğer sektörler (telekomünikasyon dahil) daha akıllı, müzakere edebilen sistemlere dönüştüğünde, aynı ilkenin oralara da uyarlanabilir olması beklenir. Bugün için bu öncülüğü yapay zeka modellerinin üstlenmesi gerekiyor.

Sonuç

Claude ve Gemini’nin 2026’da yakınsadığı beş saatlik dilim + haftalık tavan mimarisi, kullanım adaletini sağlamak için makul bir başlangıç noktasıdır, ama iş yükü ile zaman dilimi arasındaki katı eşleşme, hem ölü zaman hem de yarım kalan iş kaybı biçiminde gerçek bir sürtünme yaratmaktadır. Veresiye Kota önerisi, kullanıcının zaten hak ettiği kotanın toplamını değil, yalnızca zaman içindeki dağılımını esnetmeyi öneriyor: sıkı ama keyfi olmayan kurallarla (kaynak başına miktar tavanı, zincirsiz transfer, şeffaflık) çevrelenmiş, kullanıcı talebiyle ya da sistemin kendi gözlemi/ön-hesabıyla tetiklenebilen, hem kullanıcı hem sistem için adil bir zaman yönetimi modeli. Bu, yapay zeka şirketleri için kısa vadede bir gelir gerilimine yol açabilir, ama uzun vadede kullanıcı güveni ve verimlilik ilkesiyle tam örtüşen bir yöndür.

Künye

Bu makale, Aydın Tiryaki ile Claude (Anthropic) arasında Temmuz 2026’da gerçekleşen kapsamlı bir sohbet temelinde hazırlanmıştır. Yöntem şu şekilde işlemiştir: önce mevcut kota sistemlerinin teknik işleyişi (beş saatlik dilimlerin başlangıç mantığı, haftalık sınırların sabitliği, 24’ün 5’e bölünmemesinden doğan kayma, model bazlı farklılaşma) adım adım, karşılıklı soru-cevap ve doğrulama yoluyla netleştirilmiştir. Bu aşamada Aydın Tiryaki’nin kendi Gemini ve Claude kullanım deneyiminden aktardığı gözlemler (ekran görüntüleriyle desteklenen zaman dilimi başlangıçları, Gem Fabrikası ve ATG Gem/GPT Proje Dağarcığı üzerindeki somut kota tüketim örnekleri) belirleyici veri kaynağı olmuştur; Claude ise bu gözlemleri güncel kaynaklarla (Anthropic ve Google’ın resmi destek belgeleri ile bağımsız teknik incelemeler) doğrulamış ve teknik çerçeveyi bütünleştirmiştir.

Makalenin özünü oluşturan Veresiye Kota önerisi — temel fikri, kurallarını (miktar tavanı, hedef kısıtlaması, çoklu kaynak, zincirsiz transfer, iki kademeli yapı), tetikleyici kanallarını ve ekonomik/etik gerekçesini içeren tüm çekirdek — tamamen Aydın Tiryaki’ye aittir ve sohbet boyunca onun art arda gelen açıklamalarıyla adım adım inşa edilmiştir. Claude’un bu süreçteki katkısı, önerilen fikirleri teknik olarak sınıflandırmak, tutarlılıklarını sınamak, ilgili terminolojiyle ifade etmek ve nihayetinde bu makale metnini yazılı forma dökmek ile sınırlıdır. Bu nedenle makale, Aydın Tiryaki imzasıyla yayınlanmaktadır.

Yazan: Aydın Tiryaki Katkı: Claude (Anthropic, Sonnet 5) — teknik doğrulama, çerçeveleme ve metin yazımı Tarih: Temmuz 2026 Yayın: aydintiryaki.org

| aydintiryaki.org | YouTube | Aydın Tiryaki’nin Yazıları ve Videoları │Articles and Videos by Aydın Tiryaki | Bilgi Merkezi│Knowledge Hub | ░ Virgülüne Dokunmadan │ Verbatim ░ | ░ Veresiye Kota: Yapay Zekada Zaman Adaletine Doğru │Quota on Credit: Toward Time Fairness in AI Usage Limits ░ 13.07.2026

Kategoriler

Bağlantılar