The cheapest LLM API in 2026, and whether it is good enough for your agent

As of October 26, 2026, the cheapest LLM API from a major provider is OpenAI's gpt-5-nano, at $0.05 per million input tokens and $0.40 per million output tokens. Among current-generation models, OpenAI's gpt-6-luna and Anthropic's Claude Haiku 5.5 tie at $0.10 input and $0.50 output, DeepSeek's deepseek-flash costs $0.15 input and $0.60 output off-peak (double that at peak), and Google's cheapest model open to new projects is gemini-3.1-flash-lite at $0.25 input and $1.50 output. If you drop the major-provider filter, aggregators list small niche models from $0.01 per million input tokens.

Whether the cheapest LLM is good enough for your agent is a separate question, and the price table cannot answer it. The only reliable answer is to replay your own production traffic against your current model and the cheap candidate and compare what the agent does: which tools it calls, with which arguments, and whether it still answers when it should. I ran exactly that on a migration that was 58.8% cheaper and 75.2% faster with zero failed calls, and the report still returned FAIL, because the cheaper model called the wrong tools on a quarter of the comparisons. Another migration, 71.2% cheaper, passed every budget. Price told me nothing about which one would be which.

The rest of this post is the price table, why list price is not what an agent actually costs, and the check to run before you switch.

## Cheapest LLM API prices, October 2026

Prices are per million tokens, standard (non-batch) tier, from each provider's own pricing page: OpenAI ↗, Anthropic ↗, Google Gemini API ↗ and DeepSeek ↗. The last column is what 1,000 agent calls cost at 3,000 input and 400 output tokens each, uncached, which is roughly one turn of a small tool-calling agent with its system prompt and tool definitions.

For scale, the same 1,000 calls cost $3.75 on gemini-3.8-flash, $5.00 on gpt-6.1-terra and $10.00 on Claude Sonnet 5.5. The cheapest tier is 10 to 30 times cheaper than the mid-tier models most agents are built on, which is why the question keeps coming up.

Outside the major providers, BenchLM's pricing table ↗ lists 198 paid models from 40 providers. Its cheapest entry is a 4B-parameter Perplexity model at $0.01 per million input tokens, and its cheapest model with a benchmark score is Qwen3.7 Flash at $0.03 input and $0.13 output. Those are real prices, but most of the very cheapest rows are small classifier-style models with no published score, not general agent models.

Two notes on the Google rows. gemini-2.5-flash-lite is the cheapest Gemini model on paper, but it retired on Vertex AI on October 20, 2026, and new Gemini API projects can't use it; the Gemini deprecation checklist has the dates. And several Gemini 3.x prices on Google's page are marked as introductory, valid until the end of 2026, so check the page before you budget a year out.

All three of OpenAI, Anthropic and Google take 50% off for batch requests. That matters for offline jobs and evals, and almost never for an agent, which has a user waiting on the other end.

## List price is not what your agent costs

An agent is not one call. It is a loop: the model reads the conversation, calls a tool, reads the result, and decides what to do next, and every turn resends the whole growing context. So for agents, input price usually matters more than output price, and four things move the real bill away from the list price:

• +Tokens per task, not per call. A cheaper model that takes two extra tool-call turns to finish a task, or retries a malformed call, can cost more per task than a pricier model that gets it right the first time.
• +Prompt caching. Your system prompt and tool definitions repeat on every turn. Cached input is $0.01 per million on gpt-6-luna and Haiku 5.5, and $0.003 off-peak on deepseek-flash. With a long, stable prefix, the cache discount can matter more than the headline price.
• +Price tiers inside one model. Haiku 5.5 is $0.10 input up to 100K-token prompts and $0.50 above. DeepSeek doubles during peak hours. An agent with long contexts, or traffic concentrated in one time zone, does not pay the number in the first row.
• +Reasoning tokens. Models that think before answering bill those tokens as output. Two models with the same price per token can differ several-fold in tokens per answer.

The only number worth comparing is measured cost on your traffic. In the run described below, the source model cost $0.1799 and the candidate $0.0741 for the same 16 calls, a 58.8% saving measured on real requests rather than read off a pricing page.

## Is the cheapest LLM good enough for your agent?

Sometimes. Here is a case where it was not.

I replayed 16 real examples from an agent against its current model and a cheaper candidate. On every number a finance review would check, the candidate won: 58.8% cheaper, 75.2% faster, and not one failed or truncated call. The EvalShift migration report returned FAIL.

Two budgets broke, and both were about behavior, not quality of prose:

• +Tool-selection divergence was 25% against a 10% limit. The cheaper model picked a different tool, or a tool where none was needed, on a quarter of the comparisons.
• +The equivalence rate fell to 61.4% against a required 75%. Fewer than two in three paired comparisons were judged to do the same job as the current model.

The failures were the kind that never show up in an error rate. Asked for an opinion on working late, the current model answered in two sentences; the cheaper one issued a search_web call and returned no text at all. In another example, the cheaper model told the user an action was done without ever calling the tool that does it. In a third, it routed the request to a different tool.

Every one of those calls succeeded at the API level. A dashboard tracking latency, cost and error rate would have shown the migration as a clean win. The full breakdown, with the per-evaluator results and the diffs, is in the new model was 59% cheaper and 75% faster, and I still wouldn't ship it.

### And when the cheap model is good enough

The opposite result is just as real. A customer-support agent with six tools moved from gemini-3.7-pro to gemini-3.7-flash, measured over 120 production examples: 71.2% cheaper, 61.9% faster, and all ten budgets held, including zero allowed regressions on the security slice and zero argument drift on refunds. That one shipped. The policy and the full report are in this one passed: 71% cheaper, and the agent still does the same thing.

The difference between the two was not the size of the discount. It was what each agent asked the model to do, and the only way to find that out was to run it.

## Where cheap models break in agents

The cheapest tier is usually fine at the parts of an agent that look like classification or extraction with a clear schema. The regressions I see cluster in the parts where the model has to decide something:

• +Whether to call a tool at all. Cheap models over-call (searching instead of answering) or under-call (answering from memory where a lookup was required).
• +Claiming an action without doing it. "I've updated your address" with no update_address call in the trace. This is the most expensive failure, because the text reads as a success.
• +Which tool. With several tools that overlap, the cheaper model picks a neighbor.
• +Arguments. An id copied with a typo, an enum value outside the allowed set, a date in the wrong format. The call succeeds and does the wrong thing.

None of these show up in a benchmark score, and most don't show up in a semantic-similarity score either, because the text around the mistake is fluent. They show up when you compare the tool-call trace of the old model and the new one on the same input. The guide to evaluating agent tool calls covers the checks for each of them.

## How to tell if the cheapest LLM is good enough for your agent

Six steps, and only the first one uses the price table.

## Step 1: shortlist by price, then stop looking at price

Pick two or three candidates from the table above that support the features the agent uses: tool calling, structured output, your context length. More candidates than that and the comparison turns into a benchmark exercise instead of a decision.

## Step 2: replay real traffic, not a demo set

Take 100 to 300 inputs from production, stratified by route or intent, so the rare but expensive paths are in the sample, and run them through the current model and each candidate. A golden suite built from production traffic is the reusable version of this, and how many eval cases you need covers the sizing.

## Step 3: write the limits down before the run

Maximum tool-selection divergence, minimum equivalence rate, and zero tolerance on routes that move money or touch security. Deciding after you have seen the numbers is how a bad migration gets approved, because a 58.8% saving makes almost any regression look acceptable in hindsight.

## Step 4: compare behavior, not just answers

Diff tool calls, arguments and structured fields per example, and read every example that regressed. An LLM judge helps on open-ended text, but know when to trust it, and don't let an averaged score stand in for the per-example diff.

## Step 5: measure cost per task on the same run

Use the cost both models actually incurred on your inputs, with your caching, not the list price. If the cheaper model needs more turns per task, this is where it shows.

## Step 6: decide per route

The cheapest model is often good enough for some routes and not others. Sending the easy routes to it and keeping the rest on the current model captures most of the saving without the failures.

## Doing this with EvalShift

This is the workflow EvalShift automates. It replays a frozen suite against the current and candidate model, scores every pair with tool-call, structural, semantic and judge evaluators, checks the result against the budgets you wrote, and produces a pass or fail verdict with the per-example diffs and the measured cost beside it. It runs locally and writes a single HTML report. The step-by-step migration test guide shows the whole flow, and getting started has the install.

The cheapest LLM API is a fact you can look up. Whether it is good enough for your agent is a fact you can only measure.

## FAQ

What is the cheapest LLM API? As of October 26, 2026, the cheapest from a major provider is OpenAI's gpt-5-nano at $0.05 per million input tokens and $0.40 per million output tokens. The cheapest current-generation models are OpenAI's gpt-6-luna and Anthropic's Claude Haiku 5.5, both $0.10 input and $0.50 output. Aggregators list small niche models from $0.01 per million input tokens.

What is the cheapest Gemini API model? On paper gemini-2.5-flash-lite, at $0.10 input and $0.40 output, but it retired on Vertex AI on October 20, 2026 and the Gemini API serves it only to projects that already used it. For new projects the cheapest is gemini-3.1-flash-lite at $0.25 input and $1.50 output.

Is the cheapest LLM good enough for an AI agent? Sometimes, and only a replay of your own traffic can tell. One swap that was 58.8% cheaper and 75.2% faster with no failed calls still failed, because the cheaper model chose a different tool on 25% of comparisons and claimed actions it never performed. Another swap, 71.2% cheaper, passed every budget.

Why can a cheaper model end up costing more per task? An agent pays per task, not per call. A model that needs extra tool-call turns, retries malformed calls, or spends more reasoning tokens can cost more per completed task than a pricier model, and long prompts or peak hours can move it onto a higher price tier.

Where do cheap LLMs usually fail in agents? In decisions rather than prose: calling a tool where the previous model answered directly or skipping a required lookup, reporting an action as done without calling its tool, picking a neighboring tool, and passing malformed arguments. All of these can return fluent text and a successful API response.

## Keep reading

• +The new model was 59% cheaper and 75% faster. I still wouldn't ship it. — the full failing report, evaluator by evaluator.
• +This one passed: 71% cheaper, and the agent still does the same thing — the policy and report from a cheap swap that held.
• +What actually breaks when you switch LLMs — why the worst regressions from a model swap read as correct.