Token Weighting Inference Plan: How Counted Tokens Bill Usage

A token weighting inference plan doesn't bill you for raw tokens. It bills you for weighted tokens: output tokens count at 4x, fresh input tokens count at 1x, and cached input tokens count as low as 0.25x, with one model priced even lower at 0.03x. The three weighted totals get summed into a single "counted token" number, and that number is what runs against your monthly allowance. That's the entire billing mechanism behind Spheron's managed inference plans, and it's why a long, cache-heavy agent conversation can land on an invoice for a fraction of what its raw token count would suggest.

The mechanism matters most on exactly the traffic pattern agents produce: a conversation that resends most of its own history on every call, so the cached share of a prompt grows turn over turn even as the raw token count climbs.

TL;DR: How a Token Weighting Inference Plan Bills Usage

A counted token is a weighted sum, output at 4x, fresh input at 1x, cached input as low as 0.25x, billed against a fixed monthly allowance instead of a moving per-token rate.

• Weights: Spheron weighs output at 4x, fresh input at 1x, and cached input at 0.25x (0.03x on DeepSeek V4.1 Flash).
• Example: 16,000 cached input + 2,000 fresh input + 400 output tokens equal 7,600 counted tokens, 59% below the 18,400-token raw total.
• Overage: Usage past the allowance bills at the plan's rate; unused tokens expire monthly with no rollover.
• Routers: OpenRouter bills at list price with no markup, taking its fee only on credit purchases. Compare per-token rates.

How a Token Weighting Inference Plan Weighs Output, Fresh Input, and Cached Input

A counted token isn't one thing. It's the sum of three separately weighted totals: fresh input tokens at 1x, cached input tokens at 0.25x (0.03x on DeepSeek V4.1 Flash), and output tokens at 4x. The reasoning is serving cost, not an arbitrary multiplier: output costs the most to serve and cached input the least, so the weights track what each token type actually does to a GPU.

The mechanics behind that gap come from how an inference engine handles a request. Fresh input tokens go through full prefill, the pass where the model builds the KV cache for everything it's about to attend over. Output tokens are worse: every single output token requires its own forward pass through the model during decode, one token at a time, which is why output is weighted highest. Cached input tokens skip almost all of that work. If a request's prompt starts with the same token sequence as something already served, the engine reuses the stored KV cache tensors for that prefix instead of recomputing them. What is prefix caching? covers that mechanism in detail; the billing weight on Spheron's plans is the pricing layer built on top of it, not the mechanism itself.

Here's the weight table as it applies across models:

Every plan serves the same three models: GLM-5.3, GLM-5.3-Flash, and DeepSeek V4.1 Flash, with Dedicated plans able to add a custom or fine-tuned open model on top. The plans themselves scale by monthly counted-token allowance and concurrency, not by model selection:

Spheron's inference page describes the plans in one line: "a month of counted tokens on one open model, paid up front, at a price that does not move." The GPUs backing every plan are reserved, never spot, so throughput doesn't degrade from preemption mid-contract, and data retention is zero: prompts and answers pass through the serving layer and are never stored or used for training. Each model runs at the precision its maker publishes. None of the plan prices themselves are published; they're quoted through Spheron's request form once you've picked a tier.

Why Long Agent Contexts Stay Cheap: A Worked Example

Here's a single agent turn, the kind a coding agent or a tool-calling loop fires dozens of times a session.

Say the call carries a system prompt, tool definitions, and the full prior conversation, 16,000 tokens total, that match a prefix already served on an earlier call in the same session. On top of that sits 2,000 tokens of genuinely new content (the latest user message plus a tool result), and the model writes back 400 output tokens.

Raw token count: 16,000 + 2,000 + 400 = 18,400 tokens.

Counted token count, weighting each part separately:

7,600 counted tokens against an 18,400-token raw count, a 59% reduction, entirely from the fact that most of the prompt was cached rather than fresh. Run the same math against DeepSeek V4.1 Flash's 0.03x cache weight instead of the standard 0.25x: cached input drops to 16,000 x 0.03 = 480 counted tokens, and the total falls to 4,080, a 78% reduction against the raw count.

This compounds the longer an agent session runs. Each new call in a tool-calling loop typically resends everything the session has already produced, so the cached share of the prompt grows turn over turn while the fresh share stays roughly flat (just the newest message or tool result). A session that starts with a small cached fraction on turn one ends up mostly cached by turn ten, and the counted-token bill tracks that shift down even as the raw token count keeps climbing. RAG Inference Cost Calculator works through a parallel version of this same fresh-vs-retrieved-context split for retrieval pipelines, if your workload leans more RAG than agent loop.

Counted Tokens vs Raw Tokens: Why Your Router Bill and Your Plan Bill Differ

A per-token router bills every token at the provider's list rate, with no built-in weighting for how cheap or expensive that token actually was to serve. A counted-token plan bills a weighted sum instead. The two numbers on the same request can differ sharply, and it's worth knowing exactly where.

OpenRouter is the clearest comparison because its own pricing page states the principle directly: "Inference is billed at the provider's list price on every plan." OpenRouter doesn't mark up the per-token rate itself. Those are OpenRouter's own published rates as of 1 Nov 2026 and can change; check its pricing page for the current figures before you plan around them. LLM API Pricing 2026 breaks down what those underlying per-token rates look like across GPT, Claude, Gemini, and DeepSeek if you want the raw numbers each provider sets.

Caching on a per-token router is real, but it isn't a fixed weight. OpenRouter's usage accounting returns cached tokens (read) and cache write tokens as separate fields on every API response, counted with each model's own native tokenizer, so you can see exactly how much of a request hit a cache. What it doesn't document is a single, guaranteed discount multiplier for those cached tokens across models. Whatever discount you get on a cached token through a router comes from the underlying model provider's own cache-pricing policy, not a promise from the router itself, and it varies by provider and model rather than landing on one number you can plan around. A counted-token plan fixes that number in the contract: 0.25x (0.03x on DeepSeek V4.1 Flash) applies the same way on every call, for the life of the term.

There's a separate axis worth knowing if you're routing through someone else's infrastructure today: OpenRouter's BYOK tiers waive its fee entirely on the first $25,000 of list-price inference a month, charging 5% only above that threshold, figures OpenRouter published as of 1 Nov 2026 and worth rechecking before you plan around them, which changes the math for teams already holding direct contracts with a model provider. That's a genuinely different trade than a counted-token plan: a router (OpenRouter among them, alongside Fireworks AI alternatives like Together and DeepInfra) gives you one API across many models with no term commitment, which a single-provider fixed-price plan with three models and a contract term doesn't match for a team that needs broad model coverage or genuinely unpredictable, low-volume traffic. Cost Per Million Tokens has the general formula for turning a GPU-hour rate into a raw per-token cost, which is the number a fixed-price plan replaces for workloads that fit its three-model catalog.

What Happens When You Go Over Your Monthly Allowance

Going over the allowance doesn't stop requests. Counted tokens past a plan's monthly limit are billed at the plan's own rate on the next invoice, so a traffic spike keeps getting served instead of failing mid-session. The other side of that same mechanic is less forgiving: unused tokens expire at the end of each plan month. There's no rollover, so a plan sized well above real usage is paying for headroom that resets to zero every month rather than banking it.

That makes sizing the plan the actual decision, not just picking a tier.

A fixed-price plan is the wrong call for some traffic, worth saying plainly. If your volume is low or genuinely unpredictable month to month, a prepaid allowance that expires unused is a worse deal than paying per token as you go. And if your stack needs GPT, Claude, Gemini, or a wide multi-vendor catalog rather than GLM-5.3, GLM-5.3-Flash, or DeepSeek V4.1 Flash, a router stays the better fit regardless of how the weighting math works out.

If your agent traffic already runs mostly on cached context, a token weighting inference plan prices that pattern the way it actually costs to serve, instead of charging agent-call volume at a flat per-token rate.

Request a managed inference plan on Spheron →