Geçenlerde codexte kodlama yaptırırken çok fazla token kullanıldığından bahsetmiştim bir çok denemenin ardından ve araştırmalarım sonucu sorunu büyük ölçüde çözdüm.

İşte Rehber

Bir program yaptıracağınızda ya da mevcut programda güncelleme yapacağınız zaman şunları uygulayın:

1) Her iş için yeni sohbet açın
Uzun bir sohbette Codex her çalıştığında sohbet geçmişini ve proje dosyalarını yeniden okuyor, bu yüzden sohbet uzadıkça her mesaj daha pahalı oluyor. Ben altı programı tek sohbette yaptırıyordum ve limitin çabuk bitmesinin ana nedenlerinden biri büyük ihtimalle buydu. Kural: bir iş = bir sohbet. İş bitince sohbeti bırakın, yeni iş için yeni sohbet açın.

2) Bilgiyi sohbette değil, proje dosyalarında tutun
Proje klasörünün köküne şu dosyaları koyun:

• AGENTS.md: çalışma kuralları (hangi klasörde çalışılacak, verilere dokunulmayacak, test nasıl raporlanacak vb.). Kısa tutun, çünkü her çalıştırmada yeniden okunuyor.
• README.md: programın ne olduğu, belgelerin nerede olduğu.
• BACKLOG.md: bekleyen işler. Yarım kalan iş buraya yazılsın.
• CHANGELOG.md: tamamlanan değişiklikler.

Yeni sohbet bu dosyaları okuyarak başlar, siz her seferinde baştan anlatmak zorunda kalmazsınız.

3) İlk mesajı şablonla verin

AGENTS.md ve README.md'yi oku, ardından yalnız bu özellikle ilgili docs belgelerini oku (hepsini değil). Yalnız [program klasörü] programında çalışacağız.

Özellik: [ne istediğiniz, bir iki cümle]
Neden: [hangi sorunu çözüyor]
Nerede görünecek: [hangi ekran]
Kabul ölçütü: [ne görünce "tamam" diyeceğiniz]
Dokunma: veritabanı verilerine, modellere, mevcut işlevlere.

Önce kodu değiştirme, kısa bir plan yaz: etkilenen dosyalar, riskler, kaç adım. Ben onaylayınca uygula. Bitince: ne değişti, hangi testler gerçekten çalıştı, ekran kontrolü yapıldı mı, CHANGELOG'a ne yazıldı. Kısa tablo.

4) Önce plan, sonra uygulama
Yanlış anlaşılmayı planda yakalamak, yanlış yapılmış işi düzeltmekten çok daha ucuz. "Önce plan yaz, ben onaylayınca uygula" demek kotayı korur.

5) Kısa rapor isteyin
"Tek tablo, yorum yok" demek hem token hem okuma zamanı kazandırıyor. Uzun açıklamalar sohbeti şişirir.

6) Model ve akıl yürütme düzeyini bilinçli seçin

• Rutin işlerde (ekran düzeltme, belge, küçük özellik) orta kademe model ve orta düzey yeterli olabilir.
• Zor ve hata maliyeti yüksek işlerde (veri, hesap, karmaşık mantık) güçlü modeli kullanın.
• En yüksek akıl yürütme düzeylerini (ultra, max gibi) sadece gerçekten gerekirse açın, bunlar çok daha fazla token harcıyor.
• Alt ajan / çoklu ajan özelliği açıksa kapatın, her ajan ayrı kota yiyor.

Seçicideki model adları ve düzeyler sürüme göre değişebilir, kendi ekranınızdaki açıklamaları okuyun.

7) Bağlam sıkıştırmasını beklemeyin
Sohbet uzayınca Codex bağlamı otomatik daraltıyor. Bu hem token yiyor hem de sıkıştırma sırasında görev durumu eksik kalabiliyor. Sohbet uzamaya başladıysa işi bitirip yeni sohbete geçin.

8) Limit bitince sadece "devam et" yazmayın
"Kaldığın yerden devam et" demek, Codex'in sohbet özetine güvenmesine yol açıyor. Bitmiş işi tekrar yapabiliyor ya da yarım kalanı atlayabiliyor. Bunun yerine:

Önce hiçbir şeyi değiştirme. BACKLOG.md'ye ve git durumuna bak. Yarım kalan işte hangi dosyalar değişti, hangi adımlar bitti, hangileri kaldı, kanıtla raporla. Emin olmadığın yere "bilmiyorum" yaz. Ben onaylayınca yalnız kalan adımı yap.

9) Büyük çıktı ve log yapıştırmayın
Hata mesajının yalnızca ilgili kısmını verin. Uzun loglar ve büyük dosyalar bağlamı gereksiz şişirir.

10) Kullanım ekranını izleyin
Codex'in kullanım panelinden hangi sohbet ve hangi model ne kadar yiyor bakın. Bir hafta bu kurallarla deneyin, farkı kendi hesabınızda ölçün.

11) Git ve yedek
Yarım kalan bir işin geri alınabilmesi için proje git altında olsun, veritabanı ve model gibi büyük dosyalar için de ayrı, harici bir yedek tutun. Kota bitip iş yarıda kalınca "ne değişti" sorusunun cevabı hazır olur.

Özet:

• Bir iş = bir sohbet
• Bilgi dosyada (AGENTS.md, BACKLOG.md), sohbette değil
• Önce plan, sonra uygulama
• Kısa rapor
• Gereksiz yüksek düzey ve alt ajan yok
• Limit bitince "devam et" değil, "önce durumu kanıtla" de

Not: Bunlar kendi deneyimim ve topluluk kaynaklarından topladıklarım, resmî bir OpenAI önerisi değil. Kullanım hesabı sürüme ve plana göre değişebilir, kendi hesabınızda deneyip ölçün.

Sorusu olan yazsın, bildiğim kadarıyla yardımcı olurum.