The useful way to compare OpenRouter models by price is to filter for the capabilities your coding workflow requires first, then compare live input and output prices, context, speed, and the cost of completing an accepted task. Sorting every model from cheapest to most expensive is a starting point, not a coding-model ranking.
That distinction matters because a Coding Agent is more than a model call. The model may need to inspect files, propose tool calls, produce patches, read test output, recover from errors, and repeat the loop. A cheap request that fails twice can cost more than a higher-priced request that passes the same acceptance check once.
OpenRouter makes the raw comparison easier through its Models page and Models API. The harder part is choosing the right comparison method. It also helps to understand the difference between a model and an agent harness: OpenRouter supplies model and provider access, while a harness organizes the multi-step coding workflow around those calls.
What does “OpenRouter models by price” actually mean?
OpenRouter lists models with separate pricing fields and operational metadata. Its Models API can sort results with pricing-low-to-high, but the official documentation says that sort is based on a weighted average of prompt, completion, request, and web-search pricing. It is useful for discovery; it is not a guarantee that the first result will be cheapest for your exact traffic pattern.
Several variables can change the bill:
- Input versus output mix. Repository context can make input dominant, while long plans, patches, and reasoning can make output dominant.
- Tokenization. OpenRouter notes that models tokenize the same text differently, so identical source files can produce different token counts.
- Non-token charges. Some models or features can include per-request, image, reasoning, or web-search charges.
- Provider endpoint. A model can be served by multiple providers with different price, latency, throughput, data-policy, or parameter support.
- Retries. Rate limits, invalid tool calls, failed patches, and test failures can turn one logical task into several paid requests.
OpenRouter says it passes through underlying model inference pricing and displays the details on each model page. Its FAQ also distinguishes inference pricing from fees charged when purchasing credits. Check both the current model page and current account pricing before estimating a budget.
Filter for coding requirements before sorting by price
The cheapest model is irrelevant if it cannot satisfy the request contract. For a tool-using coding workflow, begin with hard requirements.
Tool calling
OpenRouter lets you filter the Models API with supported_parameters=tools. Its tool-calling documentation explains that the model proposes a function call; the caller executes that function and returns the result. Support for tools therefore establishes an integration capability, not proof that the model will edit a repository reliably.
Also check whether your workflow depends on tool_choice, structured output, reasoning controls, or another parameter. Model-level support and provider-level support are related but not identical. If a request must preserve every parameter, the provider-routing configuration needs to enforce that requirement.
Context and input types
Context capacity affects how much code, documentation, tool output, and session history can be sent in one request. Bigger is not automatically better: unnecessary context raises cost and can add noise. Treat context as a constraint tied to your repository strategy, not as a quality score.
If the workflow includes screenshots, diagrams, PDFs, or other files, filter for the required input modalities too. A text-only model should not remain in a visual debugging shortlist simply because its token price is lower.
Availability and policy requirements
Production workloads may require a specific region, zero data retention, a provider allowlist, or a quantization policy. Those constraints can remove otherwise attractive endpoints. Apply them before comparing cost so the shortlist represents routes you can actually use.
Build a live shortlist with the Models page or API
For a manual check, open the Models page and apply the relevant filters for tool calling, modality, context, price, and model family. For a repeatable workflow, query the Models API instead of copying a static table into a spreadsheet.
A useful starting request is:
The official schema exposes fields such as model ID, context length, pricing, supported parameters, per-request limits, and top-provider information. OpenRouter also supports sorting by p50 throughput and p50 latency. Because model and provider data change, retrieve a fresh snapshot when making a decision and record the time of the snapshot.
Do not collapse the response into one score. Keep at least these columns:
The API’s price sort is an efficient first pass. The shortlist becomes meaningful only after you weight those fields according to a real workload.
Compare the cost of an accepted coding task
For an Agent workflow, the most useful unit is not cost per request. It is cost per accepted task: the total expense required to produce a result that passes the same tests and review rules.
A simple measurement is:
Track human review time separately. It is not an API charge, but it often dominates the economics of a failed or overly verbose run.
Use the same task, repository state, harness configuration, tool schema, timeout, and acceptance command for every candidate. Then record:
Run more than one task before drawing a conclusion. A single easy prompt can hide reliability problems, while one unusual failure can unfairly penalize a capable model.
Match the comparison to the coding workload
Different tasks reward different price and performance profiles.
Repository questions and triage
Short questions, file discovery, and issue classification often benefit from low latency and restrained output. A lower-priced, tool-capable model may be sufficient if it consistently selects the right files and returns a verifiable answer.
Edit, test, and repair loops
Implementation work places more weight on tool-call reliability, instruction following, and recovery from test failures. Output cost and throughput matter because patches, logs, and repeated reasoning can be large. The cheapest token price can lose its advantage if the model repeatedly invokes the wrong tool or produces edits that fail validation.
Planning and high-risk changes
Architecture work, migrations, and changes with a large blast radius may justify a more capable candidate or a staged workflow: one model plans, another executes, and deterministic tests arbitrate. Compare the cost of the whole sequence rather than assigning the planner’s price to the entire task.
This is also why a current model release such as GLM-5.3-Flash should be evaluated by workflow fit, not price alone. A low published rate can justify testing, but it cannot replace compatibility and acceptance checks.
Price sorting and provider routing solve different problems
Model selection answers, “Which model should handle this task?” Provider selection answers, “Which endpoint should serve that model request?” OpenRouter can expose the same model through multiple providers and route among them.
That routing can affect cost, latency, throughput, parameter support, and uptime. Before locking a budget, read how OpenRouter chooses a provider. If you leave routing at its defaults, the endpoint that serves a request may not be the one you assumed from a single model-card price.
Auto-selection is another separate choice. The Auto Router and Free Models Router do not mean the same thing: one chooses among eligible models according to its routing logic and can incur the chosen model’s price; the other stays within available free models.
None of these layers replaces a Coding Agent harness. The harness still owns repository access, tool execution, session state, approvals, retries, and verification. A useful comparison keeps model, provider, and harness variables visible instead of attributing the whole result to one layer. For the product-level distinction between routing access and a hosted coding workspace, see OpenRouter vs Agent.Space.
A practical OpenRouter coding-model decision process
Use this sequence to keep the comparison small and reproducible:
- Define one coding task and its acceptance command.
- List non-negotiable capabilities: tools, context, modality, structured output, data policy, or region.
- Query the current Models page or API and remove ineligible models.
- Sort the remaining candidates by price, then inspect input and output prices separately.
- Compare current throughput, latency, and eligible providers.
- Test two or three candidates with the same harness configuration.
- Record full-loop cost, retries, wall-clock time, tool errors, and acceptance.
- Keep a model only if its result is repeatable enough for the task class.
The result may be a small routing policy rather than one universal winner. A fast, economical model can handle triage; a different model can handle difficult edits; another can review high-risk changes. The right split is the one your own acceptance data supports.
Frequently asked questions
What is the cheapest OpenRouter model for coding?
There is no durable answer because model availability and prices change, and the cheapest listed model may not support the tools or reliability your workflow requires. Use the live Models API with supported_parameters=tools and sort=pricing-low-to-high, then test the eligible shortlist.
Does OpenRouter add a markup to model token prices?
OpenRouter’s current FAQ says it passes through underlying provider inference pricing. It separately charges fees when users purchase credits, so total account cost is not identical to looking only at token rates. Recheck the current Pricing and FAQ pages before budgeting.
Is the fastest model always the cheapest overall?
No. Throughput and latency affect time, while price and token usage affect API spend. Reliability, retries, and human correction determine whether a fast request becomes an accepted task.
Can OpenRouter replace a Coding Agent?
OpenRouter provides model access and routing. An Agent harness manages the multi-step workflow around models and tools. They can be used together, but they solve different layers of the problem.
Conclusion
OpenRouter’s live price sorting is useful when it begins a comparison, not when it ends one. Filter for the coding contract first, inspect the current model and provider data, and compare complete accepted tasks under one harness setup.
Start with a small repository task that has deterministic tests. Run the same task across a short tool-capable shortlist, then keep the model and routing policy that produces the best repeatable balance of cost, speed, and accepted results for that workload.