Cheap Model, Big Prompt: When the 1.3x Rule Makes a Budget Backend Cost More Than a Premium One

When you call models through an aggregator that charges official price × 1.3, the sticker price per token is only part of the story. The total cost of a request depends on three factors: the model's input price, its output price, and how many tokens you actually send and receive. Change the prompt size or the output length, and the cheapest-looking model can become the most expensive.

The cost formula

For any request, the cost is:

cost = (input_tokens × input_price + output_tokens × output_price) × 1.3

The 1.3 multiplier applies uniformly, so it doesn't change the ranking between models for a given request shape. What changes the ranking is the ratio of input to output tokens and the absolute token counts.

Worked example: long input, short output

Suppose you have two models:

• Model A: cheap input price, expensive output price.
• Model B: higher input price, lower output price.

For a request with a very long prompt (say, a full document) and a short answer, Model A's low input price dominates. The total cost is mostly inputtokens × inputprice_A. Model B's higher input price makes it more expensive, even though its output price is lower.

But now increase the output length. As output_tokens grows, Model A's expensive output price starts to dominate. At some point, Model B becomes cheaper overall. The crossover point depends on the exact prices and the input/output ratio.

Worked example: short input, verbose output

Now consider the reverse: a short prompt but a request that produces a long output (e.g., generating a report or code). Model A's cheap input price matters little because input_tokens is small. Model A's expensive output price makes it costly. Model B, with its lower output price, wins despite higher input pricing.

This is why you can't pick a model by input price alone—or by output price alone.

The multiplier doesn't change relative rankings, but it amplifies absolute differences

Because the 1.3x multiplier applies to all models equally, it doesn't alter which model is cheaper for a given request shape. However, it does mean that the absolute cost difference between two models is 1.3 times larger than at official prices. So choosing the wrong model for your workload costs you more than you might expect.

How to evaluate total cost

Instead of comparing sticker prices, estimate the total cost for your typical request shape:

• Measure or estimate average input tokens and output tokens per request.
• For each candidate model, compute (inputtokens × inputprice + outputtokens × outputprice) × 1.3.
• Compare those totals, not the per-token prices.

Also consider that output tokens are often more expensive than input tokens, so controlling output length (e.g., with max_tokens or concise prompting) can have a bigger impact than switching models.

Practical tips

• Profile your real prompts and responses to get realistic token counts.
• If your prompts are long but outputs are short, prioritize models with low input prices.
• If your outputs are long, prioritize models with low output prices.
• Remember that the 1.3x multiplier applies to the total, so a model that looks 10% cheaper per token might not be 10% cheaper overall if the token mix differs.
• Use the aggregator's unified API to test multiple models with the same prompt and compare actual costs.

Conclusion

Picking a model by sticker price is a trap. With the 1.3x multiplier, the total cost depends on your specific input and output token counts. By evaluating cost with your real workload, you can avoid paying a premium for a budget backend that isn't actually cheaper.