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

OpenAI faturanız, geçen ay 4.237 dolar harcadığınızı gösteriyor. Bunun 3.100 dolarının tek bir kontrolden çıkmış özetleme uç noktasından, 700 dolarının size ayda 50 dolar ödeyen bir müşteriden ve 437 dolarının kimsenin kullanmadığı bir özellikten geldiğini söylemiyor. Kontrol paneli, herhangi bir fiyatlandırma, kapasite veya yol haritası kararı vermek için ihtiyacınız olan resmi gizler.

Bu rehber, OpenAI API maliyet ilişkilendirmesini doğru şekilde nasıl yapacağınızı gösteriyor: her isteği meta verilerle etiketleyin, özellik, rota ve müşteri başına harcamaları toplayın, anahtar başına bütçe üst sınırları belirleyin ve maliyetin gizemli bir kalem olmaktan çıkması için istemleri tasarlayın. LLM özelliklerini gönderiyorsanız, yapay zekayı kontrolden çıkmış bir giderden yönetilen bir ürün maliyetine dönüştüren iş budur.

Düğme

TL;DR

Her OpenAI API çağrısını yapılandırılmış meta verilerle (özellik, rota, müşteri_kimliği, ortam) etiketleyin, belirteç sayılarını ve hesaplanan maliyeti yakalayan istek başına yapılandırılmış bir günlük satırı yayınlayın, ardından deponuzda etikete göre toplayın. OpenAI kontrol panelinde anahtar başına bütçe üst sınırları belirleyin, saatlik harcama anormalliklerinde uyarı alın ve sayılarına güvenmeden önce Apidog senaryo testleri ile sarıcıyı uçtan uca doğrulayın.

Giriş

Salı günü yeni bir yapay zeka özelliği yayınlıyorsunuz. Cuma sabahı, CFO'nuz DMs'nizde OpenAI kaleminin neden yüzde 40 arttığını soruyor. Kontrol panelini açıyorsunuz. Toplam harcamanın yükseldiğini gösteriyor. Hangi özelliğin, hangi müşterinin veya hangi rotanın sorumlu olduğunu göstermiyor. Tahmin etmeye başlıyorsunuz.

Üretim LLM iş yüklerini çalıştıran her ekip bu boşlukla karşılaşıyor. OpenAI'nin faturalandırma arayüzü, mühendislik ilişkilendirmesi için değil, borçlar hesabı için oluşturulmuştur. Günlük toplamları, model dökümlerini görüyorsunuz ve hepsi bu. İstek şeklini, onu tetikleyen müşteriyi veya modeli çağıran özelliği görmüyorsunuz.

Çözüm kavramsal olarak basit, ancak uygulamada acımasız. Her API çağrısını bir meta veri katmanıyla sarıyorsunuz. Her isteği yapılandırılmış bir depolama alanına kaydediyorsunuz. Etikete göre topluyorsunuz. Sınırlar belirliyorsunuz. Farklılıklarda uyarı alıyorsunuz. Bu yazının sonunda somut bir veri modeline, iki çalışan kod örneğine, Apidog ile bir doğrulama iş akışına ve bir araç karşılaştırmasına sahip olacaksınız, böylece kendiniz mi oluşturacağınıza, satın mı alacağınıza yoksa doğrudan OpenAI kullanım API'sini mi kullanacağınıza karar verebilirsiniz.

Maliyet matematiğinizi yönlendiren fiyatlandırma bağlamı için, GPT-5.5 fiyatlandırma dökümüne bakın. Geliştirici araçları tarafındaki benzer bir faturalandırma-ilişkilendirme problemi için, API ekipleri için GitHub Copilot kullanım faturalandırmasına bakın. OpenAI API temel bilgileri için, resmi OpenAI API referansına bakın.

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

Hemen OpenAI faturalandırma sayfasını açın. Günlük harcama grafiği, model dökümü ve kullanım limiti göreceksiniz. Tüm arayüz budur. Tek bir uygulamanız, tek bir müşteriniz ve tek bir özelliğiniz varsa sorunsuz çalışır. Aynı üründe birden fazla özellik, birden fazla müşteri, birden fazla ortam veya birden fazla geliştiriciye sahip olduğunuz anda, kontrol paneli kullanışlı olmaktan çıkar.

İşte eksik olanlar.

Bağlamı olmayan toplam harcama. Kontrol paneli, dün GPT-5.5 için 312 dolar harcadığınızı söyler. Bunun, destek sohbeti uç noktanızı 50.000 kez vuran bir müşteriden mi yoksa birinin bir bayrağı açık bırakması nedeniyle tüm bilgi tabanınızı yeniden özetleyen bir arka plan işinden mi geldiğini söylemez. Her ikisi de grafikte aynı görünür.

Özellik başına döküm yok. OpenAI, istekleri API anahtarı ve modele göre etiketler. Ancak bunları özelliğinize, rotanıza, müşteri kimliğinize veya ortamınıza göre etiketlemez. Bunlardan herhangi birini isterseniz, kendiniz oluşturmanız gerekir. Kontrol panelinde ürün analizi için yerel bir boyut yoktur.

Raporlama gecikmesi. Kullanım verileri, on dakika ile birkaç saat arasında değişen bir gecikmeyle görünür. Kontrol panelinizde kontrolden çıkmış bir döngü göründüğünde, zaten bir kredi kartını yakmıştır. Tarihsel bir grafiğe değil, gerçek zamanlı takibe ihtiyacınız var.

Uyarı temel öğeleri yok. OpenAI, kuruluş başına bir bütçe sınırı ve bir yumuşak bildirim e-postası verir. Anahtar başına uyarı, özellik başına eşik, anomali tespiti yoktur. "Sohbet uç noktası bir saat içinde 50 doları aşarsa bana bildirin" istiyorsanız, bunu kendiniz oluşturursunuz.

Müşteri ilişkilendirmesi yok. Bir yapay zeka özelliğiyle B2B SaaS satıyorsanız, hangi müşterinin hangi harcamayı yaptığını bilmeniz gerekir, böylece fiyatlandırma, kısıtlama veya üst satış yapabilirsiniz. Kontrol paneli "müşteri X'in bu ay bana maliyeti nedir" sorusunu yanıtlayamaz. Finans ekibiniz, müşteri başına brüt kar marjını hesaplamak için bu sayıya ihtiyaç duyar. Bu olmadan, birim ekonominiz tahmin yürütmedir.

Hizmet hesapları ve proje düzeyinde anahtarlar yardımcı olur, ancak yalnızca kısmen. OpenAI'nin proje anahtarları, kullanımı projeye göre bölmenizi sağlar. Bu size bir seviye ilişkilendirme sağlar. Ancak özellik başına, müşteri başına veya rota başına ilişkilendirme sağlamaz. Önemli soruları yanıtlamak için hala uygulama düzeyinde meta verilere ihtiyacınız vardır. OpenAI kullanım API'si, istek başına değil, proje başına toplu veriler döndürür.

Örüntü, LLM özelliklerini büyük ölçekte gönderen her ekipte tekrarlanır. Dev.to başlığı "OpenAI Ne Harcadığınızı Söyler. Nereye Harcadığınızı Değil. Bu Yüzden Bir Kontrol Paneli Oluşturdum" viral oldu çünkü sorunu yüksek sesle dile getirdi: ölçemediğiniz şeyi yönetemezsiniz. Yerel kontrol paneli bir finans sorusunu yanıtlar. Bir ürün sorusunu yanıtlamanız gerekir.

Maliyet ilişkilendirme veri modeli

Maliyet ilişkilendirmesi tek bir kararla başlar: her OpenAI isteği deponuza yazılan etiketli bir olay alır. Bu olay sizin analiz biriminizdir. Şemayı doğru ayarlayın ve geri kalan iş, panolar, uyarılar, sınırlar bir SQL sorgusu haline gelir.

İhtiyacınız olan minimum şema budur.

Maliyeti sorgulama zamanında değil, yazma zamanında hesaplayın. Fiyatlandırma değişir; isteğin gerçekleştiği gün ödediğiniz oranı yansıtan donmuş bir sayı istersiniz. GPT-5.5 için hesaplama mantığı şöyledir:

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, ancak çıktı oranında faturalandırılırlar. Bunu kaçırırsanız, her Düşünme modu çağrısında maliyeti eksik sayarsınız. Tam fiyatlandırma matematiği için GPT-5.5 fiyatlandırma dökümüne bakın.

Şimdi OpenAI istemcisini sarın. Her çağrı tek bir fonksiyondan geçer. Bu fonksiyon meta verileri alır, isteği yapar ve olayı yazar.

import time, uuid, json, 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 tek sarıcı, maliyet ilişkilendirme arayüzünüzdür. Ürününüzdeki her özellik onu çağırır. Yapılandırılmış günlük satırı, deponuzun girdisidir. Buradan, günlükleri mevcut günlük hattınız (Vector, Fluent Bit, Logstash, OTLP toplayıcı) aracılığıyla BigQuery, ClickHouse, Snowflake veya Postgres'e gönderin. İkinci bir hattı yok. Ek bir hizmet yok.

Node.js ekipleri için şekil aynıdır. OpenAI SDK'sını meta verileri alan, response.usage'ı yakalayan, maliyeti hesaplayan ve bir JSON satırı yazan bir fonksiyonda sarmalayın. Platformunuz zaten bir olay veri yolu (Kafka, NATS, Pub/Sub) çalıştırıyorsa, olayı stdout yerine oraya yayınlayın ve alt akış tüketicilerinin onu deponuza ve uyarı sisteminize yaymasını sağlayın.

Maliyet takibini kurun ve Apidog ile test edin

Şemaya ve sarıcıya sahipsiniz. Şimdi bunu işlevsel bir şeye dönüştürün. Altı adım.

1. Doğrudan OpenAI çağrılarını sarıcıyla değiştirin. Kod tabanınızda `OpenAI(` ve `client.chat.completions.create` araması yapın. Her isabet bir `call_with_attribution(...)` çağrısı olur. `feature` ve `route`'u zorunlu argümanlar yapın. Bunları genel bir değişkenden değil, çağrı yerinde iletin. Bunları iletmeyi unutursanız, fonksiyon varsayılan olarak "bilinmeyen" olarak ayarlanmak yerine bir hata vermelidir.

2. Yapılandırılmış günlükler yayınlayın. Her olay için bir satır olarak JSON formatında stdout'a loglayın. Özellikle bu olaylar için logger seviyesini INFO olarak ayarlayın. Bunları hata ayıklama gürültüsüyle karıştırmayın. Halihazırda yapılandırılmış bir logger kullanıyorsanız (structlog, pino, winston), bunu ona bağlayın.

3. Deponuzda özellik başına toplama yapın. Olaylar BigQuery veya ClickHouse'a düştüğünde, sorgular kendiliğinden yazılı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. Rota başına harcamayı çizin. Grafana, Metabase, Looker veya Superset'i tabloya yönlendirin. Üç görünüm oluşturun: zaman içinde özellik başına harcama, zaman içinde müşteri başına harcama ve dünün harcamasına göre sıralanmış ilk 20 rota tablosu. Bu, günlük operasyon panonuzdur.

5. Sarıcıyı göndermeden önce Apidog ile test edin. Bu, çoğu ekibin atladığı ve pişman olduğu adımdır. Sarıcınız yapılandırılmış günlükler yazar. Şema yanlışsa, deponuz sessizce yanlış olur ve panolar yalan söyler. Hizmetinize karşı uçtan uca testler yapmak için Apidog kullanın:

• Apidog'da bilinen bir customer_id ve feature ile yapay zeka uç noktanıza bir istek gönderen bir senaryo oluşturun.
• Yanıtı ve yan kanal günlük yayınını (stdout, OTLP, günlük uç noktanız) yakalayın.
• Günlük yükünün beklenen feature, route, customer_id içerdiğini ve cost_usd > 0 ve prompt_tokens > 0 olduğunu doğrulamak için Apidog'un yanıt onaylarını kullanın.
• Apidog ortam değişkenlerini kullanarak aynı senaryoyu hazırlık ve üretim ortamlarında çalıştırın.
• Etiketlenmiş istekleri yeniden oynatın ve yeniden denenen çağrıların maliyeti iki kez saymadığını doğrulayın (sarıcınız yeniden denemede request_id'yi yeniden kullanmalıdır).

Bu doğrulama adımına uyan daha geniş API test yaklaşımları için, QA mühendisleri için API test araçlarına bakın. Maliyet ilişkilendirme kapsamıyla eşleşen sözleşme odaklı yaklaşım için, sözleşme odaklı API geliştirmeye bakın.

6. Anahtar başına bütçe üst sınırları ve uyarılar belirleyin. OpenAI, ortam veya özellik başına bir proje anahtarı oluşturmanıza olanak tanır. Bunu kullanın. Bir `prod-support-chat` anahtarı, bir `prod-summarization` anahtarı, bir `staging-all` anahtarı oluşturun. OpenAI kontrol panelinde katı sınırlar belirleyin, böylece bir özellikteki kontrolden çıkmış bir döngü tüm kuruluş bütçesini tüketmesin. Kendi uyarı sisteminizi üzerine katmanlayın: her 10 dakikada bir çalışan ve herhangi bir özellik, 7 günlük hareketli ortalama saatlik harcamasının 3 katını aşarsa sizi uyaran bir SQL sorgusu. PagerDuty, Opsgenie veya bir Slack webhook hepsi çalışır; tetikleyici OpenAI'den değil, deponuzdan gelir.

Yerel anahtar sınırlarının ve depo tabanlı uyarıların birleşimi size iki katmanlı bir savunma sağlar. Yerel sınırlar, felaketle sonuçlanan yanmalara karşı bir emniyet kemeridir. Depo uyarıları, üst sınır tetiklenmeden önce yavaş kaymayı yakalar.

Gelişmiş Teknikler ve Uzman İpuçları

Temel boru hattı çalışmaya başladığında optimizasyonlar takip eder.

İstem önbellekleme. GPT-5.5, önbelleğe alınmış token'lar için giriş oranının %50'sini alır. Sistem isteminizi sabit bir önek olarak yapılandırın ve istek başına değişkenleri sona koyun. Bunu yaptıktan sonra sohbet iş yüklerinde %70'in üzerindeki önbellek isabet oranları normaldir. Bir istem değişikliği isabet oranınızı düşürdüğünde bunu görmek için panonuzda özellik başına cache_hit_rate'i takip edin. Resmi OpenAI istem önbellekleme belgeleri uygunluk kurallarını kapsar.

Çevrimdışı işler için Toplu API. Senkron yanıt gerektirmeyen her şey %50 indirimle Toplu API'den geçer. Gece özetleme, değerlendirme çalıştırmaları, embedding doldurmaları, belge yeniden işleme. Maliyet sarıcısı hala geçerlidir; Toplu uç noktayı çağırın ve olayları batch_job_id ile etiketleyin, böylece onları kaynak iş yüküne geri atfedebilirsiniz.

Akıl yürütme çabasını ayarlama. GPT-5.5 Düşünme, daha yüksek reasoning.effort ile aynı modeldir. Her çaba seviyesi çıktı token'larını çarpar. Özelliklerinizi denetleyin: kalite çubuklarını geçeceği low yerine medium mı çalıştırıyorsunuz? Bir A/B testi yapın, kaliteyi ve maliyeti takip edin, kalite aynı kalırsa daha ucuz seçeneği kullanın. Daha derin matematik için GPT-5.5 API nasıl kullanılır konusuna bakın.

Bağlam penceresi disiplini. Uzun istemler pahalıdır. Sıkı bir alma bütçesine sahip RAG, tüm bilgi tabanını bağlam penceresine tıkamaktan daha iyidir. Özellik başına ortalama prompt_tokens'ı takip edin; bir özellik değişikliği olmadan hafta be hafta artıyorsa, isteminiz şişiyor demektir.

GPT-5.5 272K-token eşiğine dikkat edin. OpenAI, 272K token üzerindeki isteklere 2 kat giriş çarpanı ve 1.5 kat çıktı çarpanı uygular. Sarıcınızda, prompt_tokens > 250000 olduğunda bir uyarı kaydeden bir koruma ekleyin, böylece eşiğe yaklaşan istemleri yakalayabilirsiniz. Fiyatlandırma ayrıntıları için GPT-5.5 fiyatlandırma gönderisine bakın.

Müşteri Başına Harcama Sınırları. B2B satış yapıyorsanız ve sözleşmeniz LLM destekli bir özellik içeriyorsa, müşteri başına bir sınıra ihtiyacınız vardır. Deponuzdan customer_id başına yuvarlanan harcamayı hesaplayın ve uygulamanızın her çağrıdan önce bunu kontrol etmesini sağlayın. Sınıra ulaşıldığında, "aylık yapay zeka kotası aşıldı" mesajı ve bir faturalandırma CTA'sı ile 429 döndürün. Bu, yapay zeka özelliklerini marj riskinden marj ürününe dönüştürür.

Kaçınılması gereken yaygın hatalar.

• Akıl yürütme token'larını giriş olarak saymak. Bunlar çıktıdır. Çıktı oranında faturalandırın.
• Gerçek zamanlı kararlar için OpenAI kontrol paneline güvenmek. Gecikme yaşar. Kendi deponuzu kullanın.
• Çağrı sitesi yerine SDK düzeyinde etiketleme. Etiketler istemciye değil, özelliğe aittir.
• Arka plan işlerini etiketlemeyi unutmak. Cron işleri, kuyruk çalışanları ve web kancaları aynı OpenAI çağrılarını yapar; bunları cron:nightly-summarize veya queue:image-caption gibi sentetik bir route ile etiketleyin.
• Örnekleme. Örnekleme yapmayın. Her isteği kaydedin. Veri hacmi önemsizdir; ilişkilendirme doğruluğu değildir.
• customer_id'nin null olmasına izin vermek. Müşteriyi bilmiyorsanız, internal veya system olarak kaydedin, asla null bırakmayın. Null bir ilişkilendirme kara deliği haline gelir.

Alternatifler ve Araçlar

Bunu kendiniz inşa etmek zorunda değilsiniz. İşte dürüst karşılaştırma.

Unutulmaması gereken takaslar. Bir proxy (Helicone) kritik yolunuza bir atlama ekler; gecikme maliyeti küçük ama gerçektir ve onların kullanılabilirliğine bağımlı hale gelirsiniz. Kendi kendine barındırılan bir gözlemlenebilirlik yığını (Langfuse) size tam kontrol sağlar ancak onu siz işletirsiniz. Özel depo yolu, çoğu büyük ekibin sonunda vardığı yerdir; veri yığınlarınızın geri kalanıyla bütünleşir, ancak sorguları ve uyarıları kendiniz yazarsınız. İhtiyaçlarınız basitse yerel kullanım API'si iyidir, değilse işe yaramaz.

İyi LLM maliyet gözlemlenebilirliğinin pratikte nasıl göründüğüne dair daha derinlemesine bir okuma için, Helicone ekibinin LLM maliyetlerini izleme rehberi proxy tabanlı yaklaşımı anlatır. Maliyet takibi üzerine Langfuse belgeleri açık kaynak yolunu kapsar.

Bunu platform ölçeğinde işletiyorsanız, desenler genelleşir. Maliyet ilişkilendirme sarıcılarının bir hizmet ağı stratejisine nasıl uyduğunu görmek için mikro hizmet mimarileri için API platformlarına bakın.

Gerçek Dünya Kullanım Senaryoları

Müşteri Başına LLM Harcaması Olan B2B SaaS. Bir şirket satış zekası ürünü satıyor. Her müşteri, bir özet talep ettiklerinde GPT-5.5 çağrılarını tetikler. İlişkilendirme olmadan, şirket OpenAI'ye ayda 80.000 dolar harcadığını biliyor. Müşteri başına ilişkilendirme ile, müşterilerin %12'sinin harcamanın %71'ini oluşturduğunu öğrenir. Katmanlı fiyatlandırma, en düşük katmanda yumuşak kotalar ve koltuk başına ek kullanım ücreti uygular. Yapay zeka özelliğindeki brüt kar marjı bir çeyrekte %41'den %73'e yükselir.

Dahili geliştirici aracı takibi. Bir mühendislik departmanı, her geliştiriciye özel bir GPT-5.5 sohbet asistanına erişim sağlar. Geliştirici başına etiketlerle (customer_id, dev_email olur), platform mühendisliği, üç geliştiricinin dahili harcamanın %50'sini oluşturduğunu görür. Bunlardan ikisi kapatmayı unuttukları otomatik aracı döngüleri çalıştırıyor. Bunları kapatmak ayda 1.800 dolar tasarruf sağlar. Üçüncüsü meşru işler yapıyor; veriler, onlar için kuruluş çapında daha yüksek bir kotayı haklı çıkarıyor.

Yapay zeka özelliği harcama tahmini. Bir ürün ekibi yeni bir özetleme özelliği yayınlamak istiyor. Ürün yöneticisi maliyeti nasıl tahmin edeceğini bilmiyor. Geçmiş özellik başına verilerle ekip bir model oluşturur: çağrı başına ortalama istem tokenları, ortalama çıktı tokenları, aktif kullanıcı başına beklenen çağrılar, beklenen aktif kullanıcılar. Tahmin geri döner: aktif kullanıcı başına günlük 0,04 dolar veya aylık 1,20 dolar. Fiyatlandırma ekibi özelliği kullanıcı başına aylık 5 dolardan fiyatlandırır. Finans, birim ekonomisi görünür olduğu için onay verir.

Sonuç

Ölçemediğinizi yönetemezsiniz. OpenAI'nin faturalandırma panosu bir finans sorusunu yanıtlar. Özellik başına, müşteri başına, rota başına ilişkilendirme ürün sorusunu yanıtlar. Sarıcıyı oluşturun, olayı kaydedin, depoyu sorgulayın ve yapay zeka hattınız gizemli bir çizgi olmaktan çıksın.

Beş çıkarım:

• Her isteği etiketleyin özellik, rota, müşteri kimliği ve ortam ile. Etiketleri çağrı yerinde zorunlu hale getirin.
• Maliyeti yazma zamanında hesaplayın böylece geçmiş veriler o gün ödediğiniz oranı yansıtır.
• Ortam başına bir proje anahtarı kullanın ve bir güvence olarak OpenAI kontrol panelinde katı sınırlar belirleyin.
• Depo tabanlı uyarıları katmanlayın yerel sınırların üzerine, böylece sınır tetiklenmeden önce yavaş kaymayı yakalarsınız.
• Sarıcıyı göndermeden önce Apidog ile test edin; kötü etiketler, sessiz ilişkilendirme hataları anlamına gelir.
• Akıl yürütme çabasını ve istem boyutunu üç ayda bir denetleyin; en ucuz optimizasyon, kaliteyi sabit tutan optimizasyondur.
• Özellik başına önbellek isabet oranını takip edin böylece bir istem değişikliği giriş maliyetinizi sessizce ikiye katlamaz.

Apidog'u indirin ve maliyet ilişkilendirme sarıcınızın uçtan uca doğrulanmasında kullanın. Etiketlenmiş isteklerle yapay zeka uç noktalarınızı sürün, günlük yükü şeklini doğrulayın ve ortamlar arasında senaryoları yeniden oynatın, böylece deponuzun güvendiği veriler, mühendislerinizin yazdığı veriler olsun.

İ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ı faturalandırma için giriş mi yoksa çıktı olarak mı sayılır?Akıl yürütme tokenları çıktı oranında faturalandırılır. OpenAI API bunları usage.completion_tokens_details.reasoning_tokens altında döndürür. Maliyeti hesaplarken bunları completion_tokens'a ekleyin. Çaba başına çarpanlar için GPT-5.5 fiyatlandırma dökümüne bakın.

response.usage, OpenAI paneline kıyasla ne kadar doğru?response.usage içindeki token sayıları, panelle token bazında eşleşir. Eski bir oran tablosundan maliyeti hesaplarsanız, fiyatlandırma değişiklikleri küçük bir sapmaya neden olabilir; oranı modele sabitleyin ve OpenAI bir fiyat değişikliği yayınladığı gün güncelleyin.

Yalnızca OpenAI proje anahtarlarıyla ilişkilendirme yapabilir miyim?Proje anahtarları size tek bir ilişkilendirme boyutu sağlar: proje başına. Özellik başına, müşteri başına veya rota başına sağlamazlar. Ortam ayrımları ve bütçe sınırları için proje anahtarlarını kullanın; diğer her şey için uygulama düzeyinde meta verileri kullanın.

Yeniden denemeler ve oran sınırlaması hataları ne olacak? Maliyeti iki kez sayar mı?Model çalışmadan önce başarısız olan bir istek (4xx, tamamlama öncesi ağ hatası) bir usage nesnesi döndürmez, bu nedenle hiçbir maliyet kaydedilmez. Başarılı olan ve ardından uygulama katmanında yeniden denenen bir istek, request_id'yi yeniden kullanmadığınız sürece iki kez kaydedilecektir. İdempotent yeniden denemeler aynı request_id'yi geçmelidir ve sarıcınız yazma sırasında tekrarı önlemelidir.

OpenAI kullanım API'si verileri ne kadar hızlı döndürür?Kullanım API'sinde onlarca dakikalık bir gecikme vardır. Gerçek zamanlı kararlar için (uyarılar, kapatma anahtarları) kendi deponuzu kullanın. Aylık mutabakat için kullanım API'si uygundur ve faturalandırma faturanızla eşleşir.

Günlük hacmini azaltmak için istekleri örneklemeli miyim?Hayır. Veri hacmi küçüktür (istek başına bir JSON satırı) ve örnekleme, müşteri başına ve rota başına ilişkilendirmeyi bozar. Her isteği günlüğe kaydedin.

Bu yaklaşımı diğer LLM sağlayıcıları için de kullanabilir miyim?Evet. Şema genelleşir. Bir provider sütunu (openai, anthropic, google, deepseek) ve sağlayıcı başına bir fiyatlandırma tablosu ekleyin. Sarıcı sağlayıcıya özeldir; depo ve panolar değildir. Bir karşılaştırma noktası için DeepSeek V4 API fiyatlandırmasına bakın.

Bu, embedding'ler ve görüntü oluşturma çağrıları için de işe yarar mı?Evet, sağlayıcıya özel maliyet matematiği ile. Embedding'ler düz bir oranla giriş tokenı başına faturalandırılır; görüntüler, çözünürlük başına bir oranla görüntü başına faturalandırılır. Şemaya endpoint (örn. chat, embeddings, image) ekleyin ve maliyet hesaplamanızı buna göre dallandırın.

Düğme