Langkah 1 · Pisahkan pembayaran pelanggan dari uang lain

Sebuah proyek bisa memperlihatkan kas masuk yang besar dan tetap kehilangan uang pada setiap tugas yang dikerjakannya. Karena itu langkah pertama bukan menghitung, melainkan memisahkan: uang mana yang masuk karena layanan benar-benar diberikan, dan uang mana yang masuk dari sumber lain.

Masuk ke baris pendapatan produkBerdiri di barisnya sendiri
Pembayaran pelanggan atas layanan, setelah refund dan biaya pembayaranPenjualan token dan penerbitan baru
Bagi hasil dari mitra yang terkait langsung dengan layananInvestasi, hibah, dan dana ekosistem
Pembayaran di muka, sebatas bagian yang layanannya sudah diserahkanKenaikan nilai aset treasury
—Transfer dari pihak terkait

Pembayaran di muka adalah titik yang paling mudah keliru. Uang yang sudah masuk rekening belum tentu pendapatan periode ini; bagian yang layanannya belum diserahkan masih berupa kewajiban, dan memindahkannya ke baris pendapatan membuat satu periode terlihat jauh lebih baik dengan cara mengosongkan periode berikutnya.

Sumber yang tidak bisa ditelusuri tidak dipaksa masuk ke salah satu kolom. Ia tetap berstatus belum diklasifikasi, dan statusnya itu ikut dilaporkan.

Langkah 2 · Hitung biaya variabel pada tugas yang diterima

Biaya variabel adalah biaya yang tumbuh mengikuti volume: inferensi model, panggilan alat, RPC, gas, biaya pembayaran, dan jam manusia yang dipakai per tugas. Satuannya sama dengan satuan pendapatan, yaitu satu tugas yang lolos kriteria penerimaan.

Kontribusi per tugas = pendapatan bersih per tugas diterima − biaya variabel penuh per tugas diterima

Dua hal menentukan apakah rumus itu jujur. Pertama, biaya percobaan yang gagal tetap dihitung dan dibebankan ke tugas yang akhirnya diterima; tanpa itu, naiknya tingkat kegagalan akan terlihat seperti turunnya biaya. Kedua, paket minimum bulanan dipecah dua: bagian yang benar-benar dipakai masuk biaya variabel, sedangkan kapasitas yang dibayar tanpa terpakai masuk biaya tetap di langkah berikutnya.

Rincian pos biaya, cara menyimpan tarif bertanggal, dan cara membebankan gas ke tugas pemicunya dibahas terpisah di biaya inferensi dan operasi Crypto AI Agent.

Langkah 3 · Tampilkan biaya tetap secara utuh

Kontribusi per unit yang positif belum berarti perusahaannya untung. Personel, kapasitas cloud yang sudah dikomitmenkan, keamanan, legal, dukungan, dan lisensi data berjalan terus terlepas dari berapa tugas yang masuk bulan itu.

Biaya tetap karena itu ditampilkan utuh untuk periode yang sama, dengan aturan alokasi yang tidak berubah di tengah periode. Item satu kali — audit, migrasi, penanganan insiden — ditandai sebagai satu kali, supaya tren tidak terlihat lebih buruk atau lebih baik daripada keadaan sebenarnya.

Yang dilaporkan tetap dua angka terpisah: contribution margin dan hasil operasi. Satu angka gabungan menyembunyikan dua pertanyaan yang jawabannya bisa berlawanan — setiap tugas bisa menguntungkan sementara perusahaannya rugi, dan sebaliknya.

Langkah 4 · Bagi biaya tetap dengan kontribusi, bukan dengan rasio

Titik impas adalah pembagian, dan pembaginya harus kontribusi per tugas. Rasio pendapatan terhadap biaya tidak bisa menggantikannya: rasio itu bisa terlihat membaik walaupun setiap tugas yang dikerjakan tetap merugi.

Volume impas = total biaya tetap periode ÷ kontribusi per tugas diterima

Kalau kontribusinya nol atau negatif, pembagian itu tidak punya jawaban: volume tambahan hanya memperbesar kerugian. Kesimpulan ini yang paling sering dihindari, padahal paling menentukan, karena rencana pertumbuhan tidak memperbaiki margin unit yang negatif — ia hanya mempercepat habisnya kas.

Bila kontribusinya positif, volume impas masih perlu dihadapkan pada tiga batas nyata: batas throughput model dan infrastruktur, kapasitas manusia yang melakukan tinjauan, dan ukuran pasar yang bisa dijangkau pada harga itu. Volume impas yang melampaui salah satu batas tersebut adalah hasil aritmetika, bukan rencana yang bisa dijalankan.

Tanda bahwa angka bagusnya ditopang subsidi

Angka yang bagus bisa benar dan tetap tidak berkelanjutan, kalau yang menopangnya adalah insentif yang punya masa berlaku. Lima tanda berikut yang biasanya terlihat lebih dulu:

  • harga jual berada di bawah biaya variabel penuh;
  • sebagian besar pemakaian datang dari pengguna yang menerima reward;
  • pembayaran dilakukan dengan token proyek sendiri, bukan dengan kas;
  • ada transfer melingkar antarpihak terkait yang muncul sebagai pendapatan;
  • retensi turun tajam segera setelah program insentif berhenti.

Cara memeriksanya adalah menyusun dua laporan untuk periode yang sama: satu dengan subsidi, satu tanpa. Selisih keduanya adalah ukuran ketergantungan, dan kurva retensi setelah insentif berhenti memperlihatkan apakah permintaannya bertahan sendiri.

Subsidi bukan bukti penipuan. Ia strategi yang biasa dipakai untuk membeli waktu; yang perlu jelas hanya sumber dananya, besarnya, dan sampai kapan ia dianggarkan.

Kondisi yang membuat hitungan ini batal

Hasil empat langkah di atas terikat pada periode, harga, dan susunan pelanggan yang dipakai saat menghitungnya. Empat perubahan berikut membatalkannya, dan masing-masing menuntut hitungan ulang pada baris yang tersentuh — bukan pada seluruh laporan:

  • tarif pemasok atau daftar model yang dipakai berubah;
  • harga jual atau struktur paket berubah;
  • program subsidi mulai atau berhenti;
  • satu pelanggan besar masuk atau keluar sehingga konsentrasinya bergeser.

Data yang tidak tersedia tidak diisi dengan satu angka tunggal. Hasilnya disajikan sebagai rentang beserta asumsi terburuknya, dan kata impas tidak dipakai sebelum ada angka yang bisa dihitung ulang oleh orang lain.

Buku kerja verifikasi

Bagian ini menyusun ulang empat langkah di atas sebagai pemeriksaan: untuk setiap langkah, satu hal yang dicari dan satu hal yang menggugurkannya. Tidak ada barisnya yang menghasilkan rekomendasi.

Langkah 1 — yang dicari
pembayaran yang bisa ditautkan ke layanan yang benar-benar diserahkan pada periode itu
Langkah 1 — yang menggugurkan
pendanaan, hibah, atau subsidi digabung ke dalam satu baris pendapatan
Langkah 2 — yang dicari
biaya yang dapat dijumlahkan dari trace tugas, termasuk percobaan yang gagal
Langkah 2 — yang menggugurkan
hanya panggilan berhasil, atau hanya model utama, yang ikut dihitung
Langkah 3 — yang dicari
total biaya tetap periode itu dengan aturan alokasi yang tidak berubah
Langkah 3 — yang menggugurkan
margin dipublikasikan tanpa tim operasi dan tanpa komitmen kapasitas
Langkah 4 — yang dicari
input rumus impas yang bisa dihitung ulang dari angka yang dipublikasikan
Langkah 4 — yang menggugurkan
rasio pendapatan terhadap biaya dipakai menggantikan kontribusi per tugas
Tanda subsidi — yang dicari
pemakaian berbayar yang tetap ada ketika reward dihentikan
Tanda subsidi — yang menggugurkan
insentif dihitung sebagai permintaan organik

Bila salah satu baris «yang menggugurkan» terbukti, yang dilaporkan adalah batas datanya, bukan kesimpulan yang diperhalus. Ketergantungan subsidi membatasi keberlanjutan; ia bukan temuan penipuan dan tidak ditulis seperti itu.

Hasil yang paling sering benar adalah rentang yang melewati titik impas di satu ujung dan tidak melewatinya di ujung lain. Itu jawaban yang sah, dan lebih berguna daripada satu angka yang dibulatkan supaya terlihat selesai.

Pertanyaan umum

Jika pengguna membayar gas, apakah masih dihitung?

Ungkap total biaya pengguna; apakah masuk biaya perusahaan bergantung pada pihak yang membayar.

Dapatkah pendapatan diperkirakan tanpa data publik?

Bisa sebagai skenario berasumsi, bukan revenue aktual atau margin terverifikasi.

Apakah margin positif menjamin keberlanjutan?

Tidak; biaya tetap, retensi, konsentrasi pelanggan, subsidi, dan kapasitas tetap penting.

Sumber yang menopang berkas ini

  1. AI x Crypto: Exploring Use Cases and Possibilities — Sumber primer untuk memeriksa cakupan, versi, perilaku, atau kontrol; periksa tanggal dan konteks halaman tertaut.
  2. Building effective agents — Sumber primer untuk memeriksa cakupan, versi, perilaku, atau kontrol; periksa tanggal dan konteks halaman tertaut.
  3. OpenAI Agents SDK — Sumber primer untuk memeriksa cakupan, versi, perilaku, atau kontrol; periksa tanggal dan konteks halaman tertaut.
  4. Ethereum JSON-RPC API — Sumber primer untuk memeriksa cakupan, versi, perilaku, atau kontrol; periksa tanggal dan konteks halaman tertaut.
  5. AI agent quickstarts for Safe Smart Account — Sumber primer untuk memeriksa cakupan, versi, perilaku, atau kontrol; periksa tanggal dan konteks halaman tertaut.
  6. NIST AI 600-1: Generative AI Profile — Sumber primer untuk memeriksa cakupan, versi, perilaku, atau kontrol; periksa tanggal dan konteks halaman tertaut.
  7. Viewing activity and data for a repository — Sumber primer untuk memeriksa cakupan, versi, perilaku, atau kontrol; periksa tanggal dan konteks halaman tertaut.