OpenRouter with OpenClaw

OpenRouter has hundreds of models. That sounds nice until you need to pick one.

Prices move around. Model names keep mutating (they may have a date in their name) and benchmark numbers live on random sites that look like they were built by an AI promoting itself. After a while you stop comparing and start guessing.

I wanted a better answer than "this one feels good today." So I used OpenClaw, my local assistant, to query OpenRouter's API, pull pricing and context windows, check coding benchmarks, and reorder my fallback chain.

That turned out to be a much better use of an AI assistant than asking it for one more confident opinion about the "best" model.

The problem

You have to be really careful with OpenClaw, its very useful, but you can lose your shirt if its misconfigured and decides to use a service with your creditcard number in hand.

Picking a model on OpenRouter is annoying for a simple reason. You are comparing three different things at once:

1. price
2. coding quality
3. context size

If you optimize for only one of them, you get useless or painful results.

The cheapest model is often cheap for a reason. The smartest model may cost enough to make you wince every time it decides to 'refactor' something. The giant context model looks impressive until it writes code like you would with deadline and a head injury at the same time.

I wanted a fallback list that matched how I actually use these tools: mostly coding, occasional large-context work, and a strong preference for not setting money on fire. I don't use openclaw constantly, just occasionally, so a smart model is more important than a fast one. Cheap is always good though.

What I actually did

OpenClaw can hit APIs, parse JSON, and edit config files. So I had it do the boring part.

First it pulled the full model list from OpenRouter:

curl -s "https://openrouter.ai/api/v1/models"

That response includes the fields that matter here: prompt price, completion price, and context length.

Then I filtered it with a short Python script. Nothing fancy:

import json
data = json.load(sys.stdin)
for m in data['data']:
    if 'glm' in m['id'].lower():
        print(f"{m['id']}: ${float(m['pricing']['prompt'])*1e6:.2f}/M input")

After that I had OpenClaw sort newer models by input cost and turn the result into a table.

Cheap is easy to find. Cheap and good is the annoying part.

So the next step was benchmarks. I had OpenClaw pull SWE-bench results and line them up against pricing.

That is where things got useful. MiniMax M2.5 stood out fast. It costs $0.27 per million input tokens and scores 80.2% on SWE-bench Verified. That is a very stupidly good trade if your main job is throwing code at a model and hoping it behaves.

The fallback chain I ended up with

My config stores a primary model plus fallbacks:

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "openrouter/z-ai/glm-5",
        "fallbacks": [
          "openrouter/deepseek/deepseek-v3.2-exp",
          "openrouter/moonshotai/kimi-k2.5",
          "openrouter/minimax/minimax-m2.5"
        ]
      }
    }
  }
}

I had OpenClaw reorder that list based on coding score, price, and context window.

1. GLM-5: 77.8% SWE-bench, $0.80/$2.56
2. DeepSeek V3.2: 73.0%, $0.25/$0.40
3. Kimi K2.5: 76.8%, $0.45/$2.20
4. MiniMax M2.5: 80.2%, $0.27/$0.95

The numbers are not perfectly clean because input and output pricing vary a lot, and benchmark reporting is messy. Still, this was enough to stop me from cargo-culting a model list from some Reddit comment written three weeks and seven model releases ago.

Why these models made the cut

GLM-5 stayed as the primary because it is strong enough to trust for normal coding work and still much cheaper than the top-end frontier stuff. Claude Opus 4.5 scores a bit higher, but paying around $5 per million input tokens for routine agent work is the software equivalent of commuting in a helicopter.

DeepSeek V3.2 is the cheaper fallback. It is not the model I want solving the mysteries of consciousness, but it is good enough for a lot of code generation and cleanup work, and the price is low enough that failure hurts less.

Kimi K2.5 earned a place mostly because of the larger context window. When the repo gets bigger, or the prompt gets swollen with too much context, that extra room matters.

MiniMax M2.5 is the one that made me rewrite the list. The price is low, the benchmark score is high, and it looks underpriced relative to the field. That usually means one of two things: either you found a great deal, or the market has not caught up yet.

Speed is nice but I care more about code quality

I also looked at Mercury 2 because it is absurdly fast. It can spit out over 1,000 tokens per second using diffusion instead of normal autoregressive decoding.

That sounds great until you remember that fast wrong answers are still wrong answers. For coding, I care more about whether the patch works than whether it arrives at Formula 1 speed.

So Mercury 2 stayed out of the main coding chain. I would use it for summarization, extraction, or bulk text work. I would not trust it with repo surgery unless I was in a reckless mood.

A few things that can still mess this up

Benchmark numbers are not clean truth. A lot of them are self-reported, and independent tests often come in much lower. So I treat SWE-bench as a rough filter, not holy scripture.

Context limits also matter more than people admit. A cheap model with a tiny context window becomes expensive the second it starts dropping half your prompt on the floor.

And model catalogs change constantly. OpenRouter removes things. Vendors rename things. A config that looked smart last month can age like supermarket sushi.

If a stale config entry breaks startup, the fix is simple:

openclaw config set plugins.entries.stale-plugin null

Conclusion

Before this, my fallback list was basically inherited folklore. It had the usual smell of something copied from a forum post, lightly edited, then trusted for no good reason.

Now it is at least tied to real numbers. Price, context, coding benchmarks, done. Not perfect, but much better than vibes.

The obvious next step is automation. Run this weekly, re-rank the models, and update the config before the market shifts again. That is the kind of boring maintenance job AI is actually good at.