Guides
Billing
How requests are charged from your prepaid USD wallet — per-token prices, cache pricing, holds, the $1.00 overdraft, and per-key budgets.
On this page
Your organization has one prepaid wallet in US dollars. You fund it with QRIS top-ups in Rupiah, and every API request is charged to it per token. There are no subscriptions and no monthly fees.
Prices
| Token type | Price per 1M tokens |
|---|---|
| Input, cache hit | $0.010 |
| Input, cache miss | $0.400 |
| Output (including reasoning) | $1.600 |
Prices are fixed: they do not change by time of day or with exchange rates. Each request is charged from the usage the model provider reports in the response:
cost = prompt_cache_hit_tokens × $0.010 / 1,000,000
+ prompt_cache_miss_tokens × $0.400 / 1,000,000
+ completion_tokens × $1.600 / 1,000,000
Charges are computed to a billionth of a dollar, rounded up, and shown to six decimal places ($0.000001) in the console.
Worked example
A support chatbot sends a 12,400-token prompt. The system prompt and earlier turns were seen recently, so 8,000 tokens are a cache hit and 4,400 are a cache miss. The model writes 1,800 output tokens, reasoning included.
| Part | Tokens | Price per 1M | Cost |
|---|---|---|---|
| Input, cache hit | 8,000 | $0.010 | $0.000080 |
| Input, cache miss | 4,400 | $0.400 | $0.001760 |
| Output | 1,800 | $1.600 | $0.002880 |
| Total | 14,200 | $0.004720 |
A thousand requests like this cost $4.72. Without the cache, the same 12,400 input tokens would all be billed at $0.400 per 1M, and each request would cost $0.007840 — the cache saves about 40% here.
Cache pricing
The provider caches prompt prefixes automatically; you do not have to enable anything. When the beginning of a prompt matches a recent request, those tokens are billed at the cache-hit price. To benefit:
- Put stable content first: system prompt, tool definitions, reference documents.
- Put the parts that change — the latest user message — at the end.
- Keep the stable prefix byte-for-byte identical between requests.
usage.prompt_cache_hit_tokens and usage.prompt_cache_miss_tokens in each response tell you exactly how the prompt was split.
Holds
Before a request is sent to the model, Laras Router places a hold on your wallet: an amount reserved for that request, so that requests running at the same time can never spend the same money twice. When the request finishes, the hold is settled to the actual charge and the rest is released immediately.
The hold is sized to the most the request could cost — the largest prompt the model accepts at the cache-miss price, plus your output cap at the output price. With the default cap of 8,192 output tokens, that is about $0.41. With max_tokens at 384,000, about $0.86. You are only ever charged for actual usage; the hold just reserves room.
Your available balance is your balance minus the holds of requests still running.
Overdraft
A request is admitted as long as your available balance is above $0.00, even when it is smaller than the request's hold. When that request settles, its charge may take your balance below zero — by at most $1.00. The negative amount is deducted from your next top-up.
While your available balance is $0.00 or below, new requests fail with 402 insufficient_credit until you top up.
| Moment | Available balance |
|---|---|
| Before the request | $0.030000 |
| Request admitted, hold of $0.409830 placed | −$0.379830 while it runs |
| Request settles, actual charge $0.050000 | −$0.020000 |
| Next request | refused: 402 insufficient_credit |
| You top up $5.00 | $4.980000 |
This lets you spend your whole balance instead of stranding a few cents. It also means that with a small balance, one running request can hold all of it: further requests are refused until it settles.
Key budgets
Each API key can have an optional monthly budget in USD, set in the console. It protects your wallet from one runaway environment or leaked key.
- A key's month-to-date spend is its settled charges plus the holds of its requests still running.
- Months are calendar months in Jakarta time (WIB, UTC+7).
- A request whose hold would take the key past its budget fails with
402 key_budget_exceededbefore it reaches the model, and nothing is charged. - Because the hold counts, a key can be refused shortly before its budget is fully spent. For example, with $9.70 of a $10.00 budget used, a request holding $0.41 is refused.
- A budget only limits one key. It never lets a key spend more than your wallet balance.
Failed requests
- Requests refused by Laras Router (bad key, empty wallet, rate limit, invalid body) are never charged.
- A request the model provider rejects with a
4xxerror is not charged; its hold is released. - A request that fails with a
5xx, times out, or is interrupted keeps its hold while we reconcile it with the provider. You are charged only for usage the provider reports; otherwise the hold is released without a charge.
Low-balance email
When your available balance drops below $1.00, the owners and admins of your organization receive one email with a link to top up. The next alert is sent only after the balance has gone back above $1.00 and dropped again.
Where to see charges
The console shows your balance, every top-up and charge in the wallet history, and each request under Usage with its token split and exact cost. Include the X-Laras-Request-ID header value when you ask support about a specific charge.