To plan an accurate budget for OpenRouter, you must separate the cost of processed requests from the upfront funds you deposit into your account balance. In addition, you need to independently evaluate BYOK (Bring Your Own Key) rules if you connect your own provider API credentials. A single published rate "per million tokens" does not account for all of these financial components.
Model Pricing and Credit Top-Ups Are Separate Line Items
According to the official FAQ, request costs are deducted from your prepaid credit balance, with rates determined by the underlying model and provider. OpenRouter states that it passes provider rates through without inference markups; the platform commission applies when purchasing credits. On the pricing page as of September 14, 2026, the fee listed for Pay-as-you-go is 5.5%.
Before completing any payment, cross-reference three separate values: the credit amount you will receive, the displayed fee, and the final amount charged to your payment method. Check the live checkout calculation for any minimum transaction fees, applicable taxes, or payment method surcharges. A published percentage in a pricing table does not replace the final checkout total.
Consider a stylized example: if purchasing $100 in credits incurs an added platform fee of 5.5%, your total payment will be $105.50. This is an arithmetic illustration excluding taxes, currency conversion, and processing fees—not an exact checkout capture. After consuming $20 in credits, your remaining balance stands at $80; you cannot attribute the full initial payment as the cost of those first few requests.
How to Estimate Your Actual Workload
For a standard text completion scenario without prompt caching or additional billable capabilities:
request_cost = input_tokens / 1000000 * input_price
+ output_tokens / 1000000 * output_price
Take a real-world BetterToken rate for glm-5.3 within the GLM group, verified on September 14, 2026, against the current pricing catalog. In US dollars per million tokens, input pricing is $1.232 and output pricing is $3.872. For 8,000 un-cached input tokens and 2,000 output tokens, the breakdown is:
input_cost = 8000 / 1000000 * 1.232 = $0.009856
output_cost = 2000 / 1000000 * 3.872 = $0.007744
total_cost = $0.0176
1000_requests = $17.60
BetterToken does not add an extra transaction fee to this total: for this volume, the cost remains $0.0176 per request or $17.60 per one thousand identical requests. There is no need to multiply this amount by 1.055—OpenRouter deposit fees do not apply to BetterToken. The token counts in this scenario are illustrative; the pricing is taken directly from the active catalog rather than a hypothetical model. Cached tokens and extra tool calls are not included in this figure. This serves as an example calculation for BetterToken, not a direct price comparison against GLM-5.3 on OpenRouter.
To convert this calculation into a practical operational budget, measure actual request sizes, including full conversation histories and system instructions. Track short prompt queries and long-context processing separately. For autonomous agents, tally every intermediate call required before the final output is accepted, rather than budgeting only for the terminal response. Any retry triggered by an unsatisfactory response must also be logged in your expense records if it generated a billable API call.
Prompt caching, image inputs, reasoning tokens, and per-request surcharges can alter cost calculations: verify the specific billing units on the model card. Usage is audited via Activity logs. For comparison with BetterToken, consult its pricing page and your own usage data in Workspace, where model, token quantities, and expenditures are visible. Always evaluate identical workloads and identical billing units; observing two different rate cards alone does not prove which path will be more cost-effective.
Free Tier Access Does Not Mean Unlimited Throughput
The pricing page lists a cap of 50 requests per day for the free tier. This quota is not a blanket service guarantee across every account type or paid fallback route. The rate limits documentation distinguishes between spending limits and request velocity limits: an HTTP 402 error requires checking your account balance and API key limit, whereas an HTTP 429 status code can originate from either the OpenRouter platform or the upstream provider.
When you encounter an HTTP 429, inspect the response body and the Retry-After header if available, and implement backoff delays between attempts. Do not write unrestricted retry loops. If your routing rules fall back to a paid model, factor that model's costs into your budget prior to deployment. While a free route is helpful for verifying compatibility, production workloads require a clear operational strategy for rate-limit exhaustion or service errors.
BYOK: Verify Both Invoices
BYOK (Bring Your Own Key) enables routing requests through OpenRouter using your own upstream provider API key. According to the pricing page as of September 14, 2026, Pay-as-you-go includes up to $25,000 in monthly list-price inference without a BYOK fee, after which a 5% platform fee applies. This figure represents a dollar threshold for fee exemptions—it is neither an allowance of free requests nor a promise that OpenRouter covers your upstream provider bill.
Key configuration is managed in the workspace BYOK interface. Under the BYOK documentation, request dispatch follows a defined hierarchy: traffic prioritizes configured Prioritized keys, transitions to shared OpenRouter endpoints if needed, and finally routes to Fallback keys, subject to model filters and routing constraints. Falling back to shared capacity draws down your OpenRouter credit balance. Furthermore, workspace budgets and guardrail budgets exclude BYOK spend by default; they must be explicitly configured using the "Include BYOK spend" setting if desired.
To configure and validate your BYOK pipeline, follow these steps:
- Verify permissions and filters: Confirm that your provider API key has the required model permissions, and establish matching model filters in OpenRouter.
- Set key priority policies: Define the priority order across keys and determine whether requests are permitted to roll over to shared OpenRouter endpoints or Fallback keys.
- Separate your budget allocations: Set spending limits independently—one directly with your upstream provider and another on your OpenRouter balance to cover fallback capacity or BYOK fees once the free tier threshold is passed.
-
Execute a single test request: Send one bounded request, open the Activity log to View Raw Metadata, check the
provider_responsesblock, and verify that the recorded data aligns with your actual provider billing statements. Never assume automated cost tracking perfectly matches upstream invoices without direct verification.
If a single direct API meets your operational needs, compare its monthly invoice against routing the same workload through OpenRouter. If you require multi-model redundancy or dynamic routing, factor in the architectural convenience of unified billing and standardized endpoints. For an initial evaluation, a small, bounded test batch is sufficient: your total cost per accepted result provides far more insight than evaluating baseline token prices in isolation.
Originally published on the BetterToken blog.
BetterToken provides pay-as-you-go access to AI model APIs through
OpenAI-compatible and Anthropic-compatible endpoints — useful if you are wiring
Claude Code, Codex, or your own tooling to a custom base URL.
See the docs to get started.
Top comments (0)