Know your models.

The single biggest split — and the one the calculator runs on.

Scruuge uses tier labels to organize its calculator baseline. They are heuristic bands, not measured task accuracy. Whether a cheaper model is suitable depends on your acceptance criteria, failure costs, and review process. Test those before switching.

Read input and output rates separately.

Input and output tokens can have different prices. Multiply each rate by its own billed token count, then add cache writes, cache reads, and tool charges where applicable. A short prompt followed by a long answer can have a very different bill from a long document followed by a short extraction.

The rate matters. So does how much gets billed.

Tokenizers, reasoning, answer length, retries, and repeated context all affect billed usage. Compare cost per accepted result, including failed attempts and review time. Equal token counts are useful for an arithmetic illustration; they are not proof that two models finish the same work for the illustrated price.

Measure the wait your user actually experiences.

Time to first token and time to a complete result are different measures. Both can vary with provider, load, prompt length, and reasoning settings. Check latency on representative requests; a listed throughput figure does not establish response time for your application.

A capacity limit is not a promise of reliable recall.

The context window limits how much a request can contain. Verify input and output limits, long-prompt price thresholds, and whether the model finds the details your task needs. Sending more history adds billed input unless a documented cache discount applies; a larger advertised window alone does not establish better results.

Parameter counts do not tell you the API bill.

Dense and mixture-of-experts designs use computation differently. That matters when serving models yourself, alongside hardware, utilization, and operations. For a hosted API, use the provider's actual rates and billed usage. Neither total nor active parameter count establishes task quality or customer pricing.

Code and math ≠ creative ≠ judgment.

Evaluate the task you actually have: runnable code, accurate extracted fields, or a draft that meets your editorial requirements. Include difficult cases and the consequences of errors. Provider capability descriptions and external benchmarks can help choose candidates; they do not replace acceptance checks on your workload.