Pricing model
The proposed standard pricing is $0 per month plus a 15% platform markup on configured model usage. This is a markup on upstream cost: $1.00 of provider cost becomes $1.15 of customer charges, not a 15% gross margin. Model prices shown to customers include that markup.
Reserve first, settle afterward
- Before dispatch, the gateway calculates a conservative maximum cost from the input bound and requested max_tokens.
- It checks your available wallet balance and the key’s monthly budget.
- It holds that amount atomically.
- After validated token usage returns, it charges actual usage and releases the unused portion.
A request can be denied even when the expected answer would cost less than the available balance. Reducing max_tokens reduces the maximum reservation. Concurrent requests and unresolved outcomes also consume available capacity.
How the charge is calculated
provider_cost = (prompt_tokens × input_rate_per_million
+ completion_tokens × output_rate_per_million) / 1,000,000
customer_charge = provider_cost × 1.15Internally, amounts use integer nanodollars. The customer charge is rounded upward to the nearest nanodollar. Use gateway.charged_usd as the settled charge rather than rebuilding billing from rounded display prices.
Billing after a failure
| Outcome | Wallet treatment |
|---|---|
| Rejected before reservation | No usage charge or hold. |
| Known provider rejection | Maximum reservation is released. |
| Unknown provider outcome | Reservation remains held for reconciliation. |
| Successful generation | Actual validated usage charged; remainder released. |
| Synthetic output withheld | Generated usage is still charged. |
| Provider usage exceeds bounds | Charge is capped at the reservation and the key is paused for review. |
Pricing boundaries
The current accounting supports flat input/output token prices. Cached-token discounts, long-context tiers, batch rates, and other dimensions are not implemented. Routes with unsupported cached usage are held for review. No customer self-refund API or production invoice reconciliation is available yet.
Auto-recharge
Auto-recharge is opt-in. In Credits, choose a balance threshold, a recharge amount, and a calendar-month cap (UTC), then authorize a card through Stripe. It is currently being verified in the owner-only Stripe sandbox; no live card charges are enabled.
Only settled spending triggers a recharge; temporary model reservations do not. Gateway allows one unresolved recharge per workspace and adds credits only after verified Stripe confirmation. Duplicate payment events do not add duplicate credits. Failed payments pause auto-recharge. Unknown outcomes require reconciliation before another automatic charge. Turning it off stops new attempts; an already-started payment may still complete.
Card details remain with Stripe. Gateway stores the customer and payment-method references, consent, limits and accounting records. Manual purchases do not count toward the auto-recharge cap. A production launch also requires live payment acceptance, customer agreements, taxes/receipts and operational review.
When a known payment is delayed, use Check payment status in Credits. Gateway retrieves that existing payment from Stripe without initiating another charge. Background checks use the same verified settlement path, with a five-minute backoff shared across app instances. A successful payment adds credits once even if its webhook arrives later. A paused recharge stays off until you explicitly re-enable it.
If a payment failed, choose Use a different card and save your settings to replace the card through Stripe. Unresolved payments block a new automatic charge. If no payment reference was received or authentication is required, contact support for resolution before retrying.