Billing and usage
You prepay on chain, and every request debits that balance as it is served. That splits spend into two questions that need different answers. Seeing what an individual call cost is per-request data you read off the response. Knowing whether you are about to run out is account-level state you have to go and check.
What’s here
Section titled “What’s here”| Page | When you need it | What it solves |
|---|---|---|
| Cost per request | You need to attribute spend to a feature, a customer, or a model, or explain why one call cost more than another | Reads input, output, and total cost from the x_0g_trace.billing block on every response, and logs it with the request ID |
| Balance & usage | You need to know the balance is dropping before it reaches zero and every request starts failing | Reads balance and usage from the account endpoints with an mk- management key, and puts an alert on a schedule |
Where to start
Section titled “Where to start”If you are still deciding how any of this works, read Pricing and billing first — it explains the prepay model and where prices come from, which the two pages here assume. If you are already writing code, start with Cost per request, because the data is already in responses you are receiving and getting it into structured logs takes a few lines. Before you serve real traffic, do Balance & usage as well: a balance at zero is a hard stop with no warning attached, so the alert has to be something you built.
One thing catches most people on the account endpoints: /v1/account/* accepts only an mk- management key. An sk- inference key returns 403 insufficient_scope no matter what it is scoped to. See API keys for creating each kind.
Related
Section titled “Related”- Pricing and billing — the prepay model and how a provider’s declared prices become your charge.
- Cap what a single request may cost — bound a request’s price before it is routed, rather than reading the cost afterwards.
- Get 0G and fund your account — how funds get onto the balance in the first place.