There is no "cheapest LLM API." Ask one provider which of its models is cheapest for your workload and it will name its entry tier; ask another and it will name a different one. "Cheapest" is a per-task question with a per-task answer, and this post is the table — a mid-2026 view of five task classes with what actually wins each one, plus the price dimensions that make the headline number lie.
The table, task by task
Classify / label / route. Cheap input rate plus the batch discount: these jobs are short prompts, structured output, and latency-tolerant — quality is measured nightly, not per keystroke, so a 24-hour batch SLA costs about half. The winner here is the provider whose batch discount is widest, not the one with the lowest headline line.
Long-input summarization. Input price dominates — the output is a small fraction of the input, so the model with the lowest input rate wins, regardless of its output price. Two second-order dimensions: the context tier, because a 200K-token document into a 128K-window model forces chunking or a tiered long-context price, so a model that looks cheaper on the sheet can be more expensive at the document length you actually use; and the cache, because re-summarizing a document family with a shared prefix turns the read rate into the real variable.
Customer-facing chat / assistant. Mid tier, cached stable prefix, mix-aware. The community's per-month cost breakdowns for this exact class are the closest thing to a public benchmark; the provider-agnostic way to read them is per-request cost at your input/output ratio, after the cached-system-prefix discount. This is the task where "cheapest" flips: at 3-5x output pricing, a thousand output tokens can cost as much as 3,000-5,000 input tokens, so a model that is cheaper on input and pricier on output loses the chat workload that tail on long answers.
Hard reasoning — planning, complex analysis, agentic steps. Scope-gate before model-pick. Most "hard" requests are hard because of the context around them — everything the task does not need was fetched in — and most of that is trimmable. Trim the context, split the step, and the mid tier covers a surprising share of what you were budgeting at the frontier. For the genuinely frontier-class remainder: budget the output rate (reasoning-heavy work is output-heavy) and treat reasoning tokens as a billed-but-opaque line — on the invoice as a count, not as a rate you can compute in advance.
Code generation / code review. Tier by scope, not by task: the frontier class for long-context whole-repo changes, the mid class for file-level work, and the cheap class for the triage — classification, lint routing, diff summarization — which is the high-volume, input-heavy part of the pipeline and should not be paying frontier rates. And because an agentic loop multiplies every rate by the step count, a model that is 2x cheaper per token but 3x more steps to converge is losing.
The hidden price dimensions behind the headline
- Output pricing: 3-5x the input on most tiers. Lowest-input-rate loses whenever the output share of your mix is anything but small.
- Context tiers: crossing the window boundary is not free. Some providers price long-context requests at a separate, higher rate; the 120K request is not 120x the 1K request in every case.
- Cache write vs read: reads run around 10% of input; writes around 1.25x. A task that keeps missing the cache can pay more than the uncached path does, in the write premium alone.
- Batch discount: roughly half price, 24-hour SLA, and not everywhere — some providers, some models.
- Reasoning tokens: billed, but the budget for them is opaque — they arrive as a usage count, not a rate line you can precompute.
- Markup: not a token rate at all — some gateways add a service percentage on top of provider pricing; pass-through endpoints add none. It is a column of the table, not a footnote: a 5% markup quietly re-prices every row.
How to read the real winner
For your top two or three task classes: fix the request shape (tokens in, tokens out, context length, cached or not), compute per-task dollars for three candidate models including the hidden columns, and shadow the cheapest one against the incumbent for two weeks on production traffic. The static table picks the candidates; the shadow log picks the winner. Every rate in the computation is in the model catalog.