Güncelleme — 2026 yazı: benim için artık çalışmıyor
2026 yazına gelindiğinde bu workflow benim için güvenilir şekilde çalışmayı bıraktı. Hesabımdaki 5 saatlik kullanım sayacı kayboldu, haftalık limit ise görünür kaldı. Pratikte, bu yöntemi daha önce etrafında planladığım kısa sıfırlama penceresi ortadan kalkmış oldu.
Daha önemli değişiklik uzun süren görevlerdeydi. Büyük bir Codex görevi haftalık limitimin sonuna geldiğinde, işin tamamlanana kadar devam etmek yerine durduğunu gördüm. Bu yüzden eski “son %3–5’te en ağır görevi başlat” kuralım büyük ölçüde anlamını yitirdi: başlamış bir görevin haftalık limitin sonunu aşarak devam edeceğine artık güvenemiyordum.
Yine de kendi gözlemimle resmi ürün kuralını ayırmak gerekiyor. Kendi hesabımda ve workflow’umda gördüğüm şeyi doğrulayabilirim; OpenAI’ın 5 saatlik pencereyi tüm kullanıcılar için kalıcı olarak kaldırdığını kanıtlayamam. Güncel Codex belgeleri hâlâ hem 5 saatlik hem haftalık kullanım pencerelerinden söz ediyor ve aktif bir turn’ün limite ulaşıldıktan sonra fair-use sınırlarına tabi olarak bazen devam edebileceğini belirtiyor. Bu nedenle 2026 yazındaki değişikliği, kendi deneyimimde gördüğüm gerçek davranış olarak yazıyorum; tüm hesaplar için evrensel bir kural olarak değil.
Makalenin geri kalanı, bu değişiklikten önce benim için gerçekten çalışan workflow’un kaydı olarak korunuyor. Yukarıdaki güncelleme, eski metindeki şimdiki zamanla yazılmış önerilerin önüne geçiyor.
ChatGPT Plus planımdaki Codex kullanım sayacı yaklaşık son %3–5’e düştüğünde kalan kısmı küçük prompt’lara harcamıyorum. Tam tersini yapıyorum: önceden hazırladığım en büyük mühendislik görevini başlatıyorum.
Benim durumumda bu genellikle tam kapsamlı TypeScript migration, repository genelinde ESLint cleanup, büyük bir codebase üzerinde derin bug review veya büyük yapısal refactor oluyor. Son kullanım dilimini gerçekten hazır olan en ağır işe verebilmek için çoğu zaman birden fazla projeyi önceden hazırlıyorum.
Bunun nedeni tekrarlanan bir gözlem. Birden fazla kez görünür limitin sonuna yakın büyük bir iş başlattım ve limit tükenmiş gibi göründükten sonra da Codex’in çalışmaya devam ettiğini gördüm. Bazen task tamamlanacak kadar ilerledi. Bu, çalışma planımı değiştirecek kadar tekrarlandı; ama bunu ürün garantisi sayacak kadar değil.
Workflow’umu değiştiren gözlem
Bir kullanım limitine yaklaşınca doğal refleks konservatif olmaktır: büyük bir task kesilebilir diye kalan kısmı küçük isteklere harcamak. Ben artık son %3–5’i farklı görüyorum. Benim için bu bir launch window.
Artık sorduğum soru “kaç küçük prompt daha sığdırabilirim?” değil. “Included usage hâlâ varken, hazır görevlerden hangisini başlatmak en yüksek değeri sağlar?”
Bu ancak proje zaten hazır ve task net tanımlı olduğu için çalışıyor. Son birkaç yüzdeyi ne yapılacağını keşfetmek için kullanmıyorum; execution başlatmak için kullanıyorum.
İsim ve limitlerle ilgili önemli bir düzeltme
Başta buna “Codex Plus” diyordum, ancak bu resmi ürün adı değil, yalnızca shorthand. OpenAI Codex’in ChatGPT Plus’a dahil olduğunu söylüyor. Codex Plus ayrı bir plan veya ürünmüş gibi görünmemesi için bu ayrımı düzeltmek önemli.
OpenAI’nin güncel Codex kullanım dokümantasyonu tüketimin işin boyutu ve karmaşıklığına, modele ve task’ın nerede çalıştığına göre değiştiğini de açıklıyor. 5 saatlik ve haftalık usage window’lar da belgelenmiş durumda. Bu nedenle “%3–5” derken usage arayüzünde görünen remaining percentage’ı kastediyorum; gerçek zamanın, token’ların veya garantili mühendislik işinin %3–5’ini değil.
Uygun Plus kullanıcıları included limit sonrasında credits ile Codex kullanımını uzatabiliyor. Bu workflow’u geçersiz kılmıyor; yalnızca sınırını netleştiriyor. Ben plana dahil kullanımı nasıl dağıttığımı anlatıyorum, quota bypass etmeyi değil.
Son %3–5’te ne başlatıyorum
Bu ana sakladığım görevler genellikle geniş mühendislik operasyonları:
- tam kapsamlı TypeScript migration
- repository-wide ESLint cleanup
- büyük codebase’lerde derin bug review
- büyük yapısal refactor
Kalan kullanımı düşük değerli küçük istekler dizisine bölmek yerine bu işlerden birini ciddi bir çalışma bloğu olarak başlatmayı tercih ediyorum. Bu tür task’larda akıllıca prompt cümlelerinden çok hazırlanmış repository ve net hedef önemlidir.
Birden fazla projeyi hazır tutmanın faydası da aynı. Bir repository hâlâ karar veya setup gerektiriyorsa son window’u onu hazırlamakla harcamıyorum; hazır olan başka bir projede iş başlatabiliyorum.
Gerçek kısıt preparation
Numara “%3’e kadar bekle, sonra dev bir prompt yapıştır” değil. Task belirsizse sınırlı budget exploration, clarification veya yanlış yöndeki işte kaybolabilir. Benim pattern’im yalnızca proje execution-ready ve task iyi sınırlandırılmışsa faydalı.
Benzer workflow deneyenler için pratik preflight: ne değişmeli, ne değişmemeli, hangi constraint’ler var, sonuç nasıl validate edilecek ve agent’tan hangi output bekleniyor? Bunlar genel engineering safeguard’lardır; belirli prompt formatının daha fazla kullanım açtığının kanıtı değildir.
Bu hazırlık, limit gerçekten task’ı durdurursa devam etmeyi de kolaylaştırır. Scope ve validation criteria en baştan net olduğunda yarım kalmış migration veya review çok daha kolay sürdürülür.
Neyi doğrulayabilirim — neyi doğrulayamam
Kendi kullanımımdan doğrulayabildiğim şey dar kapsamlı: birkaç kez zaten başlatılmış task görünür usage limit tükenmiş gibi göründükten sonra da ilerlemeye devam etti ve bazen tamamlandı.
Mechanism’i doğrulayamam. OpenAI’nin her running task’a hidden grace period verdiğini, son %3–5’in herhangi büyüklükteki işi bitirmeye yeteceğini, davranışın stabil olduğunu veya limit aşmanın yolu olduğunu söyleyemem. OpenAI dokümantasyonu bunların hiçbirini vaat etmiyor.
Bu ayrım önemli. Tekrar tekrar gördüğüm bir behavior’ı dikkate alarak plan yapıyorum, ama garanti gibi bağımlı olmuyorum. Task limitte durursa bu bir şeyin bozulduğu anlamına gelmez. Kalan included usage birkaç küçük prompt yerine daha önemli işe gittiyse strateji yine amacına ulaşmıştır.
Task’ın bitmesi doğrulandığı anlamına gelmez
Task büyüdükçe ikinci ayrım daha önemli hale gelir: completion, correctness değildir. Build alan TypeScript migration doğru runtime behavior kanıtı değildir. Temiz ESLint business logic’in doğru olduğunu kanıtlamaz. Bug review’un şüpheli pattern işaretlemesi gerçek bug bulunduğu anlamına gelmez. Tests geçen refactor bile ancak onu kapsayan tests ve checks kadar güvenilirdir.
Bu workflow yalnızca işe ne zaman başladığımı değiştirir; validation standardını düşürmez. Büyük agentic changes hâlâ riske uygun kontroller ister: diff review, typecheck, tests, build, runtime checks veya projeye özgü verification.
Bu pattern ne zaman kötü fit olur
Her büyük task end-of-limit task değildir. İş hâlâ belirsizse, sık ürün kararı gerektiriyorsa, destructive veya production-sensitive operation içeriyorsa ya da yarıda kesilince repository’yi riskli durumda bırakıyorsa bu yaklaşım zayıftır.
Bu durumlarda daha küçük, well-bounded task veya yeni usage window genellikle daha iyi engineering seçimidir. Amaç son prompt’u dramatik yapmak değil; kıt included usage’ı güvenli biçimde yararlı progress üretebilen işe harcamaktır.
Şimdiki kuralım
ChatGPT Plus’taki included Codex usage yaklaşık %3–5’e indiğinde kalan prompt sayısını optimize etmeyi bırakıyorum. Önceden hazırladığım projelere bakıp en ağır, scope’u net ve gerçekten yapmaya değer engineering task’ı başlatıyorum.
Visible counter sıfıra geldikten sonra Codex çalışmaya devam ederse bunu yararlı bir observed behavior olarak görüyorum, hak olarak değil. Durursa şaşırmıyorum. Limiti bypass etmenin yolunu bulmadım. Limite ulaşmadan önce neyi başlatacağıma daha iyi karar vermenin yolunu buldum.