Vibe Kodlamanın Ekonomik Formülü ve Kritik Noktalar

Token, API çağrıları ve prompt sayısı olmak üzere üç temel ücretlendirme modelinin maliyetini ortak değişkenlerle modelleyip kritik nokta formüllerini ve çalışma önerilerini sunar.

Wednesday, January 07, 2026

Categories:

Görüş

Yapay zeka kodlama araçlarının ücretlendirme modelleri üç ana başlıkta toplanabilir:

Token bazlı ücretlendirme: API’ler, Claude Code (Claude Pro), Codex Cli (ChatGPT Plus), Zhipu Lite/Pro, Cursor yeni sürüm vb. temelde hepsi token bazlı ücretlendirmeye dayanır, bazı ürünler paket indirimleri sunabilir.
API çağırı sayısı bazlı ücretlendirme: OpenRouter (ücretsiz kota), ModelScope, Gemini Code Assistant (günlük 1000), Chutes vb.
Prompt sayısı bazlı ücretlendirme: Cursor eski sürüm (500), Github Copilot (300) vb.

Bu üç model temelde aynı “model çıkarımı ve bağlam işleme” maliyetini yansıtır, farklar fiyatlandırma granülitesi ve limit biçiminde ortaya çıkar.

Bu yazıda, farklı çalışma yükleri ve çalışma biçimlerindeki tercih kritik noktalarını belirleyen, uygulanabilir değişken tanımları ve formüller sunan ortak bir maliyet modeli kurulur. Maliyet, nakit harcamayı, zaman maliyetini ve yeniden çalışma riskini kapsar.

Ortak Toplam Maliyet Fonksiyonu

Herhangi bir araç i için, bir fatura dönemindeki toplam maliyet şöyle ifade edilebilir:

$$ \begin{aligned} \mathrm{Total}_i &= \mathrm{Cash}_i + \mathrm{Time}_i + \mathrm{Risk}_i \ \mathrm{Time}_i &= R \cdot \mathrm{Hours}_i \ \mathrm{Risk}_i &= R \cdot \mathrm{ReworkHours}_i \end{aligned} $$

Burada R, zaman birim maliyetinizdir (TL/saat). Zamanı hesaba katmak istemiyorsanız R’yi 0 yapabilirsiniz; formül sadece nakit maliyet karşılaştırmasına indirgenir.

Değişken Tanımları

Üç ücret modelini birleştirmek için iş yükünü “oturum(session)” ve “yineleme(iteration)” olmak üzere iki katmana ayırıyoruz. Yeni projeye girişteki tarama ve indeksleme bir kezlik işlemdir; aynı bağlam içindeki sürekli sohbet ve kod değişiklikleri tekrarlanabilir işlemlerdir.

Değişkenler:

$S_i$: Araç $i$‘nin sabit ücreti (abonelik veya aylık asgari tüketim)
$N_s$: Dönem içindeki yeni oturum sayısı (proje değiştirme, bağlam temizleme, yeni oturum)
$N_{it}$: Dönem içindeki etkili yineleme sayısı (gereksinim netleştirme, kod değişikliği, hata düzeltme vb.)
$R$: Zaman birim maliyeti (TL/saat)
$h0_i$: Her yeni oturumun soğuk başlama süresi (saat)
$h1_i$: Her yineleme başına ortalama süre (saat)
$p_{\mathrm{fail},i}$: Her yinelemede yeniden çalışma gereken hata olasılığı (0 ile 1 arası)
$h_{\mathrm{re},i}$: Tek bir yeniden çalışma için ortalama süre (saat)

Buna göre zaman ve risk terimleri:

$$ \begin{aligned} \mathrm{Hours}i &= N_s \cdot h0_i + N{it} \cdot h1_i \ \mathrm{ReworkHours}i &= N{it} \cdot p_{\mathrm{fail},i} \cdot h_{\mathrm{re},i} \end{aligned} $$

Şimdi sadece üç ücret modeli için $Cash_i$‘yi yazmamız gerekir.

Token Ücretlendirmesindeki Nakit Maliyet

Token bazlı ücretlendirme araçları genellikle üç seviyeye ayrılır: giriş, önbelleğe alınmış giriş, çıkış. Yaygın bir hata, aynı giriş token’larını giriş ve önbellek terimlerine birden eklemektir. Öneri: önce toplam giriş token miktarını tahmin edin, ardından önbellek hit oranına göre ayırın.

Değişkenler:

$Tin0_i$: Her yeni oturum için giriş token toplamı
$r0_i \in [0,1]$: Yeni oturum giriş önbelleği hit oranı
$Tin1_i$: Her yineleme için giriş token toplamı
$r1_i \in [0,1]$: Yineleme giriş önbelleği hit oranı
$Tout0_i, Tout1_i$: Çıkış token miktarı
$Pin_i, Pcache_i, Pout_i$: Fiyat parametreleri (TL/milyon token)

Önbellek ücretlendirmesini desteklemeyen araçlar için $r0_i=r1_i=0$ ya da $Pcache_i=Pin_i$ alınabilir.

O zaman:

$$ \begin{aligned} \mathrm{Cash}^{(\mathrm{token})}i &= S_i + \frac{1}{10^6}\Bigl[ N_s \cdot \bigl(Pin_i \cdot (1-r0_i)\cdot Tin0_i + Pcache_i \cdot r0_i\cdot Tin0_i + Pout_i \cdot Tout0_i\bigr) \ &\qquad + N{it} \cdot \bigl(Pin_i \cdot (1-r1_i)\cdot Tin1_i + Pcache_i \cdot r1_i\cdot Tin1_i + Pout_i \cdot Tout1_i\bigr) \Bigr] \end{aligned} $$

Bu formül, “aynı oturumda derinleşip sürekli çalışmak, $N_{it}$ artarken $Tin0_i$ bir kez ödenir, yineleme başına ortalama maliyet düşer” şeklindeki deneyimsel sonucu doğrudan açıklar. Sık proje değiştirme veya sık bağlam temizleme $Tin0_i$‘nin tekrar ödenmesine yol açar.

API Çağrı Ücretlendirmesindeki Nakit Maliyet

API çağrı ücretlendirmesinde “bir çağrı” sohbet, araç çağırma, dosya okuma, arama, komut yürütme vb. operasyonları kapsar. Tahmin gerekir:

$A0_i$: Her yeni oturum için API çağırı sayısı
$A1_i$: Her yineleme için API çağırı sayısı
$Ccall_i$: Her çağırı için birim fiyat (TL/çağrı)

Nakit maliyet formülü:

$$ \mathrm{Cash}^{(\mathrm{call})}i = S_i + Ccall_i \cdot (N_s \cdot A0_i + N{it} \cdot A1_i) $$

Araç ücretsiz kota Q (çağrı/period) sunuyor ve limit aşımında ücret yerine bekleme varsa, bekleme süresini zaman maliyetine ekleyin, aşım çağırılarını $Hours_i$‘ye çevirin ve yine $Total_i$ ile karşılaştırma yapın.

Prompt Ücretlendirmesindeki Nakit Maliyet

Prompt bazlı ücretlendirme bir “prompt"u bir görev gönderimiyle eşdeğer sayar. Tahmin gerekir:

$P0_i$: Her yeni oturum için prompt sayısı
$P1_i$: Her yineleme için prompt sayısı
$Cprompt_i$: Her prompt için birim fiyat (TL/prompt)

Nakit maliyet formülü:

$$ \mathrm{Cash}^{(\mathrm{prompt})}i = S_i + Cprompt_i \cdot (N_s \cdot P0_i + N{it} \cdot P1_i) $$

“Ayda N prompt” paketleri için gölge fiyatı (shadow price) yaklaşımı kullanılabilir: Dönem abonelik ücreti $S_i$, kota $Q_i$ ise $Cprompt_i \approx S_i / Q_i$. Katı marjinal nakit maliyeti olmasa da “kota kıtlığı"nı hesaplanabilir fırsat maliyetine dönüştürür.

Kritik Nokta: İki Araç Arasındaki Sınır Formülü

Yukarıdaki ifadeleri tek bir formda toplayalım. Araç i için:

$$ \mathrm{Total}_i = S_i

N_s \cdot (c0_i + R \cdot h0_i)
N_{it} \cdot (c1_i + R \cdot h1_i + R \cdot p_{\mathrm{fail},i} \cdot h_{\mathrm{re},i}) $$

Burada $c0_i$, $c1_i$ sırasıyla soğuk başlama ve tek yineleme için nakit maliyetleridir ve üç ücret modelindeki farklı açılımları temsil eder.

Verilen iki araç A ve B için $N_s$ sabitken $Total_A = Total_B$ eşitliği çözülürse yineleme sayısındaki kritik nokta bulunur:

$$ N_{it}^{\ast}

\frac{ (S_B - S_A) + N_s \cdot \bigl((c0_B - c0_A) + R \cdot (h0_B - h0_A)\bigr) }{ (c1_A - c1_B) + R \cdot (h1_A - h1_B)

R \cdot \bigl(p_{\mathrm{fail},A} \cdot h_{\mathrm{re},A} - p_{\mathrm{fail},B} \cdot h_{\mathrm{re},B}\bigr) } $$

Açıklama:

Payda pozitifken, $N_{it} > N_{it}^{\ast}$ ise A daha uygun, $N_{it} < N_{it}^{\ast}$ ise B daha uygun olur. Payda negatifse eşitsizlik yönü tersine döner. Payda sıfıra yaklaştığında, iki araç arasındaki marjinal yineleme maliyeti neredeyse aynıdır; tercih sabit ücret ve soğuk başlama maliyetine dayanır.

Bu formülü kullanarak token vs prompt, token vs API çağrı, API çağrı vs prompt arasındaki kritik noktaları hesaplayabilirsiniz. Sadece $c0, c1$‘yi token, çağrı sayısı ya da prompt sayısı olarak ilgili açılımlara göre yazmanız yeterlidir.

Pratik Strateji: Maliyeti Düşürme Yöntemleri

1. Derin Çalışma: Token Ücretlendirmesinde Optimizasyon

Token bazlı ücretlendirme araçları (ör. Codex Cli) için temel strateji çalışma bağlamını sabit tutmak.

Prensip: $Tin0_i$‘nin tekrar ödenmesini önlemek. Aynı projede sürekli çalışmak, ilk bağlam yükleme maliyetini dağıtır; aynı zamanda önbellek hit oranı artışı yanıt hızını önemli ölçüde yükseltir.

Uygulama: Sık proje değiştirme ya da bağlam temizleme yapmaktan kaçının. Tek bir hatayı onarım sonrası projeyi kapatmayı planlıyorsanız, öncelikli dosya okuma maliyeti tam olarak amorti edilemez.

2. Gereksinimleri Birleştirme: API Çağrı Ücretlendirmesinde Optimizasyon

API çağrı bazlı ücretlendirme araçları (ör. Gemini Code Assistant) için temel strateji “bağlam kurma” için harcanan çağrı sayısını en üst seviyeye çıkarmak.

Prensip: $A0_i$ maliyetini dağıtmak. Araç çağırma, dosya okuma vb. tüm operasyonlar çağrı sayısına eklenir.

Uygulama: Tek oturumda birden fazla ilgili gereksinimi topluca ele alın, öncelikli dosya okuma vb. operasyonların değer yoğunluğunu yükseltin. Küçük bir görev tamamlandıktan sonra anında bağlantıyı kesmeyin.

3. Büyük Görevler: Prompt Ücretlendirmesinde Optimizasyon

Prompt bazlı ücretlendirme araçları (ör. Cursor eski sürüm) büyük görevler veya soğuk başlama bakımı için uygundur.

Prensip: Marjinal maliyeti sabitlemek. Bağlam ne kadar uzun olursa olsun, tek prompt ücreti sabittir.

Uygulama: “Büyük görev” derken çok fazla token tüketen (çok sayıda dosya okuma, çok uzun bağlam) ama çıktı sınırlı olan ya da yüksek kaliteli model kontrolü gerektiren görevler kastedilir. Böyle görevlerde prompt bazlı ücretlendirme en yüksek maliyet etkinliğini sunar. Küçük görevlerde prompt bazlı ücretlendirme maliyet etkinliği düşük olur.

Hesaplanabilir Bir Seçim Süreci

Aşağıdaki akış şeması, değişkenleri seçim mantığına haritalar. $N_s$ ve $N_{it}$ değerlerini tahmin ettikten sonra kritik nokta formülü ile karşılaştırma yaparak en uygun seçeneği belirleyebilirsiniz.

flowchart TD
    A[İş yükü tanımını yap] --> B[N_s: Yeni oturum sayısını tahmin et]
    B --> C[N_it: Oturum başı yineleme sayısını tahmin et]
    C --> D[Her araç için c0, c1 tahmin et]
    D --> E[N_it* formülüne değerleri koy]
    E --> F{Ana iş yükü profili?}
    F -->|N_s büyük, N_it küçük| G[Öncelik: prompt veya çağrı bazlı]
    F -->|N_s küçük, N_it büyük| H[Öncelik: token bazlı]
    F -->|Her ikisi de büyük| I[İş akışını böl: Soğuk başlama için prompt/çağrı, derin aşamada token]

    classDef in fill:#2c3e50,stroke:#ecf0f1,stroke-width:2px,color:#ecf0f1
    classDef calc fill:#3498db,stroke:#2980b9,stroke-width:2px,color:#fff
    classDef decide fill:#f39c12,stroke:#d35400,stroke-width:2px,color:#fff
    classDef out fill:#27ae60,stroke:#229954,stroke-width:2px,color:#fff

    class A,B,C in
    class D,E calc
    class F decide
    class G,H,I out