OpenRouter Benchmarks
τ²-Bench Airline measures whether a model can do real agentic work: it plays an airline customer-service agent that must follow a policy manual, talk with a simulated customer, and call the right tools at the right time to search flights, change bookings, and issue refunds. There's no trivia component—a model only scores well by executing multi-step tasks correctly. We run it continuously against the same provider endpoints that serve OpenRouter traffic, so scores reflect the model and the provider serving it together: real-world performance rather than ideal-conditions numbers.
Last benchmark run Jul 11, 2026, 3:35 PM UTC
Models evaluated
58
Providers covered
47
Top-level rows use default routing where available; click a row to expand provider-pinned results.
| # | Model | Std dev | ||||
|---|---|---|---|---|---|---|
| 1 | Qwen: Qwen3.5-122B-A10B Pareto | 79.8% | ±3.5pp | $0.10 | 3.0m | 28.9k |
| 2 | Qwen: Qwen3.5 397B A17B Pareto | 78.3% | ±4.3pp | $0.082 | 49s | 11.3k |
| 3 | 78.0% | -- | $0.18 | 15s | 2.86k | |
| 4 | 78.0% | -- | $0.14 | 8s | 1.95k | |
| 5 | 76.9% | ±0.8pp | $0.10 | 40s | 8.57k | |
| 6 | Qwen: Qwen3.6 27B Pareto | 76.7% | ±2.5pp | $0.074 | 1.7m | 17.4k |
| 7 | Qwen: Qwen3.5-35B-A3B Pareto | 76.3% | ±5.3pp | $0.052 | 1.6m | 28.1k |
| 8 | Google: Gemma 4 31B Pareto | 76.1% | ±3.8pp | $0.012 | 49s | 5.85k |
| 9 | 76.0% | ±3.1pp | $0.044 | 25s | 5.24k | |
| 10 | 75.5% | ±3.6pp | $0.009 | 25s | 5.86k | |
| 11 | 75.2% | ±2.9pp | $0.046 | 39s | 4.69k | |
| 12 | 74.6% | ±5.4pp | $0.034 | 27s | 4.26k | |
| 13 | 74.0% | -- | $0.21 | 7s | 1.66k | |
| 14 | 74.0% | ±4.4pp | $0.025 | 1.5m | 11.6k | |
| 15 | 73.7% | ±3.8pp | $0.050 | 24s | 4.49k | |
| 16 | 73.4% | ±4.8pp | $0.028 | 27s | 4.02k | |
| 17 | 73.3% | ±3.0pp | $0.049 | 34s | 6.18k | |
| 18 | 73.1% | ±4.1pp | $0.021 | 46s | 6.14k | |
| 19 | 72.4% | ±2.2pp | $0.034 | 1.6m | 19.7k | |
| 20 | 71.6% | ±3.3pp | $0.026 | 34s | 4.35k | |
| 21 | 71.1% | ±4.9pp | $0.015 | 23s | 4.42k | |
| 22 | 70.4% | ±4.6pp | $0.015 | 23s | 3.8k | |
| 23 | 70.0% | ±5.7pp | $0.019 | 2.1m | 22.4k | |
| 24 | 69.7% | ±4.5pp | $0.048 | 1.9m | 5.61k | |
| 25 | 69.2% | ±5.1pp | $0.032 | 63s | 8.26k | |
| 26 | 69.0% | ±5.1pp | $0.052 | 2.4m | 8.32k | |
| 27 | Xiaomi: MiMo-V2.5 Pareto | 69.0% | ±1.0pp | $0.008 | 1.7m | 15.9k |
| 28 | 68.8% | ±9.8pp | $0.042 | 20s | 3.57k | |
| 29 | 68.8% | ±4.8pp | $0.014 | 24s | 4.58k | |
| 30 | 68.4% | ±3.9pp | $0.014 | 68s | 10.1k | |
| 31 | 68.0% | ±11.4pp | $0.031 | 29s | 4.48k | |
| 32 | Xiaomi: MiMo-V2-Flash Pareto | 67.2% | ±6.9pp | $0.005 | 19s | 3.94k |
| 33 | 66.8% | ±7.6pp | $0.025 | 25s | 5.84k | |
| 34 | 63.9% | ±4.9pp | $0.014 | 33s | 4.76k | |
| 35 | 61.8% | ±5.9pp | $0.011 | 38s | 8.9k | |
| 36 | 61.5% | ±4.6pp | $0.042 | 71s | 15.9k | |
| 37 | 60.0% | ±5.4pp | $0.008 | 45s | 7.25k | |
| 38 | 59.4% | ±3.5pp | $0.019 | 11s | 2.1k | |
| 39 | 59.1% | ±11.4pp | $0.060 | 78s | 9.08k | |
| 40 | 56.5% | ±6.4pp | $0.066 | 1.9m | 12.5k | |
| 41 | 55.1% | ±5.0pp | $0.10 | 27s | 2.35k | |
| 42 | 51.2% | ±2.9pp | $0.020 | 3.0m | 58.3k | |
| 43 | 51.0% | ±3.0pp | $0.017 | 1.9m | 36.5k | |
| 44 | 46.9% | ±5.0pp | $0.015 | 16s | 1.7k | |
| 45 | 46.8% | ±4.0pp | $0.011 | 8s | 1.71k | |
| 46 | 46.6% | ±5.6pp | $0.025 | 12s | 1.58k | |
| 47 | 43.7% | ±5.3pp | $0.013 | 29s | 8.31k | |
| 48 | 42.8% | ±4.8pp | $0.033 | 68s | 4.45k | |
| 49 | 40.4% | ±4.4pp | $0.027 | 15s | 1.61k | |
| 50 | 40.2% | ±2.5pp | $0.008 | 13s | 911 | |
| 51 | 40.0% | -- | $0.010 | 5s | 919 | |
| 52 | 37.3% | ±4.3pp | $0.012 | 14s | 1.88k | |
| 53 | 35.2% | ±7.5pp | $0.029 | 12s | 1.7k | |
| 54 | 33.6% | ±5.1pp | $0.017 | 19s | 2.23k | |
| 55 | 33.6% | ±15.8pp | $0.013 | 1.6m | 9.95k | |
| 56 | 33.0% | ±5.6pp | $0.006 | 29s | 1.71k | |
| 57 | 32.5% | ±2.9pp | $0.057 | 1.6m | 5.91k | |
| 58 | 17.8% | ±6.2pp | $0.019 | 49s | 2.49k |
It's a tool-calling benchmark that is hard to game. Grading depends on live tool-call trajectories rather than memorized answers, so it resists training-data leakage better than Q&A-style evals. It exercises every tool-calling failure mode (wrong arguments, skipped policy checks, giving up, hallucinated confirmations) at a relatively low cost per run. The relative scores also carry more signal than the absolute ones. The same model can score differently across providers, and those deltas are what Exacto routing uses to pick higher-accuracy endpoints.
Each task is a simulated airline support conversation with a scripted user, a toolbox (flight search, booking changes, refunds, loyalty policies), and a gold reference solution. A task passes only if the final database state and the messages to the user match the reference; partial credit is not awarded.
There is still headroom. Top models fail roughly one in five tasks, and the airline domain is the hardest τ²-Bench split. Accuracy differences here separate models that follow multi-step policies from ones that merely chat well.
The floor is high, though. Many tasks reward inaction. A refusal task with an empty gold action list passes for any agent that changes nothing. Even weak models score well above zero, so the meaningful spread sits at the top of the range.
The benchmark is public, so tasks may appear in training corpora. Contamination inflates scores less here than in Q&A-style evals, though, since a leaked task still has to be executed correctly, step by step, against a live database.
Scoring fidelity has limits. The checker verifies two things: the final database hash and exact substring matches in the agent's messages. Each task's natural-language assertions ("agent should refuse the cancellation") are metadata, and no judge model reads the transcript. So a savings calculation fails if the agent says "$23,552.50" when the checker greps for "23553".
The user simulator matters too. We pin it to gemini-2.5-flash so agent scores stay comparable, but the sim is itself an LLM with failure modes of its own. It can stop the conversation before the agent finishes, leak its hidden task instructions, or keep a stuck agent looping until the 200-step ceiling kills the run. Swapping the sim model shifts absolute scores, which is why cross-paper τ²-Bench numbers rarely line up exactly.
Every task ships a gold solution: a list of tool calls, strings the agent must say, and natural-language assertions. After the conversation ends, the checker replays the gold tool calls against a fresh database and compares hashes with the agent's final database. It then greps the agent's messages for each required string. The reward is the product of those two checks:
reward = db_match × communicate_met // each ∈ {0, 1}
db_match = hash(agent DB) == hash(gold DB)
communicate_met = every required string appears in an agent message
any run that hits MAX_STEPS instead of a clean stop scores 0 outrightThe rollouts below are from real runs, with gemini-2.5-flash as the user simulator throughout.
Task 17 · agent: openai/gpt-5.1
For reservation FQ8APE: add 3 checked bags, swap the passenger to Omar Rossi, and upgrade basic economy to economy, paying with a gift card.
The agent looked up the user, found the right reservation among several, confirmed the changes and payment method, then made all three writes: passenger swap, cabin upgrade, and bags. The final database hashes match the gold state and the run ends on USER_STOP, so reward is 1. This is what the eval is designed to measure: multi-step tool use under policy constraints, done correctly.
Scores aggregate all successful runs, weighted by task count, with a minimum of 45 graded tasks per model-provider pair. A model's headline score uses its default routing (not pinned to a provider) when one exists; otherwise it falls back to the median provider. The standard deviation is measured across runs for that representative result. Cost, time, and token figures are per-task averages from the same runs. Best value is the cheapest Pareto-optimal model within 5 points of the top score.
These are the same measurements that power Exacto routing. See the docs for how routing works, or browse all models to try one.