Cara Melacak Pengeluaran API OpenAI per Fitur: Panduan Atribusi Biaya

Faktur OpenAI Anda menunjukkan bahwa Anda menghabiskan $4.237 bulan lalu. Ini tidak memberitahu Anda bahwa $3.100 dari jumlah tersebut berasal dari satu titik akhir ringkasan yang tidak terkendali, $700 dari pelanggan yang membayar Anda $50 per bulan, dan $437 dari fitur yang tidak digunakan siapa pun. Dasbor menyembunyikan gambaran yang Anda butuhkan untuk membuat keputusan harga, kapasitas, atau peta jalan apa pun.

Panduan ini menunjukkan cara melakukan atribusi biaya API OpenAI dengan benar: beri tag setiap permintaan dengan metadata, agregasikan pengeluaran per fitur, rute, dan pelanggan, tetapkan batasan anggaran per kunci, dan rancang prompt agar biaya tidak lagi menjadi item baris yang misterius. Jika Anda mengirimkan fitur LLM, inilah pekerjaan yang mengubah AI dari pengeluaran yang tidak terkendali menjadi biaya produk yang terkelola.

tombol

Ringkasan

Beri tag setiap panggilan API OpenAI dengan metadata terstruktur (fitur, rute, customer_id, lingkungan), keluarkan baris log terstruktur per permintaan yang menangkap jumlah token dan biaya terhitung, lalu agregasikan berdasarkan tag di gudang data Anda. Tetapkan batasan anggaran per kunci di dasbor OpenAI, beri peringatan tentang anomali pengeluaran per jam, dan validasi wrapper secara menyeluruh dengan pengujian skenario Apidog sebelum Anda memercayai angka-angkanya.

Pendahuluan

Anda meluncurkan fitur AI baru pada hari Selasa. Pada Jumat pagi, CFO Anda bertanya di DM mengapa pengeluaran OpenAI melonjak 40 persen. Anda membuka dasbor. Dasbor menunjukkan total pengeluaran yang meningkat. Dasbor tidak menunjukkan fitur mana, pelanggan mana, atau rute mana yang bertanggung jawab. Anda mulai menebak-nebak.

Ini adalah celah yang dihadapi setiap tim yang menjalankan beban kerja LLM produksi. Antarmuka penagihan OpenAI dibuat untuk pembayaran utang, bukan untuk atribusi rekayasa. Anda melihat total harian, rincian model, dan hanya itu. Anda tidak melihat bentuk permintaan, pelanggan yang memicunya, atau fitur yang memanggil model.

Perbaikannya sederhana dalam konsep dan tanpa ampun dalam eksekusi. Anda membungkus setiap panggilan API dengan lapisan metadata. Anda mencatat setiap permintaan ke penyimpanan terstruktur. Anda melakukan agregasi berdasarkan tag. Anda menetapkan batasan. Anda memberi peringatan tentang perbedaan. Di akhir postingan ini, Anda akan memiliki model data konkret, dua contoh kode yang berfungsi, alur kerja verifikasi dengan Apidog, dan perbandingan alat sehingga Anda dapat memutuskan apakah akan membangun, membeli, atau menggunakan API penggunaan OpenAI secara langsung.

Untuk konteks harga yang mendorong perhitungan biaya Anda, lihat rincian harga GPT-5.5. Untuk masalah atribusi penagihan terkait di sisi alat pengembang, lihat penagihan penggunaan GitHub Copilot untuk tim API. Untuk dasar-dasar API OpenAI, lihat referensi API OpenAI resmi.

Mengapa Dasbor Penagihan OpenAI Tidak Cukup

Buka halaman penagihan OpenAI sekarang. Anda akan melihat grafik pengeluaran harian, rincian model, dan batas penggunaan. Itulah seluruh permukaannya. Ini berfungsi dengan baik jika Anda memiliki satu aplikasi, satu pelanggan, dan satu fitur. Begitu Anda memiliki salah satu dari ini: beberapa fitur dalam produk yang sama, beberapa pelanggan, beberapa lingkungan, atau beberapa pengembang, dasbor tersebut menjadi tidak berguna.

Inilah yang hilang.

Total pengeluaran tanpa konteks. Dasbor memberitahu Anda bahwa Anda menghabiskan $312 kemarin untuk GPT-5.5. Dasbor tidak memberitahu Anda apakah itu berasal dari satu pelanggan yang memukul titik akhir obrolan dukungan Anda 50.000 kali atau dari pekerjaan latar belakang yang meringkas ulang seluruh basis pengetahuan Anda karena seseorang lupa membalikkan sebuah bendera. Keduanya terlihat identik di grafik.

Tidak ada rincian per fitur. OpenAI memberi tag permintaan berdasarkan kunci API dan model. Itu tidak memberi tag berdasarkan fitur Anda, rute, ID pelanggan, atau lingkungan. Jika Anda menginginkan salah satunya, Anda harus membangunnya sendiri. Tidak ada dimensi asli untuk analitik produk di dasbor.

Keterlambatan pelaporan. Data penggunaan muncul dengan penundaan yang diukur dalam puluhan menit hingga beberapa jam. Pada saat loop yang tidak terkendali muncul di dasbor Anda, itu sudah membakar kartu kredit. Anda memerlukan pelacakan real-time, bukan grafik historis.

Tidak ada primitif peringatan. OpenAI memberi Anda satu batasan anggaran per organisasi dan satu email notifikasi lunak. Tidak ada peringatan per kunci, tidak ada ambang batas per fitur, tidak ada deteksi anomali. Jika Anda menginginkan "beri tahu saya jika titik akhir obrolan melebihi $50 dalam satu jam", Anda harus membangunnya sendiri.

Tidak ada atribusi pelanggan. Jika Anda menjual SaaS B2B dengan fitur AI, Anda perlu tahu pelanggan mana yang mendorong pengeluaran mana sehingga Anda dapat menentukan harga, membatasi, atau melakukan upsell. Dasbor tidak dapat menjawab "berapa biaya pelanggan X bagi saya bulan ini". Tim keuangan Anda membutuhkan angka tersebut untuk menghitung margin kotor per pelanggan. Tanpa itu, ekonomi unit Anda hanya tebak-tebakan.

Akun layanan dan kunci tingkat proyek membantu, tetapi hanya sebagian. Kunci proyek OpenAI memungkinkan Anda membagi penggunaan berdasarkan proyek. Itu memberi Anda satu tingkat atribusi. Itu tidak memberi Anda per fitur, per pelanggan, atau per rute. Anda masih memerlukan metadata tingkat aplikasi untuk menjawab pertanyaan-pertanyaan penting. API penggunaan OpenAI mengembalikan data agregat per proyek, bukan per permintaan.

Pola ini terulang di setiap tim yang mengirimkan fitur LLM dalam skala besar. Thread Dev.to "OpenAI Tells You What You Spent. Not Where. So I Built a Dashboard" menjadi viral karena secara gamblang menyebutkan masalahnya: Anda tidak dapat mengelola apa yang tidak dapat Anda ukur. Dasbor bawaan menjawab pertanyaan keuangan. Anda perlu menjawab pertanyaan produk.

Model Data Atribusi Biaya

Atribusi biaya dimulai dengan satu keputusan: setiap permintaan OpenAI mendapatkan peristiwa berlabel yang ditulis ke gudang data Anda. Peristiwa tersebut adalah unit analisis Anda. Dapatkan skema yang benar dan sisa pekerjaan, dasbor, peringatan, batasan, akan menjadi kueri SQL.

Berikut adalah skema minimum yang Anda butuhkan.

Hitung biaya saat menulis, bukan saat kueri. Harga berubah; Anda ingin angka yang beku yang mencerminkan tarif yang Anda bayarkan pada hari permintaan terjadi. Logika perhitungan untuk GPT-5.5 terlihat seperti ini:

PRICING = {  # USD per 1 juta token, per Mei 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)

Token penalaran dihitung sebagai output. API OpenAI mengembalikannya di usage.completion_tokens_details.reasoning_tokens, tetapi ditagih dengan tarif output. Lewati ini dan Anda akan menghitung kurang biaya pada setiap panggilan mode Berpikir. Untuk matematika harga lengkap, lihat rincian harga GPT-5.5.

Sekarang bungkus klien OpenAI. Setiap panggilan melewati satu fungsi. Fungsi tersebut mengambil metadata, membuat permintaan, dan menulis peristiwa.

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

Wrapper tunggal itu adalah permukaan atribusi biaya Anda. Setiap fitur dalam produk Anda memanggilnya. Baris log terstruktur adalah input gudang data Anda. Dari sini, kirim log ke BigQuery, ClickHouse, Snowflake, atau Postgres melalui pipeline log Anda yang sudah ada (Vector, Fluent Bit, Logstash, OTLP collector). Tidak ada pipeline kedua. Tidak ada layanan tambahan.

Untuk tim Node.js, bentuknya identik. Bungkus SDK OpenAI dalam sebuah fungsi yang mengambil metadata, menangkap response.usage, menghitung biaya, dan menulis baris JSON. Jika platform Anda sudah menjalankan bus peristiwa (Kafka, NATS, Pub/Sub), publikasikan peristiwa tersebut di sana daripada stdout dan biarkan konsumen hilir menyebarkannya ke gudang data Anda dan sistem peringatan Anda.

Hubungkan Pelacakan Biaya dan Uji dengan Apidog

Anda memiliki skema dan wrapper. Sekarang ubah menjadi sesuatu yang operasional. Enam langkah.

1. Ganti panggilan OpenAI langsung dengan wrapper. Cari di basis kode Anda untuk OpenAI( dan client.chat.completions.create. Setiap hit menjadi panggilan call_with_attribution(...). Jadikan feature dan route argumen wajib. Teruskan di situs panggilan, bukan dari global. Jika Anda lupa meneruskannya, fungsi tersebut harus memunculkan kesalahan, bukan mengaturnya ke "tidak dikenal".

2. Keluarkan log terstruktur. Catat ke stdout sebagai JSON, satu baris per peristiwa. Atur tingkat logger ke INFO khusus untuk peristiwa ini. Jangan mencampurkannya dengan "noise" debug. Jika Anda sudah menggunakan logger terstruktur (structlog, pino, winston), hubungkan ke sana.

3. Agregasikan per fitur di gudang data Anda. Setelah peristiwa masuk ke BigQuery atau ClickHouse, kueri akan menulis sendiri:

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. Buat grafik pengeluaran per rute. Arahkan Grafana, Metabase, Looker, atau Superset ke tabel tersebut. Buat tiga tampilan: pengeluaran per fitur dari waktu ke waktu, pengeluaran per pelanggan dari waktu ke waktu, dan tabel 20 rute teratas yang diurutkan berdasarkan pengeluaran kemarin. Itulah dasbor operasi harian Anda.

5. Uji wrapper dengan Apidog sebelum Anda meluncurkannya. Ini adalah langkah yang dilewati sebagian besar tim dan disesali. Wrapper Anda menulis log terstruktur. Jika skema salah, gudang data Anda secara diam-diam salah, dan dasbor berbohong. Gunakan Apidog untuk menjalankan pengujian end-to-end terhadap layanan Anda:

• Buat skenario di Apidog yang mengirimkan permintaan ke titik akhir AI Anda dengan customer_id dan feature yang diketahui.
• Tangkap respons dan emisi log saluran samping (stdout, OTLP, titik akhir log Anda).
• Gunakan pernyataan respons Apidog untuk memverifikasi bahwa payload log berisi feature, route, customer_id yang diharapkan, dan bahwa cost_usd > 0 serta prompt_tokens > 0.
• Jalankan skenario yang sama di seluruh lingkungan staging dan produksi menggunakan variabel lingkungan Apidog.
• Putar ulang permintaan yang ditandai dan pastikan bahwa panggilan yang dicoba ulang tidak menghitung biaya dua kali (wrapper Anda harus menggunakan kembali request_id pada percobaan ulang).

Untuk pendekatan pengujian API yang lebih luas yang sesuai dengan langkah verifikasi ini, lihat alat pengujian API untuk insinyur QA. Untuk pendekatan contract-first yang dipadukan dengan cakupan atribusi biaya, lihat pengembangan API contract-first.

6. Tetapkan batasan anggaran per kunci dan peringatan. OpenAI memungkinkan Anda membuat satu kunci proyek per lingkungan atau per fitur. Gunakanlah. Buat kunci prod-support-chat, kunci prod-summarization, kunci staging-all. Tetapkan batas keras di dasbor OpenAI sehingga loop yang tidak terkendali pada satu fitur tidak dapat menguras seluruh anggaran organisasi. Lapisi dengan sistem peringatan Anda sendiri: kueri SQL yang berjalan setiap 10 menit dan memberi Anda notifikasi jika ada fitur yang melebihi 3x rata-rata pengeluaran per jam selama 7 hari. PagerDuty, Opsgenie, atau webhook Slack semuanya berfungsi; pemicu berasal dari gudang data Anda, bukan dari OpenAI.

Kombinasi batasan kunci bawaan ditambah peringatan berbasis gudang data memberi Anda dua lapisan pertahanan. Batasan bawaan adalah penahan terhadap pengeluaran yang merugikan. Peringatan gudang data menangkap pergeseran lambat sebelum batasan dipicu.

Teknik Lanjutan dan Kiat Profesional

Setelah pipeline dasar berjalan, optimalisasi akan menyusul.

Penyimpanan cache prompt. GPT-5.5 mengenakan biaya 50 persen dari tarif input untuk token yang disimpan dalam cache. Strukturkan prompt sistem Anda sebagai awalan yang stabil dan letakkan variabel per permintaan di akhir. Tingkat hit cache di atas 70 persen pada beban kerja obrolan adalah normal setelah Anda melakukan ini. Lacak cache_hit_rate per fitur di dasbor Anda sehingga Anda dapat melihat kapan perubahan prompt menurunkan tingkat hit Anda. Dokumen caching prompt OpenAI resmi mencakup aturan kelayakan.

API Batch untuk pekerjaan offline. Apa pun yang tidak memerlukan respons sinkron melalui API Batch untuk diskon 50 persen. Ringkasan malam, menjalankan evaluasi, pengisian ulang embedding, pemrosesan ulang dokumen. Wrapper biaya masih berlaku; panggil titik akhir Batch dan beri tag peristiwa dengan batch_job_id sehingga Anda dapat mengatribusikannya kembali ke beban kerja sumber.

Penyesuaian upaya penalaran. GPT-5.5 Thinking adalah model yang sama dengan reasoning.effort yang lebih tinggi. Setiap tingkat upaya melipatgandakan token output. Audit fitur Anda: apakah Anda menjalankan medium di mana low akan memenuhi standar kualitas? Jalankan uji A/B, lacak kualitas dan biaya, kirim opsi yang lebih murah jika kualitas tetap terjaga. Untuk matematika yang lebih mendalam, lihat cara menggunakan API GPT-5.5.

Disiplin jendela konteks. Prompt panjang mahal. RAG dengan anggaran pengambilan yang ketat lebih baik daripada memasukkan seluruh basis pengetahuan ke dalam jendela konteks. Lacak rata-rata prompt_tokens per fitur; jika naik dari minggu ke minggu tanpa perubahan fitur, prompt Anda membengkak.

Perhatikan batas 272K-token GPT-5.5. OpenAI menerapkan pengganda input 2x dan pengganda output 1,5x pada permintaan di atas 272K token. Tambahkan pelindung di wrapper Anda yang mencatat peringatan ketika prompt_tokens > 250000 sehingga Anda dapat menangkap prompt yang akan mencapai batas tersebut. Untuk detail harga, lihat postingan harga GPT-5.5.

Batasan pengeluaran per pelanggan. Jika Anda menjual B2B dan kontrak Anda mencakup fitur yang didukung LLM, Anda memerlukan batasan per pelanggan. Hitung pengeluaran bergulir per customer_id dari gudang data Anda dan minta aplikasi Anda memeriksanya sebelum setiap panggilan. Jika batasan tercapai, kembalikan 429 dengan pesan "kuota AI bulanan terlampaui" dan CTA penagihan. Inilah yang mengubah fitur AI dari risiko margin menjadi produk margin.

Kesalahan umum yang harus dihindari.

• Menghitung token penalaran sebagai input. Mereka adalah output. Tagih dengan tarif output.
• Mempercayai dasbor OpenAI untuk keputusan real-time. Ada jeda. Gunakan gudang data Anda sendiri.
• Memberi tag di tingkat SDK alih-alih di situs panggilan. Tag seharusnya bersama fitur, bukan klien.
• Lupa memberi tag pada tugas latar belakang. Cron jobs, pekerja antrean, dan webhook membuat panggilan OpenAI yang sama; beri tag dengan route sintetik seperti cron:nightly-summarize atau queue:image-caption.
• Sampling. Jangan lakukan sampling. Catat setiap permintaan. Volume data sepele; akurasi atribusi tidak.
• Membiarkan customer_id menjadi null. Jika Anda tidak tahu pelanggan, catat internal atau system, jangan pernah null. Null menjadi lubang hitam atribusi.

Alternatif dan Peralatan

Anda tidak harus membangun ini sendiri. Berikut adalah perbandingan yang jujur.

Pertimbangan yang perlu diingat. Sebuah proksi (Helicone) menempatkan satu lompatan di jalur kritis Anda; biaya latensi kecil tapi nyata, dan Anda bergantung pada ketersediaan mereka. Tumpukan observabilitas yang di-host sendiri (Langfuse) memberi Anda kontrol penuh tetapi Anda yang mengoperasikannya. Jalur gudang data kustom adalah apa yang sebagian besar tim besar pilih; ini terintegrasi dengan sisa tumpukan data Anda, tetapi Anda menulis kueri dan peringatan sendiri. API penggunaan bawaan baik-baik saja jika kebutuhan Anda sederhana, tidak berguna setelah tidak sederhana.

Untuk bacaan lebih dalam tentang seperti apa observabilitas biaya LLM yang baik dalam praktik, panduan tim Helicone tentang pelacakan biaya LLM menjelaskan pendekatan berbasis proksi. Dokumentasi Langfuse tentang pelacakan biaya mencakup jalur sumber terbuka.

Jika Anda mengoperasikan ini pada skala platform, pola-pola ini dapat digeneralisasi. Lihat platform API untuk arsitektur mikroserevisi untuk melihat bagaimana wrapper atribusi biaya cocok dengan strategi service mesh.

Studi Kasus Nyata

SaaS B2B dengan pengeluaran LLM per pelanggan. Sebuah perusahaan menjual produk intelijen penjualan. Setiap pelanggan memicu panggilan GPT-5.5 ketika mereka meminta ringkasan. Tanpa atribusi, perusahaan tahu bahwa mereka menghabiskan $80.000 sebulan untuk OpenAI. Dengan atribusi per pelanggan, mereka mengetahui bahwa 12 persen pelanggan mendorong 71 persen pengeluaran. Perusahaan memperkenalkan harga berjenjang, kuota lunak pada tingkat terendah, dan biaya kelebihan per kursi. Margin kotor pada fitur AI bergerak dari 41 persen menjadi 73 persen dalam satu kuartal.

Pelacakan alat pengembang internal. Sebuah organisasi rekayasa memberi setiap pengembang akses ke asisten obrolan GPT-5.5 pribadi. Dengan tag per pengembang (customer_id menjadi dev_email), rekayasa platform melihat bahwa tiga pengembang menyumbang 50 persen dari pengeluaran internal. Dua di antaranya menjalankan loop agen otomatis yang lupa mereka matikan. Mematikannya menghemat $1.800 sebulan. Yang ketiga melakukan pekerjaan yang sah; data tersebut membenarkan kuota organisasi yang lebih tinggi untuk mereka.

Perkiraan pengeluaran fitur AI. Tim produk ingin meluncurkan fitur ringkasan baru. PM tidak tahu cara memperkirakan biaya. Dengan data historis per fitur, tim membangun model: rata-rata token prompt per panggilan, rata-rata token output, perkiraan panggilan per pengguna aktif, perkiraan pengguna aktif. Perkiraan kembali: $0,04 per pengguna aktif per hari, atau $1,20 per bulan. Tim harga menentukan harga fitur pada $5 per pengguna per bulan. Tim keuangan menyetujui karena ekonomi unit terlihat.

Kesimpulan

Anda tidak dapat mengelola apa yang tidak dapat Anda ukur. Dasbor penagihan OpenAI menjawab pertanyaan keuangan. Atribusi per fitur, per pelanggan, per rute menjawab pertanyaan produk. Bangun wrapper, catat peristiwa, kueri gudang data, dan baris AI Anda tidak lagi menjadi misteri.

Lima poin penting:

• Beri tag setiap permintaan dengan fitur, rute, customer_id, dan lingkungan. Jadikan tag wajib di situs panggilan.
• Hitung biaya pada saat menulis sehingga data historis mencerminkan tarif yang Anda bayarkan pada hari itu.
• Gunakan satu kunci proyek per lingkungan dan tetapkan batasan keras di dasbor OpenAI sebagai pengaman.
• Lapisi peringatan berbasis gudang data di atas batasan bawaan sehingga Anda menangkap pergeseran lambat sebelum batasan terpicu.
• Uji wrapper dengan Apidog sebelum Anda meluncurkannya; tag yang salah berarti kesalahan atribusi yang tersembunyi.
• Audit upaya penalaran dan ukuran prompt setiap kuartal; optimalisasi termurah adalah yang menjaga kualitas tetap datar.
• Lacak tingkat hit cache per fitur sehingga perubahan prompt tidak secara diam-diam menggandakan biaya input Anda.

Unduh Apidog dan gunakan untuk memverifikasi wrapper atribusi biaya Anda secara menyeluruh. Dorong titik akhir AI Anda dengan permintaan berlabel, tegaskan bentuk payload log, dan putar ulang skenario di seluruh lingkungan sehingga data yang dipercaya gudang data Anda adalah data yang ditulis oleh insinyur Anda.

Untuk bacaan terkait manajemen biaya, lihat rincian harga GPT-5.5 dan penagihan penggunaan GitHub Copilot untuk tim API.

FAQ

Apakah token penalaran dihitung sebagai input atau output untuk penagihan?Token penalaran ditagih dengan tarif output. API OpenAI mengembalikannya di bawah usage.completion_tokens_details.reasoning_tokens. Tambahkan ke completion_tokens saat Anda menghitung biaya. Untuk pengganda per upaya, lihat rincian harga GPT-5.5.

Seberapa akurat response.usage dibandingkan dengan dasbor OpenAI?Jumlah token dalam response.usage cocok dengan dasbor hingga token. Perubahan harga dapat menyebabkan sedikit perbedaan jika Anda menghitung biaya dari tabel tarif yang usang; tetapkan tarif per model dan perbarui pada hari OpenAI mengirimkan perubahan harga.

Bisakah saya melakukan atribusi hanya dengan kunci proyek OpenAI?Kunci proyek memberi Anda satu dimensi atribusi: per proyek. Kunci tersebut tidak memberi Anda per fitur, per pelanggan, atau per rute. Gunakan kunci proyek untuk pembagian lingkungan dan batasan anggaran; gunakan metadata tingkat aplikasi untuk yang lainnya.

Bagaimana dengan percobaan ulang dan kesalahan batas tarif? Apakah itu menghitung biaya dua kali?Permintaan yang gagal sebelum model berjalan (4xx, kesalahan jaringan sebelum selesai) tidak mengembalikan objek usage, sehingga tidak ada biaya yang dicatat. Permintaan yang berhasil dan kemudian dicoba ulang di lapisan aplikasi akan dicatat dua kali kecuali Anda menggunakan kembali request_id. Percobaan ulang yang idempoten harus meneruskan request_id yang sama dan wrapper Anda harus melakukan deduplikasi saat menulis.

Seberapa cepat API penggunaan OpenAI mengembalikan data?API penggunaan memiliki jeda puluhan menit. Untuk keputusan real-time (peringatan, sakelar pemutus), gunakan gudang data Anda sendiri. Untuk rekonsiliasi bulanan, API penggunaan baik-baik saja dan cocok dengan faktur penagihan Anda.

Haruskah saya mengambil sampel permintaan untuk mengurangi volume log?Tidak. Volume data kecil (satu baris JSON per permintaan), dan sampling merusak atribusi per pelanggan dan per rute. Catat setiap permintaan.

Bisakah saya menggunakan pendekatan ini untuk penyedia LLM lainnya?Ya. Skema ini bersifat umum. Tambahkan kolom provider (openai, anthropic, google, deepseek) dan satu tabel harga per penyedia. Wrapper bersifat spesifik penyedia; gudang data dan dasbor tidak. Untuk titik perbandingan, lihat harga API DeepSeek V4.

Apakah ini juga berfungsi untuk panggilan embeddings dan pembuatan gambar?Ya, dengan matematika biaya spesifik penyedia. Embeddings ditagih per token input dengan tarif tetap; gambar ditagih per gambar dengan tarif per resolusi. Tambahkan endpoint (misalnya chat, embeddings, image) ke skema dan cabang perhitungan biaya Anda berdasarkan itu.

tombol