How to reduce LLM costs without lowering your quality bar

Start with the whole task, not a token price

A lower price per token is a useful lead, not a decision. For recurring document extraction, the useful unit is the original document entering your system. That document may trigger several model calls, a failed attempt, another model, a source check and a correction by a person.

Record the current workflow before changing it. Retain the model identifier, prompts, inputs, outputs, quality checks, attempts, returned usage and latency. Keep the failed documents in the denominator. A timeout with an unknown charge is not a free attempt.

Use provider usage records when available. For example, OpenRouter documents token counts and cost information in its response usage object. Preserve the billing source alongside your calculation rather than presenting a token estimate as an independently verified invoice. OpenRouter usage accounting.

Use two cost denominators

Cost per original input describes the resources consumed by the workload. Cost per accepted result connects that consumption to the agreed output requirements. Both are useful, and neither proves the requirements are accurate.

Cost per input = total in-scope cost / original inputs
Cost per accepted result = total in-scope cost / accepted outputs

Include the costs of rejected attempts in both numerators. When no output is accepted, cost per accepted result is undefined. Report that explicitly. Also show critical errors, unresolved reviews and false accepts found by source review. A permissive checker can make accepted-result economics look better while the product gets worse.

Compare three options before adding infrastructure

A practical comparison worksheet

Option	Change to test	What to inspect
Current setup	The deployed prompt, model and execution policy	Existing errors, cost and correction effort
Model swap	A cheaper model with the same prompt and task	Which documents regress, not just the average pass rate
Workflow change	A specific split or other supported design change	Extra calls, merging errors, verification and fallback

Use the same evaluation examples and frozen requirements for every candidate. Give each experiment a specific hypothesis, such as whether a dedicated line-item step reduces omissions. Separate development examples used to tune prompts from held-out examples used for the final comparison.

Inspect actual outputs together with aggregate scores. If the model swap satisfies the requirements and has the best complete economics, choose it. Keeping the current setup is also a valid result when the improvement is too small or too uncertain.

A worked arithmetic example

The following numbers are hypothetical assumptions, not Keemlo measurements or provider prices. Consider 10,000 documents per month. Assume both options have separately met the agreed quality requirements, while the alternative needs more human review.

Hypothetical monthly cost before platform fees and overhead

Component	Current setup	Alternative
Extraction, including retries	$1,000	$300
Automated verification	$100	$200
Additional human review	$200	$500
Total	$1,300	$1,000

The review calculation assumes two minutes per reviewed document at $30 per hour, with review rates of 2% and 5%. Extraction alone looks $700 cheaper. Including verification and review reduces the difference to $300.

If the alternative adds $150 in monthly fees and overhead, the recurring benefit becomes $150 per month. If implementation costs $600 and the comparison costs $150, total upfront cost is $750. Simple payback is five months, and first-year net benefit is $1,050, assuming unchanged volume and performance.

Monthly net benefit = current monthly cost - alternative monthly cost
Upfront cost = implementation cost + experiment cost
Payback months = upfront cost / positive monthly net benefit

Do not count a completed human review both in verification charges and again as additional review labor. Keep every assumption visible. Unknown costs prevent a complete projection. Use the outcome cost calculator to explore the denominator, then add adoption costs before making a decision.

Check what the saving costs you

• Latency: inspect slow documents and fallback paths, not only the average.
• Quality: compare critical errors and source-level correctness, not only valid JSON.
• Review burden: measure time and frequency, including unresolved verification.
• Integration: record code changes, staging time, maintenance and rollback work.
• Evidence: retain sample size, document families and the limits of extrapolation.

Repeat the comparison when the model, prompt, source mix or quality requirements change. A useful improvement should survive that review; one favorable run is not a permanent guarantee.

Run a comparison you can inspect and reuse

Keemlo's local SDK prepares reviewed examples, compares a baseline, an unchanged-prompt model swap and an explicit split, then exports an approved configuration. The selected runtime records extraction attempts and can record a separately supplied verification method and its charges.

The SDK does not invent source truth for new documents or automatically deploy the winner. You provide the approved provider adapter and source-verification process. The offline quickstart uses authored outputs, so it tests the software path rather than demonstrating model savings.

Try the demo to inspect that path, or download the developer kit to prepare a private comparison. The next useful result is a change your engineer can run, evaluate and decide whether to keep.

Sources and further reading

• OpenRouter usage accounting

Keemlo team content, drafted and reviewed with AI assistance. Methods and product claims are checked against the linked sources and shipped software. About these guides.

PUT IT INTO PRACTICE

Inspect the trade-offs yourself.

Compare three approaches in the demo, inspect a rejected output and download a runnable configuration. The sample uses authored outputs, not measured model savings.

Try the demo ↗Test one workflow with us