Multi-Model Token Cost Testing: A Strategy for Pairing Expensive Reasoning with Cheap Execution

In LLM application development, cost control often becomes a bottleneck before model capability does. This is especially true once your application enters batch inference, autonomous agent loops, code generation, or long-document processing scenarios, where token consumption can rise sharply. Unit prices between models can differ by a factor of tens or even hundreds. Without a clear scheduling strategy, it is easy to end up in a situation where the feature works—and the bill runs away.

This article is based on my actual usage records. I reverse-engineered the token consumption rates of several common model tiers through regression fitting, and from that derived a practical multi-model collaboration strategy: high-cost models handle the thinking, low-cost models handle the execution. Note that the data here comes from personal measurement and reverse-engineering—it is not an official price list, and pricing rules may change over time. The core value of this article is the analytical approach and the scheduling method, not a fixed price reference.

1. Why Token Consumption Rates Matter

In pay-as-you-go LLM services, cost is typically determined by three dimensions:

1. Input tokens: all context sent to the model, including system prompts, conversation history, retrieved documents, code snippets, and so on.
2. Output tokens: the content the model generates in response.
3. Cache hits: when the input shares a repeated prefix with recent requests, some services offer a cache discount.

Many developers roughly compare only the headline “price per million tokens” when evaluating model costs, overlooking two key details:

• Input and output prices differ dramatically. For some models, the output price is more than 5x the input price; for certain reasoning-oriented models, it can exceed 10x.
• A cache hit can cut costs by an order of magnitude. In long conversations or templated request scenarios, the cache hit rate affects the final bill far more than most people expect.

Judging by “is this model expensive or not” alone is therefore not enough. A more sensible approach is to compute a blended cost based on your own request structure.

Consider a typical agent scenario: the model reads an 8,000-token system prompt and a 5,000-token tool description, then receives the user’s question and generates a 500-token action instruction. If that 13,000-token fixed prefix consistently hits the cache, the effective input cost per call may be only 2%–5% of the original. If the cache misses, the full cost applies. This gap gets amplified dramatically in batch workloads.

2. Measured Results: Consumption Differences Across Model Tiers

To quantify actual costs, I exported my call records over a period of time and ran a regression fit on four fields: input tokens, output tokens, cache-hit tokens, and the credits actually deducted. The goal was to reverse-engineer each model’s input price, output price, and cached-input price from the credit consumption.

The fit showed residuals near zero and an R² of 1.0, meaning that under the billing rules at the time, a linear model could explain actual consumption almost perfectly. The reverse-engineered consumption rates per million tokens (in credits):

Model tier	Input (/1M)	Output (/1M)	Cached input (/1M)
High-tier reasoning model A	80,000	400,000	—
Mid-tier reasoning model B	32,000	112,000	—
General execution model C	4,000	8,000	80
Lightweight execution model D	2,000	2,000	—

Note: Model names are replaced with letters to avoid pointing to any specific vendor. The data is reverse-engineered from personal usage and does not represent official pricing.

Several key observations follow from the table:

First, output costs far exceed input costs. For model A, the output price is 5x the input price. A 2,000-token output costs as much as 10,000 tokens of input. In applications with heavy generative output—code completion, report writing, conversation generation—the output side quickly becomes the dominant expense.

Second, the gap between model tiers is measured in orders of magnitude. Model A’s output price is 200x model D’s output price, and its input price is 40x higher. Even models C and D, both in the “execution tier,” differ by 2x on input and 4x on output.

Third, the value of cache hits is especially pronounced for model C. The cached input price is only 2% of the normal input price. If the fixed prefix accounts for a large share of each request, choosing a model that supports caching with a sufficiently low cache price may be more effective than simply switching to a cheaper model.

3. Converting Costs to a Real Usage Quota

Unit prices alone cannot guide decisions—they need to be placed in the context of a concrete usage allowance. Suppose a developer has a quota of 60,000 credits per 5-hour window and 600,000 credits per week, and assume a request structure of 80% input tokens + 20% output tokens, ignoring cache benefits for now. The total token volume each model can process per 5-hour window is roughly:

• Model A: ~417,000 tokens
• Model B: ~1,250,000 tokens
• Model C: ~12,500,000 tokens
• Model D: ~30,000,000 tokens

This reveals a harsh reality: the gap in processing volume between model A and model D exceeds 70x. If a developer routes every task to model A, the quota burns extremely fast, and large numbers of simple tasks consume resources that should be reserved for complex reasoning.

It is worth emphasizing that this “total token volume” is a weighted sum of input and output, not raw throughput. A lightweight model may trail a high-tier model in output quality, but for formatting, entity extraction, preprocessing, and classification, its capability may be sufficient. The question is not “which model is the strongest,” but “which model is just good enough.”

4. Hybrid Scheduling: Let Expensive Models Think, Cheap Models Execute

Given this cost structure, a natural strategy is tiered routing. I divide my tasks into four tiers, each mapped to a different capability and cost band:

Tier 1: Planning and final review — high-tier reasoning models

High-tier reasoning models are suited to tasks that require a global perspective, such as:

• Decomposing vague user requirements into executable steps;
• Evaluating the risks and benefits of candidate solutions;
• Performing final quality review of execution results;
• Handling reasoning that requires complex logic chains or long-range dependencies.

These calls are relatively infrequent, but each carries a large context and requires output with some depth. Concentrating them on a high-cost model keeps total call counts under control while ensuring quality at critical nodes.

Tier 2: Complex reasoning — mid-tier reasoning models

Some tasks demand strong reasoning but not top-tier planning capability, for example:

• Code logic review and edge-case analysis;
• Intermediate steps of multi-step mathematical derivation;
• Anomaly pattern recognition in structured data;
• Tasks that require a moderate degree of contextual understanding.

Mid-tier models typically cost about 60% less on input and more than 70% less on output than high-tier models. Routing tasks that are “challenging but don’t need top-tier reasoning” to this tier strikes a good balance between quality and cost.

Tier 3: Main execution — general execution models

In agent workflows, a large share of calls do not need deep reasoning; they execute explicit instructions, such as:

• Formatting parameters before tool calls;
• Converting natural language into JSON or function-call formats;
• Extracting specified fields from long text;
• Generating standardized reply templates.

General execution models typically cost only about 5% of a high-tier model’s input price and 2%–5% of its output price. Even with significantly more calls, overall costs remain low. More importantly, if such a model supports cache hits, fixed prefixes like system prompts and tool descriptions can be reused at minimal cost.

Tier 4: Bulk simple tasks — lightweight execution models

For large-scale simple processing—format cleanup, classification labels, keyword extraction, sample preprocessing—a lightweight execution model is the more economical choice. Its input and output prices are identical and the lowest in absolute terms. At this tier, even processing tens of millions of tokens costs only a fraction of what a high-tier model would charge.

Tiered routing can be expressed in the following pseudocode:

def route_task(task):
    if task.requires_planning():
        return model_high.generate(task)
    elif task.requires_complex_reasoning():
        return model_mid.generate(task)
    elif task.is_execution_heavy():
        return model_exec.generate(task)
    else:
        return model_lite.generate(task)

On top of this, add cache optimization:

def build_request(task):
    prompt = system_template + tool_schema + task.context
    # Keep the fixed prefix stable to improve the cache hit rate
    return prompt

The core idea of both examples: match task complexity to model capability. Do not call above the tier you need, and do not give high-cost models low-value work.

5. Further Cost-Reduction Practices

Beyond tiered scheduling, several general cost optimizations are worth combining.

First, compress the input context. Input tokens are a fixed overhead on every call. Trimming the system prompt, dropping redundant history, extracting key passages, and splitting long documents for on-demand retrieval all reduce input-side costs. Even with a cheap model, less input means less absolute spend.

Second, raise the cache hit rate. Cache hits require a stable request prefix. In agent scenarios, placing the system prompt and tool descriptions at a fixed position and avoiding dynamic content in the prefix can significantly improve hit probability. For frequently called tasks, caching gains may be more pronounced than those from switching models.

Third, optimize output length. Explicitly requiring the model to “return only the necessary fields,” “use a compact format,” or “do not repeat the question content” in the prompt reduces wasted output. For batch generation tasks, compressing output length translates directly into cost savings.

Fourth, establish cost monitoring. After every call, log the model type, input tokens, output tokens, cache-hit tokens, and actual cost, then aggregate and analyze the data regularly. Only by making costs observable can you verify whether your scheduling strategy actually works, rather than tuning by feel.

6. Conclusion

The most important finding of this exercise can be summarized in one sentence: the token cost differences between models are far larger than most developers intuitively assume. When the output price of a high-tier model is 200x that of a lightweight model, any “use the most capable model for everything” strategy is unsustainable.

The sensible approach is a tiered scheduling mechanism based on task complexity. Let expensive models play their irreplaceable role in planning, complex reasoning, and final review, and let cheap models take on high-frequency, repetitive, formatted execution work. Combine this with cache optimization, input compression, and output constraints to keep pushing costs down within each tier.

The end goal is not “use the cheapest model,” nor “use the strongest model,” but give each class of task exactly the capability it needs and pay a fair price for that capability. This approach is vendor-agnostic and applies to any development scenario with multi-model access and pay-as-you-go billing. Pricing rules will change and models will iterate, but the principles of tiered scheduling and cost observability will remain effective for a long time.