Operations
Billing and usage
Openbase is prepaid. Credit sits in a balance, and each request draws down what it actually cost.
How a request is priced
Cost is input tokens times the model's input rate, plus output tokens times its output rate, both quoted per million tokens on the catalog. The platform fee is already included in those published rates, so there is no separate line item.
cost = (prompt_tokens / 1_000_000) * input_rate
+ (completion_tokens / 1_000_000) * output_rateReasoning tokens
Models that think before answering produce hidden reasoning tokens. Providers bill those at the output rate, so Openbase does too. They are counted inside completion_tokens and broken out under completion_tokens_details.reasoning_tokens so nothing is hidden from you.
Providers disagree about the arithmetic
Some vendors fold reasoning tokens into completion_tokens and some report them separately. Openbase normalises both conventions before charging, so the same workload costs the same regardless of which upstream served it.
What is never billed
- Requests rejected for a bad model, a bad key or an empty balance.
- Failed attempts against providers that were retried during failover.
- Requests where the upstream returned an error before producing tokens.
Balance and precision
Balances are held in micro-dollars, one millionth of a dollar, because a single small request can cost a fraction of a cent. Amounts cross the API as integer micro-dollar values to avoid floating point drift.
Usage reporting
- Per request. Model, provider, tokens, latency, time to first token and exact charge.
- Daily. Rolled up per model and provider for charts and exports.
- Monthly. An invoice summarising the period, available in the dashboard.
Adding credit
Top up from the billing page. Promotional codes can be redeemed against the same balance, and administrators can grant credit directly, which is how support adjustments and refunds are handled.