OpenAI API Harcamalarını Özellik Bazlı Takip Etme: Maliyet Atfetme Rehberi

OpenAI faturanız geçen ay 4.237 dolar harcadığınızı gösterir. Ama bunun 3.100 dolarının kontrolden çıkmış tek bir özetleme uç noktasından, 700 dolarının size ayda 50 dolar ödeyen bir müşteriden, 437 dolarının ise kimsenin kullanmadığı bir özellikten geldiğini söylemez. Kontrol paneli, fiyatlandırma, kapasite ve yol haritası kararları için ihtiyacınız olan ilişkilendirmeyi gizler.

Apidog'u bugün deneyin

Bu rehber, OpenAI API maliyet ilişkilendirmesini uygulama düzeyinde nasıl kuracağınızı gösterir: her isteği meta verilerle etiketleme, özellik/rota/müşteri bazında harcama toplama, anahtar bazlı bütçe sınırları koyma, uyarı üretme ve sarıcıyı üretime almadan önce Apidog ile doğrulama. LLM özellikleri gönderiyorsanız, yapay zekayı kontrolsüz bir giderden yönetilebilir bir ürün maliyetine dönüştüren katman budur.

💡 Apidog, maliyet izleme sarıcınızın üretime geçmeden önce doğru çalıştığını doğrulamak için istek düzeyinde görünürlük ve senaryo testi sağlar. Etiketlenmiş istekleri yeniden oynatmak, günlük yapısını doğrulamak ve her çağrının beklenen meta verileri taşıdığını kontrol etmek için kullanabilirsiniz.

TL;DR

Her OpenAI API çağrısını yapılandırılmış meta verilerle etiketleyin:

• feature
• route
• customer_id
• environment
• model

Ardından her istek için token sayıları, gecikme, hata kodu ve hesaplanan maliyeti içeren tek satırlık JSON log üretin. Bu olayları BigQuery, ClickHouse, Snowflake veya Postgres gibi bir depoya gönderin. OpenAI kontrol panelinde anahtar başına bütçe sınırları belirleyin, kendi deponuzdan saatlik anomali uyarıları üretin ve sarıcıyı Apidog senaryolarıyla uçtan uca test edin.

Giriş

Salı günü yeni bir yapay zeka özelliği yayınlıyorsunuz. Cuma sabahı CFO, OpenAI kaleminin neden %40 arttığını soruyor. OpenAI panelini açıyorsunuz. Toplam harcama artmış görünüyor. Ama hangi özellik, müşteri veya rota buna neden olmuş görünmüyor.

Üretimde LLM kullanan ekiplerin çoğu aynı boşlukla karşılaşır. OpenAI’nin faturalandırma arayüzü mühendislik ilişkilendirmesi için değil, finansal mutabakat için tasarlanmıştır. Günlük toplamları ve model dökümlerini görürsünüz; fakat isteği tetikleyen müşteri, ürün yüzeyi veya arka plan işi görünmez.

Çözüm uygulama tarafındadır:

1. OpenAI istemcisini tek bir sarıcı fonksiyondan geçirin.
2. Her çağrıda zorunlu meta veri isteyin.
3. response.usage üzerinden tokenları okuyun.
4. Maliyeti yazma anında hesaplayın.
5. Olayı yapılandırılmış log olarak yayınlayın.
6. Depoda özellik, rota ve müşteri bazında toplayın.
7. Uyarı ve bütçe sınırlarını bu verinin üzerine kurun.

Fiyatlandırma matematiği için GPT-5.5 fiyatlandırma dökümüne bakın. Benzer bir kullanım/faturalandırma problemi için API ekipleri için GitHub Copilot kullanım faturalandırmasına bakabilirsiniz. OpenAI API temel referansı için resmi OpenAI API referansı kullanılabilir.

Neden OpenAI’nin faturalandırma paneli yeterli değil?

OpenAI paneli şunları gösterir:

• Günlük toplam harcama
• Model bazlı kullanım
• Organizasyon/proje limitleri

Tek uygulama, tek müşteri ve tek özellik için bu yeterli olabilir. Ancak birden fazla özellik, müşteri, ortam veya geliştirici varsa panel ürün kararları için yetersiz kalır.

Eksik kalan noktalar:

1. Toplam harcama bağlamsızdır

Panel dün GPT-5.5 için 312 dolar harcadığınızı gösterebilir. Ama bunun:

• destek sohbeti uç noktasını 50.000 kez çağıran bir müşteriden mi,
• yanlışlıkla tüm bilgi tabanını yeniden özetleyen bir cron job’dan mı,
• staging ortamındaki testlerden mi

geldiğini göstermez.

2. Özellik bazlı döküm yoktur

OpenAI istekleri model ve anahtar düzeyinde takip eder. Ancak şu boyutları bilmez:

• feature
• route
• customer_id
• environment
• background_job

Bunları istiyorsanız uygulama tarafında üretmeniz gerekir.

3. Raporlama gecikmelidir

OpenAI kullanım verileri dakikalar veya saatler gecikmeli görünebilir. Kontrolden çıkmış bir döngüyü panelde gördüğünüzde maliyet çoktan oluşmuş olabilir. Gerçek zamanlı uyarılar için kendi olay akışınıza ihtiyacınız vardır.

4. Uyarılar sınırlıdır

OpenAI organizasyon/proje düzeyinde bütçe sınırları sağlayabilir. Ancak şunları yerel olarak vermez:

• özellik başına eşik,
• rota başına eşik,
• müşteri başına kota,
• saatlik anomali tespiti,
• “support-chat son 1 saatte 50 doları geçti” uyarısı.

5. Müşteri ilişkilendirmesi yoktur

B2B SaaS ürünlerinde müşteri başına LLM maliyeti doğrudan brüt kâr marjını etkiler. “Müşteri X bu ay bana kaç dolara mal oldu?” sorusu OpenAI panelinden yanıtlanamaz.

6. Proje anahtarları yardımcıdır ama yeterli değildir

OpenAI proje anahtarları kullanımı proje bazında ayırmanıza yardım eder. Bu iyi bir başlangıçtır. Ancak özellik, müşteri veya rota bazında ilişkilendirme sağlamaz. OpenAI kullanım API’si de istek başına değil, proje bazında toplu veri döndürür.

Bu nedenle yerel panel finans sorusunu yanıtlar; sizin ürün sorusunu yanıtlamanız gerekir. Dev.to üzerindeki “OpenAI Ne Harcadığınızı Söyler. Nereye Harcadığınızı Değil. Bu Yüzden Bir Kontrol Paneli Oluşturdum” tartışmasının yayılmasının nedeni de budur: ölçemediğiniz maliyeti yönetemezsiniz.

Maliyet ilişkilendirme veri modeli

Temel karar şu: her OpenAI çağrısı, deponuza yazılan etiketli bir olay üretmelidir. Bu olay analiz biriminiz olur.

Minimum şema:

Sütun	Tip	Örnek	Neden önemli
request_id	uuid	7a91...	Tekilleştirme, yeniden deneme takibi
timestamp	timestamptz	2026-05-06T14:23:01Z	Zaman serisi ve anomali sorguları
feature	text	support-chat	Çağrıyı tetikleyen ürün yüzeyi
route	text	/api/v1/chat/answer	HTTP rotası veya arka plan işi kimliği
customer_id	text	cust_4291	Müşteri başına maliyet
environment	text	prod, staging, dev	Dev/staging maliyetini prod’dan ayırma
model	text	gpt-5.5, gpt-5.4-mini	Fiyatlandırma modele göre değişir
prompt_tokens	int	15234	Giriş token sayısı
completion_tokens	int	812	Çıkış token sayısı
reasoning_tokens	int	4500	Akıl yürütme tokenları çıktı gibi faturalandırılır
cached_tokens	int	12000	Önbelleğe alınmış giriş tokenları
latency_ms	int	2341	Maliyet/performans korelasyonu
cost_usd	numeric(10,6)	0.045672	Yazma anında hesaplanan maliyet
prompt_cache_key	text	system-v3	Önbellek isabet oranı takibi
error_code	text	null, 429	Hata ve yeniden deneme analizi

Maliyeti sorgu zamanında değil, yazma zamanında hesaplayın. Fiyatlar değişebilir; geçmiş olayın gerçekleştiği gün kullanılan oranı saklamak istersiniz.

Örnek maliyet hesaplama:

PRICING = {  # USD per 1M tokens, as of May 2026
    "gpt-5.5":      {"input": 5.00,  "cached": 2.50,  "output": 30.00},
    "gpt-5.5-pro":  {"input": 30.00, "cached": 15.00, "output": 180.00},
    "gpt-5.4":      {"input": 2.50,  "cached": 1.25,  "output": 15.00},
    "gpt-5.4-mini": {"input": 0.25,  "cached": 0.125, "output": 2.00},
}

def compute_cost_usd(
    model,
    prompt_tokens,
    cached_tokens,
    completion_tokens,
    reasoning_tokens
):
    rates = PRICING[model]

    uncached = max(0, prompt_tokens - cached_tokens)

    input_cost = (uncached * rates["input"]) / 1_000_000
    cache_cost = (cached_tokens * rates["cached"]) / 1_000_000
    output_cost = (
        (completion_tokens + reasoning_tokens) * rates["output"]
    ) / 1_000_000

    return round(input_cost + cache_cost + output_cost, 6)

Akıl yürütme tokenları çıktı olarak sayılır. OpenAI API bunları usage.completion_tokens_details.reasoning_tokens altında döndürür. Bunları giriş tokenı gibi hesaplarsanız maliyeti eksik yazarsınız. Ayrıntılar için GPT-5.5 fiyatlandırma dökümüne bakın.

OpenAI istemcisini sarın

Uygulamadaki tüm OpenAI çağrıları tek bir fonksiyondan geçmelidir. Bu fonksiyon:

1. Zorunlu meta verileri alır.
2. OpenAI çağrısını yapar.
3. response.usage alanını okur.
4. Maliyeti hesaplar.
5. Yapılandırılmış log üretir.

import time
import uuid
import json
import logging
from openai import OpenAI

client = OpenAI()
logger = logging.getLogger("llm.cost")

def call_with_attribution(
    *,
    feature,
    route,
    customer_id,
    environment,
    model,
    messages,
    **openai_kwargs
):
    request_id = str(uuid.uuid4())
    started = time.time()
    error_code = None
    response = None

    try:
        response = client.chat.completions.create(
            model=model,
            messages=messages,
            **openai_kwargs
        )
    except Exception as e:
        error_code = getattr(e, "code", "unknown_error")
        raise
    finally:
        latency_ms = int((time.time() - started) * 1000)

        u = response.usage if response else None

        prompt_tokens = getattr(u, "prompt_tokens", 0)
        completion_tokens = getattr(u, "completion_tokens", 0)

        cached_tokens = (
            getattr(
                getattr(u, "prompt_tokens_details", None),
                "cached_tokens",
                0
            )
            or 0
        )

        reasoning_tokens = (
            getattr(
                getattr(u, "completion_tokens_details", None),
                "reasoning_tokens",
                0
            )
            or 0
        )

        cost_usd = compute_cost_usd(
            model,
            prompt_tokens,
            cached_tokens,
            completion_tokens,
            reasoning_tokens
        )

        logger.info(json.dumps({
            "event": "openai.request",
            "request_id": request_id,
            "feature": feature,
            "route": route,
            "customer_id": customer_id,
            "environment": environment,
            "model": model,
            "prompt_tokens": prompt_tokens,
            "completion_tokens": completion_tokens,
            "reasoning_tokens": reasoning_tokens,
            "cached_tokens": cached_tokens,
            "latency_ms": latency_ms,
            "cost_usd": cost_usd,
            "error_code": error_code,
        }))

    return response

Bu sarıcı maliyet ilişkilendirme sınırınızdır. Üründeki her özellik doğrudan SDK’yı değil bu fonksiyonu çağırmalıdır.

Logları mevcut hattınıza gönderin:

• Vector
• Fluent Bit
• Logstash
• OTLP collector
• Kafka / Pub/Sub / NATS
• BigQuery
• ClickHouse
• Snowflake
• Postgres

Ayrı bir servis zorunlu değildir. Tek satırlık JSON olayları çoğu mevcut gözlemlenebilirlik hattına eklenebilir.

Node.js tarafında yapı aynıdır: OpenAI SDK çağrısını saran bir fonksiyon yazın, meta verileri zorunlu alın, response.usage değerlerini okuyun, maliyeti hesaplayın ve JSON olay yayınlayın.

Maliyet takibini kurun ve Apidog ile test edin

1. Doğrudan OpenAI çağrılarını sarıcıyla değiştirin

Kod tabanında şunları arayın:

OpenAI(
client.chat.completions.create

Her doğrudan çağrıyı call_with_attribution(...) ile değiştirin.

feature ve route zorunlu olmalıdır. Bunları global değişkenden değil, çağrı yerinden verin:

response = call_with_attribution(
    feature="support-chat",
    route="/api/v1/chat/answer",
    customer_id=current_user.customer_id,
    environment="prod",
    model="gpt-5.5",
    messages=messages,
)

Eksik meta veri geldiğinde "unknown" yazmak yerine hata verin. Sessiz varsayılanlar ilişkilendirme verisini kirletir.

2. Yapılandırılmış log yayınlayın

Her istek için tek satır JSON üretin. Logger seviyesini INFO yapın ve bu olayları debug log gürültüsünden ayırın.

Örnek olay:

{
  "event": "openai.request",
  "request_id": "7a91...",
  "feature": "support-chat",
  "route": "/api/v1/chat/answer",
  "customer_id": "cust_4291",
  "environment": "prod",
  "model": "gpt-5.5",
  "prompt_tokens": 15234,
  "completion_tokens": 812,
  "reasoning_tokens": 4500,
  "cached_tokens": 12000,
  "latency_ms": 2341,
  "cost_usd": 0.045672,
  "error_code": null
}

3. Depoda özellik bazlı toplama yapın

Olaylar deponuza düştüğünde ilk sorgu şu olmalıdır:

SELECT
  feature,
  DATE_TRUNC(timestamp, DAY) AS day,
  COUNT(*) AS requests,
  SUM(cost_usd) AS spend_usd,
  SUM(prompt_tokens + completion_tokens) AS tokens,
  AVG(latency_ms) AS avg_latency_ms,
  SUM(cached_tokens) / NULLIF(SUM(prompt_tokens), 0) AS cache_hit_rate
FROM openai_events
WHERE environment = 'prod'
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY feature, day
ORDER BY day DESC, spend_usd DESC;

4. Operasyon panosu oluşturun

Grafana, Metabase, Looker veya Superset ile üç temel görünüm kurun:

1. Zaman içinde özellik başına harcama
2. Zaman içinde müşteri başına harcama
3. Dünkü harcamaya göre en pahalı 20 rota

Bu pano, OpenAI fatura panelinin ürün odaklı karşılığı olur.

5. Sarıcıyı Apidog ile doğrulayın

Sarıcınız yanlış etiket yazarsa tüm pano yanlış olur. Bu yüzden üretime almadan önce uçtan uca test edin.

Apidog ile şu senaryoyu kurun:

• Bilinen bir customer_id ve feature ile yapay zeka uç noktanıza istek gönderin.
• Yanıtı ve log çıktısını yakalayın.
• Log payload’ında şu alanları doğrulayın:
  • feature
  • route
  • customer_id
  • environment
  • model
  • prompt_tokens > 0
  • cost_usd > 0
• Apidog environment değişkenleriyle aynı senaryoyu staging ve prod ortamlarında çalıştırın.
• Aynı isteği yeniden oynatın ve retry edilen çağrıların iki kez maliyet yazmadığını doğrulayın.

Bu doğrulama yaklaşımını daha geniş API test süreçlerine bağlamak için QA mühendisleri için API test araçlarına ve sözleşme odaklı API geliştirmeye bakabilirsiniz.

6. Anahtar başına bütçe sınırı ve uyarı ekleyin

Ortam veya özellik başına ayrı OpenAI proje anahtarı kullanın:

• prod-support-chat
• prod-summarization
• staging-all
• dev-all

OpenAI panelinde bu anahtarlar için sert limitler belirleyin. Böylece tek bir hatalı özellik tüm organizasyon bütçesini tüketmez.

Bunun üstüne depo tabanlı uyarı koyun. Örneğin her 10 dakikada bir çalışan bir sorgu:

• son 1 saatlik harcamayı hesaplar,
• 7 günlük hareketli ortalama ile karşılaştırır,
• 3x artış varsa Slack, PagerDuty veya Opsgenie uyarısı gönderir.

Yerel OpenAI limitleri felaket senaryosunu durdurur. Depo tabanlı uyarılar ise yavaş maliyet kaymasını erken yakalar.

Gelişmiş teknikler

İstem önbellekleme

GPT-5.5, önbelleğe alınmış tokenlar için giriş oranının %50’sini alır. Sistem isteminizi sabit bir önek olarak tutun ve istek bazlı değişkenleri sona koyun.

Takip etmeniz gereken metrik:

cache_hit_rate = SUM(cached_tokens) / SUM(prompt_tokens)

Özellik bazında bu oranı izleyin. Bir prompt değişikliği cache hit oranını düşürürse giriş maliyetiniz sessizce artabilir. Kurallar için resmi OpenAI istem önbellekleme belgelerine bakın.

Çevrimdışı işler için Batch API

Senkron yanıt gerektirmeyen işler Batch API’ye taşınabilir:

• gece özetleme,
• değerlendirme çalıştırmaları,
• embedding doldurma,
• belge yeniden işleme.

Aynı sarıcı mantığını kullanın; olayları batch_job_id ile etiketleyin.

Akıl yürütme çabasını ayarlayın

GPT-5.5 Thinking modunda reasoning.effort arttıkça çıktı tokenları artar. Her özellik için şu soruyu sorun:

medium yerine low kalite eşiğini karşılıyor mu?

A/B testi çalıştırın, kalite ve maliyeti birlikte ölçün. Ayrıntılar için GPT-5.5 API nasıl kullanılır yazısına bakın.

Bağlam penceresini kontrol edin

Uzun prompt pahalıdır. RAG kullanıyorsanız tüm bilgi tabanını bağlama koymak yerine sıkı bir retrieval bütçesi belirleyin.

Takip edin:

AVG(prompt_tokens) BY feature

Bir özellik değişmeden prompt tokenları hafta hafta artıyorsa prompt şişiyor olabilir.

GPT-5.5 272K-token eşiğine dikkat edin

OpenAI, 272K token üzerindeki isteklerde ek çarpanlar uygulayabilir. Sarıcıya bir koruma ekleyin:

if prompt_tokens > 250_000:
    logger.warning(json.dumps({
        "event": "openai.large_prompt_warning",
        "request_id": request_id,
        "feature": feature,
        "route": route,
        "customer_id": customer_id,
        "prompt_tokens": prompt_tokens,
    }))

Fiyatlandırma ayrıntıları için GPT-5.5 fiyatlandırma gönderisine bakın.

Müşteri başına harcama sınırı koyun

B2B SaaS ürünlerinde müşteri başına LLM kotası uygulayın:

1. Depodan customer_id başına aylık harcamayı hesaplayın.
2. Her LLM çağrısından önce bu değeri kontrol edin.
3. Limit aşıldıysa 429 döndürün.
4. Yanıta faturalandırma/upgrade CTA’sı ekleyin.

Örnek:

if monthly_llm_spend(customer_id) >= customer_monthly_limit(customer_id):
    raise HTTPException(
        status_code=429,
        detail="Aylık yapay zeka kotanız aşıldı."
    )

Kaçınılması gereken hatalar

• Akıl yürütme tokenlarını giriş tokenı gibi faturalandırmak.
• Gerçek zamanlı kararlar için OpenAI paneline güvenmek.
• Etiketleri çağrı yerinde değil SDK düzeyinde tahmin etmeye çalışmak.
• Cron job, queue worker ve webhook çağrılarını etiketsiz bırakmak.
• Log örneklemesi yapmak.
• customer_id alanını null bırakmak.
• Retry edilen başarılı çağrılarda yeni request_id üretmek.
• Maliyeti sorgu zamanında hesaplamak.
• Dev/staging çağrılarını prod maliyetine karıştırmak.

Arka plan işleri için sentetik rota kullanın:

cron:nightly-summarize
queue:image-caption
webhook:document-ingested

customer_id bilinmiyorsa internal veya system yazın; null bırakmayın.

Alternatifler ve araçlar

Yaklaşım	İyi yaptığı şeyler	Maliyet	Ne zaman kullanılır
OpenAI kullanım API’si	Yerel, kurulum yok, fatura ile uyumlu	Ücretsiz	Tek proje, tek özellik, müşteri ilişkilendirmesi yok
Helicone	Proxy, pano, önbellekleme, kullanıcı başına maliyet	Ücretsiz katman; ücretli planlar	Hızlı barındırılan pano istiyorsanız
Langfuse	Açık kaynak, trace + maliyet, self-host veya bulut	Self-host ücretsiz; bulut ücretli	Trace ve maliyeti aynı araçta istiyorsanız
LangSmith	LangChain entegrasyonu, evaluation + maliyet	Ücretli	Zaten LangChain kullanıyorsanız
Özel depo	Tam kontrol, mevcut yığına uyum, proxy yok	Mühendislik zamanı	Büyük iş yükü, özel boyutlar, veri yerleşimi gereksinimi

Takaslar:

• Proxy tabanlı araçlar kritik yola ek hop koyar.
• Self-host araçlar kontrol sağlar ama operasyon yükü getirir.
• Özel depo en esnek yaklaşımdır fakat sorgu, uyarı ve pano sorumluluğu sizdedir.
• OpenAI kullanım API’si basit senaryolarda yeterlidir; müşteri/özellik ilişkilendirmesi gerektiğinde yetmez.

Daha fazla okuma için Helicone ekibinin LLM maliyetlerini izleme rehberi ve Langfuse maliyet takibi belgeleri faydalıdır.

Bu modeli platform ölçeğinde işletiyorsanız, maliyet ilişkilendirme sarıcılarının servis mimarilerine nasıl oturduğunu görmek için mikro hizmet mimarileri için API platformlarına bakabilirsiniz.

Gerçek dünya kullanım senaryoları

Müşteri başına LLM harcaması olan B2B SaaS

Bir satış zekası ürünü her müşteri özeti için GPT-5.5 çağırıyor. İlişkilendirme olmadan ekip yalnızca aylık 80.000 dolar OpenAI harcaması olduğunu biliyor.

Müşteri bazlı ilişkilendirme sonrası şunu görüyor:

• müşterilerin %12’si harcamanın %71’ini oluşturuyor,
• düşük paketlerdeki bazı müşteriler yüksek maliyet üretiyor,
• premium müşteriler için kota artırımı mantıklı.

Sonuç:

• katmanlı fiyatlandırma,
• yumuşak kota,
• ek kullanım ücreti,
• daha iyi brüt kâr marjı.

Dahili geliştirici aracı takibi

Bir mühendislik ekibi her geliştiriciye GPT-5.5 tabanlı asistan veriyor. customer_id yerine dev_email etiketi kullanılıyor.

Veri şunu gösteriyor:

• üç geliştirici harcamanın %50’sini oluşturuyor,
• ikisi kapatılmamış otomasyon döngüleri çalıştırıyor,
• biri gerçekten yüksek değerli kullanım yapıyor.

Sonuç:

• hatalı döngüler kapatılıyor,
• gereksiz maliyet düşüyor,
• meşru kullanım için daha yüksek kota veriliyor.

Yeni AI özelliği için maliyet tahmini

Ürün ekibi yeni özetleme özelliği çıkarmak istiyor. Geçmiş ilişkilendirme verisiyle şu model kuruluyor:

aktif kullanıcı başına günlük maliyet =
ortalama çağrı sayısı
× çağrı başına ortalama prompt token
× çağrı başına ortalama output token
× model fiyatı

Tahmin: aktif kullanıcı başına günlük 0,04 dolar, aylık 1,20 dolar.

Ürün aylık 5 dolar ek ücretle paketleniyor. Finans ekibi birim ekonomisini gördüğü için onay verebiliyor.

Sonuç

OpenAI paneli ne kadar harcadığınızı gösterir. Ama nereye harcadığınızı uygulama tarafında ölçmeniz gerekir.

Uygulanabilir özet:

• Her isteği feature, route, customer_id ve environment ile etiketleyin.
• Meta verileri çağrı yerinde zorunlu yapın.
• Maliyeti yazma anında hesaplayın.
• Her istek için tek satır yapılandırılmış JSON log üretin.
• Logları mevcut veri deponuza gönderin.
• OpenAI proje anahtarlarını ortam/özellik bazında ayırın.
• Panelde sert bütçe sınırları koyun.
• Depo üzerinden saatlik anomali uyarıları üretin.
• Sarıcıyı üretime almadan önce Apidog ile test edin.
• Prompt boyutu, akıl yürütme çabası ve cache hit oranını düzenli denetleyin.

Apidog’u indirin ve maliyet ilişkilendirme sarıcınızı uçtan uca doğrulamak için kullanın. Etiketlenmiş isteklerle yapay zeka uç noktalarınızı test edin, log payload yapısını doğrulayın ve senaryoları ortamlar arasında yeniden oynatın.

İlgili maliyet yönetimi okumaları için GPT-5.5 fiyatlandırma dökümüne ve API ekipleri için GitHub Copilot kullanım faturalandırmasına bakın.

SSS

Akıl yürütme tokenları giriş mi, çıktı mı sayılır?

Çıktı olarak faturalandırılır. OpenAI API bunları usage.completion_tokens_details.reasoning_tokens altında döndürür. Maliyeti hesaplarken completion_tokens ile birlikte çıktı oranına ekleyin. Ayrıntılar için GPT-5.5 fiyatlandırma dökümüne bakın.

response.usage, OpenAI paneline göre ne kadar doğru?

Token sayıları panelle uyumlu olmalıdır. Sapma genelde fiyat tablosunun güncel olmamasından kaynaklanır. Model bazlı fiyatları kodda versiyonlayın ve OpenAI fiyat değişikliği yayınladığında güncelleyin.

Yalnızca OpenAI proje anahtarlarıyla ilişkilendirme yapabilir miyim?

Kısmen. Proje anahtarları tek bir boyut sağlar: proje. Özellik, müşteri ve rota ilişkilendirmesi için uygulama düzeyinde meta veri gerekir.

Retry ve rate limit hatalarında maliyet iki kez yazılır mı?

Model çalışmadan önce başarısız olan istek genellikle usage döndürmez, bu yüzden maliyet yazılmaz. Başarılı olup uygulama katmanında tekrar edilen çağrılar, aynı request_id kullanılmazsa iki kez yazılabilir. İdempotent retry için aynı request_id korunmalı ve depo tarafında tekilleştirme yapılmalıdır.

OpenAI kullanım API’si ne kadar hızlı veri döndürür?

Kullanım API’sinde gecikme olabilir. Gerçek zamanlı uyarılar, kapatma anahtarları ve müşteri kotası için kendi deponuzu kullanın. Aylık mutabakat için kullanım API’si uygundur.

Log hacmini azaltmak için örnekleme yapmalı mıyım?

Hayır. Her istek tek satır JSON’dur. Hacim genelde düşüktür, fakat örnekleme müşteri ve rota bazlı ilişkilendirmeyi bozar.

Bu yaklaşım diğer LLM sağlayıcıları için de çalışır mı?

Evet. Şemaya provider alanı ekleyin:

openai
anthropic
google
deepseek

Sarıcı sağlayıcıya özel olur; depo, pano ve uyarılar aynı kalır. Karşılaştırma için DeepSeek V4 API fiyatlandırmasına bakabilirsiniz.

Embedding ve görüntü oluşturma çağrıları için de kullanılabilir mi?

Evet. Şemaya endpoint ekleyin:

chat
embeddings
image

Embedding’ler genellikle giriş tokenı başına, görüntüler ise çözünürlük veya görüntü başına fiyatlandırılır. compute_cost_usd fonksiyonunu endpoint’e göre dallandırın.