Codex maliyet testi 20260225081848

1 saat önce

15 dakika

Codex maliyet testi, Codex’i abonelikte mi yoksa API üzerinden mi kullanmanın toplam bütçenize etkisini netleştiren, gerçek görevlerle yapılan kısa bir denemedir. Sadece liste fiyatına bakmak yerine token tüketimi, çalışma süresi, tekrar denemeler, araç çağrıları ve insan incelemesi gibi kalemleri görünür kılar. Sağlam bir ölçüm için 5-10 temsilî iş seçin: küçük hata düzeltmesi, test yazımı, refactor ve kod incelemesi; her görevde giriş-çıkış token’larını, bağlamın büyümesini ve kullanım limitleri yüzünden oluşan beklemeyi not edin. Maliyeti çoğu zaman modelden çok, özellikle uzun oturumlarda aynı dosyaların tekrar tekrar bağlama taşınması ve testlerin yeniden çalıştırılması şişirir.

Codex fiyatlandırma modelleri: abonelik mi API token mı?

Abonelik kapsamına giren kullanım türleri

Codex’i en pratik şekilde ChatGPT aboneliği üzerinden kullanabilirsiniz. Codex; web, CLI, IDE eklentileri ve Codex uygulaması gibi yüzeylerde ChatGPT hesabınızla çalışır ve Plus, Pro, Business, Enterprise/Edu planlarında “dahil kullanım” olarak sunulur. Dahil kullanım, “sınırsız” değil kota ve hız limitleri (örneğin belirli zaman pencerelerinde mesaj veya bulut görevi limiti) mantığıyla ilerler.

Limitleri aştığınızda iki tip yol ortaya çıkar: plan yükseltmek ya da planınız izin veriyorsa ek kredi satın alarak Codex’i kullanmaya devam etmek. Kurumsal tarafta ise ek kullanım genelde koltuk başına limitler ve/veya çalışma alanı kredi havuzu gibi bir yapıya bağlanır. Bu yüzden abonelik, düzenli ve öngörülebilir iş akışında “paket” maliyetiyle avantajlı olabilir.

API anahtarıyla ücretlenen kullanım türleri

İkinci model, Codex’i API anahtarı ile çalıştırıp “kullandığın kadar öde” yaklaşımıyla ilerlemektir. Burada ücret; seçtiğiniz modelin girdi token, çıktı token ve varsa cached input (önbellekli girdi) fiyatlarına göre hesaplanır. Örneğin API fiyat kartında gpt-5.1-codex için 1M token başına girdi $1.25, cached input $0.125, çıktı $10.00 gibi oranlar yer alır; güncel tabloyu OpenAI API fiyatlandırma sayfasında kontrol etmek gerekir.

Ayrıca bazı yerleşik araçlar (ör. web arama gibi) token’a ek araç çağrısı maliyeti doğurabilir. Maliyet testinde bu kalemleri ayrıca izlemek önemlidir.

Hangi raporlama farkları önemli?

Maliyet testi yaparken farkı yaratan şey, “hangi model daha ucuz?” sorusundan çok hangi raporu ne kadar ayrıntıyla aldığınız olur. API tarafında genelde kullanım; model, anahtar/organizasyon, araç çağrısı ve dönem bazında daha kolay kırılımlanır. Abonelik tarafında ise çoğu ekip, harcamayı token yerine limit ve kredi tüketimi üzerinden takip eder. Müvekkil bazlı masraf dağıtımı, iç proje maliyetlendirmesi veya “bu görev neden pahalıya geldi?” analizi hedefleniyorsa API raporları pratikte daha elverişli olur.

Codex kullanım ücreti token bazında nasıl hesaplanır?

Girdi token ve çıktı token farkı

Codex’i API ile kullandığınızda maliyetin ana gövdesi token üzerinden çıkar. Basitçe iki kalem vardır: girdi token (input) ve çıktı token (output). Girdi token; sisteme verdiğiniz her şeyi kapsar: sistem talimatı, kullanıcı isteği, kod parçaları, dosya içerikleri, araç (tool) şemaları ve önceki konuşma geçmişi. Çıktı token ise modelin ürettiği yanıtın tamamıdır.

Önemli detay: Birçok modelde çıktı token birim fiyatı, girdi tokenden daha yüksektir. Bu yüzden “tek seferde uzun kod yazdırma” ya da “çok uzun açıklama isteme” maliyeti hızla yükseltebilir.

Ayrıca bazı ayrıntı token türleri de faturalamaya dahildir. Örneğin “reasoning tokens” veya “rejected prediction tokens” gibi kalemler, kullanım dökümünde ayrı görünebilse bile toplam çıktı token hesabına dahil edilerek ücretlendirilir.

Önbellekli girdi ve caching indirimi mantığı

Tek bakışta ödeme metrikleri tablosu

Prompt caching (önbellekleme), aynı isteğin tekrar eden baş kısmı (özellikle sabit talimatlar ve ortak bağlam) değişmediğinde girdi token maliyetini düşürmeye yarayan otomatik bir mekanizmadır. Genelde 1024 token ve üzeri prompt’larda devreye girer ve yalnızca tam prefix eşleşmesi yakaladığında “cached” sayılır. Kullanım alanında prompt_tokens_details.cached_tokens olarak raporlanır.

Metrik	Ne demek?	Ücrete etkisi	Nerede görünür?
`prompt_tokens`	Toplam girdi token	Input fiyatından ücretlenir	API yanıtı `usage` alanı
`cached_tokens`	Önbellekten gelen girdi token	“Cached input” fiyatı daha düşüktür	`prompt_tokens_details.cached_tokens`
`completion_tokens`	Toplam çıktı token	Output fiyatından ücretlenir	API yanıtı `usage`
Araç çağrıları	Web search, Code Interpreter vb.	Token’a ek sabit çağrı ücreti olabilir	Fiyatlandırma kalemleri

Codex için hızlı maliyet tahmini formülü ve gerekli girdiler

Ortalama token ve istek sayısı varsayımları

Hızlı bir Codex maliyet tahmini için önce “tek istek ortalaması” çıkarın. En pratik yol, 20-50 gerçek isteğin logundan ortalama almaktır. Ölçemiyorsanız muhafazakar varsayımla başlayın.

Gerekli girdiler:

Ortalama girdi token: prompt + bağlam (dosyalar, önceki mesajlar, tool şemaları).
Ortalama çıktı token: üretilen kod + açıklama.
Aylık istek sayısı: geliştirici başına günlük istek x gün sayısı gibi.
Tekrar/yeniden deneme katsayısı: hata, timeout, kalite iyileştirme için aynı işi kaç kez çalıştırdığınız (ör. 1.15).
Cache oranı: aynı prefix tekrarlandıkça girdi token’ın ne kadarı cached sayılacak (ör. %30).

Bu varsayımlar, “tek seferde” küçük görünen işleri aylık ölçekte görünür hale getirir.

Model seçimine göre birim fiyat değişkeni

Formülde fiyat tarafı tamamen modele bağlıdır. Çoğu modelde üç ayrı birim fiyatla karşılaşırsınız: input, cached input ve output. Ayrıca bazı araç çağrıları token’a ek bir kalem olarak fiyatlanabilir. Bu yüzden maliyet testinde model değiştirirken yalnızca “daha ucuz input”a değil, output fiyatına ve cache indiriminin gerçekten devreye girip girmediğine bakın.

Güncel birim fiyatları bütçe tablonuza koymadan önce resmi fiyat kartından kontrol edin: OpenAI API pricing.

Aylık bütçe tahmini için örnek şablon

Aşağıdaki formül, hızlı ve yönetilebilir bir aylık tahmin verir:

Aylık Maliyet ≈ İstek_Sayısı x Tekrar_Katsayısı x
( (Input_Token x (1-Cache_Oranı) x Input_Fiyat)
+ (Input_Token x Cache_Oranı x Cached_Input_Fiyat)
+ (Output_Token x Output_Fiyat)
+ (Araç_Ücreti_Ortalama) )

Tabloya ekleyebileceğiniz iki pratik kolon daha:

“Maks. çıktı token limiti”: uzun yanıtları kırparak sürpriz maliyeti azaltır.
“Kur ve muhasebe payı”: Türkiye’de gider bütçesi genelde TL tutulduğu için, ödeme para birimi ve dönemsel kur etkisini ayrı satırda takip etmek daha sağlıklı olur.

Aynı görevle Codex maliyet testi yapma yöntemi

Test görevi seçimi ve sabit tutulan değişkenler

Maliyet testinin güvenilir olması için, “aynı işi” farklı kurulumlarla koşturmanız gerekir. Önce 3-5 adet temsilî görev seçin. Örnek: küçük bug fix, refactor, yeni test yazımı, API entegrasyonu, repo genelinde arama ve düzenleme.

Sonra değişkenleri sabitleyin:

Kod tabanı anlık görüntüsü: aynı commit, aynı bağımlılıklar.
Görev tanımı: aynı acceptance kriterleri, aynı “done” tanımı.
Bağlam: aynı dosyalar, aynı örnek girişler, aynı talimat şablonu.
Ayarlar: aynı araçlar (test runner, linter), aynı çıktı limiti (max output tokens), aynı rastgelelik (temperature düşük ve sabit).
Veri güvenliği: gerçek müvekkil verisi, kişisel veri veya sır niteliğinde belge varsa maskeleme ve veri minimizasyonu uygulayın; KVKK ve mesleki gizlilik açısından gereksiz veri taşımayın.

Bu sabitleme, “model farkı mı, yoksa işin değişmesi mi?” sorusunu netleştirir.

Farklı model ve ayarlarla karşılaştırmalı deneme

Her görevi aynı sırayla, en az 3 tekrar olacak şekilde çalıştırın. Tek bir koşu yanıltıcı olabilir; ağ gecikmesi, araç hatası, yeniden deneme gibi etkiler ortalamayı bozar. Bu yüzden raporda ortalama yanında medyan değer de tutmak faydalıdır.

Kıyaslayacağınız eksenler:

Model A vs Model B
Aynı modelde farklı çıktı limiti
Aynı modelde “önce plan sonra uygula” yaklaşımı (plan + uygulama iki adım) vs tek adım

Sonuçları karşılaştırma: token, süre, çıktı kalitesi

Sonuçları tek bir tabloya toplayın ve üç metriği birlikte okuyun:

Token: input, cached input, output ve toplam maliyet.
Süre: duvar saati süresi, testlerin çalışması dahil toplam görev süresi.
Kalite: derleniyor mu, testler geçiyor mu, diff boyutu makul mü, ek insan inceleme süresi ne kadar.

Pratik bir kalite puanı yaklaşımı: “0: çalışmıyor”, “1: çalışıyor ama standart dışı”, “2: çalışıyor ve kabul edilebilir”, “3: temiz ve üretime yakın”. Böylece en ucuz seçeneğin, aslında en pahalı insan zamanı maliyetini yaratıp yaratmadığını görürsünüz.

Mini senaryolarla Codex kullanım maliyeti hesaplama

Kod düzenleme ve refactor senaryosu

Bu senaryoda maliyeti şişiren şey çoğu zaman “yeni kod üretimi” değil, bağlama taşınan dosya boyutu ve tekrar eden açıklamalardır. Refactor istendiğinde Codex’e çok sayıda dosya verilir, ardından birkaç tur geri bildirim yapılır. Her turda aynı dosyalar tekrar prompt’a giriyorsa input token hızla büyür.

Hızlı hesap için yaklaşım:

1 refactor görevi = 3 tur (plan, uygulama, düzeltme)
Tur başına input token = “ortak talimat + ilgili dosyalar + son diff”
Tur başına output token = “patch + kısa gerekçe”

Refactor’da tasarruf kuralı nettir: Gerekmeyen dosyayı bağlama koymayın. Çıktıda “uzun açıklama” yerine kısa gerekçe isteyin. Aynı talimat şablonu kullanıyorsanız caching indirimi de daha sık devreye girer.

Test çalıştırma ve hata ayıklama senaryosu

Test ve debug akışında, token’dan çok yeniden deneme sayısı belirleyicidir. Bir test hatası geldiğinde Codex çoğu zaman logları okur, hipotez kurar, kodu değiştirir ve testleri tekrar koşturur. Bu döngü 2-6 tur sürebilir.

Maliyet hesaplamak için:

Her turda input token artar (loglar + önceki konuşma + yeni kod parçası)
Output token genelde orta düzeydedir (küçük patchler)

Burada maliyeti kontrol etmek için iki pratik sınır koyun: (1) Test loglarını kısaltın, sadece ilgili kısmı verin. (2) Maksimum deneme sayısı belirleyin; örneğin 3 turdan sonra insan devralır. Bu, “küçük bir bug fix”in sessizce uzun bir ajan görevine dönüşmesini engeller.

Uzun ajan görevi ve repo tarama senaryosu

Repo tarama, büyük kod tabanında bağımlılık analizi, güvenlik kontrolü veya “şu desen nerelerde var?” gibi işlerde Codex genelde çok sayıda dosyaya bakar. Bu tip uzun ajan görevlerinde iki maliyet sürücüsü öne çıkar: geniş bağlam ve araç çağrıları (dosya okuma, arama, test çalıştırma gibi).

Kabaca hesap:

Toplam maliyet ≈ (dosya okuma ve arama ile oluşan toplam input) + (bulgular raporu için output) + (varsa araç ücretleri)
Uzadıkça caching faydası artabilir ama her adımda yeni dosyalar eklendiği için cache oranı beklediğiniz kadar yüksek olmayabilir

Bütçe kontrolü için görevi parçalara bölün: “ön tarama” (sadece dizin yapısı ve kritik klasörler), ardından “derin tarama” (seçilen modüller). Böylece hem token hem de süre daha öngörülebilir olur.

Codex’te token kullanımı nereden izlenir ve raporlanır?

CLI ve uygulama tarafında görülen metrikler

Codex CLI’da en hızlı kontrol noktası /status komutudur. Bu çıktı; aktif modeli, oturum politikalarını ve mevcut token kullanımını tek ekranda gösterir. Aynı sayfada kalan bağlam kapasitesini de görürsünüz. Daha pratik takip için /statusline ile alt durum satırına “token sayaçları, limitler, bağlam” gibi alanları ekleyebilirsiniz.

API tarafında ise “ne kadar harcadım?” sorusunun en temiz cevabı her yanıtın içindeki usage alanıdır. Responses API, input_tokens, output_tokens, total_tokens ve ayrıca önbellekten gelen kısım için cached token kırılımını döndürür.

Kurumsal izleme için OpenAI Platform’daki Usage Dashboard, dönemsel harcamayı ve aktiviteyi toplu görmeyi sağlar. Özellikle proje seçimi ve dakika seviyesinde (TPM gibi) detaylara inmek gerektiğinde dashboard işinizi kolaylaştırır.

Ayrıntılı loglama ile harcama dökümü alma

Maliyet testi yapıyorsanız “oturum içi sayaç” tek başına yetmez. Görev bazında döküm için Codex’in non-interactive akışında codex exec --json kullanıp JSON Lines (JSONL) çıktısını dosyaya alın. Örnek akışta her turn.completed olayında input_tokens, cached_input_tokens ve output_tokens ayrı ayrı gelir. Böylece aynı görev için deneme sayısı, tur sayısı ve toplam token kolayca toplanır.

Avukatlık pratiğinde bu loglar, istemeden kaynak kodla birlikte kişisel veri veya sır niteliğinde bilgi de içerebilir. Bu yüzden loglarda veri minimizasyonu yapın, gerekirse maskeleme uygulayın ve saklama süresini içeride net bir politikaya bağlayın.

CI ve otomasyonda kullanım takibi

CI’da izleme için iki pratik yol var. İlki, pipeline içinde codex exec --json çalıştırıp JSONL çıktısını “build artifact” olarak saklamak. Kimlik doğrulamada tek koşuluk kullanım için CODEX_API_KEY değişkenini job secret olarak verebilirsiniz (bu yöntem codex exec için tanımlıdır).

İkincisi GitHub üzerinde Codex GitHub Action kullanmaktır. Action, son mesajı çıktı olarak taşıyabilir ve ayrıca bir dosyaya yazdırmanıza izin verir. Bu dosyayı PR’a ek yorum, kalite kontrol kaydı veya maliyet testi çıktısı olarak arşivleyebilirsiniz.

Daha merkezi raporlama isteyen ekipler, dashboard’a ek olarak organizasyon seviyesinde Usage API ve Costs API uçlarıyla periyodik sorgu çekip alarm ve bütçe uyarısı kurabilir.

Codex maliyetini düşürmek için pratik kontrol mekanizmaları

Model seçimi kuralları ve görev kapsamı daraltma

En hızlı tasarruf, “her işe aynı modeli” kullanmamakla başlar. Basit işler (format düzeltme, tek dosyada küçük refactor, kısa test ekleme) için daha hafif bir model, çoğu ekipte toplam maliyeti belirgin düşürür. Zor işler (çok dosyalı mimari değişiklik, karmaşık hata ayıklama) için güçlü modele çıkmak daha mantıklıdır.

Görev kapsamını daraltmak da kritik. Codex’e “repo genelinde düzelt” demek yerine, hedefi bölün: önce ilgili modülü bul, sonra yalnızca şu dosyaları değiştir, sonra testleri koş. Bağlama eklenen dosya sayısı azalınca input token ve tur sayısı birlikte düşer. Ayrıca çıktıyı “diff/patch odaklı” istemek, gereksiz açıklama ve tekrarları azaltır.

Limit, uyarı ve durdurma noktaları

Maliyet patlamaları genelde uzun ajan döngülerinde olur. Bu yüzden teknik ve süreçsel frenler koyun:

Maksimum çıktı token: Her çağrıda üst sınır belirleyin.
Deneme sınırı: “Aynı hata için en fazla N deneme” kuralı koyun. N aşıldığında insan devralır.
Zaman sınırı: Görev 10-15 dakikayı aşıyorsa durdur, ara özet iste, sonra devam et.
Bütçe uyarısı: Proje bazında aylık tavan; günlük veya iş başına eşik. Eşik aşılınca otomatik durdurma veya onay akışı.

Avukatlık işlerinde ayrıca veri minimizasyonu maliyeti de düşürür. Gereksiz ekleri, uzun dokümanları ve kişisel veriyi prompt’a taşımamak hem KVKK hem bütçe açısından daha güvenlidir.

“Önce plan sonra uygula” ile sürpriz harcamayı azaltma

“Önce plan sonra uygula” yaklaşımı, özellikle refactor ve debug işlerinde tur sayısını azaltır. İlk adımda Codex’ten 5-10 maddelik kısa bir plan ve hangi dosyalara dokunacağını listelemesini isteyin. Planı onayladıktan sonra ikinci adımda yalnızca o dosyalarda değişiklik yaptırın.

Bu yöntem iki yerde kazandırır: (1) yanlış yöne giden uzun çıktıların önüne geçer, (2) gereksiz dosyaların bağlama eklenmesini engeller. Sonuçta token tüketimi kadar, insan inceleme süresi de daha öngörülebilir hale gelir.