Financial Markets and Model Routers

A model router makes a forecast before every task: which LLM is most likely to finish this work at an acceptable cost?

It can compare price, latency, availability, policy, benchmarks, and demand. None tells it whether the form saved, the record appeared, the code passed, or the agent stayed within its allowed tools.

In rtrvr, the browser often supplies that evidence. If the router records cost and latency but not task completion, it cannot learn which LLM finished the work.

Financial markets suggest how to divide the job. Stock markets combine disclosures, audits, private research, and trading to set prices. Blockchains let parties share execution and settlement without one operator.

For model routing, that means centralizing the data needed for a fast choice, keeping private provider estimates local, and independently verifying task completion before changing the next route.

Model routers make three choices

Products described as model routers do not all make the same choice.

1. Model access. Who may use which models, and under what policy and budget? Rippling's AI Spend Console maps token spending to employees, teams, models, vendors, and business results. Its AI Gateway applies access and spending policies. Merge for Workforce lets companies approve models, MCPs, and skills by group.
2. Provider choice. Once a model has been chosen, where should it run? OpenRouter's provider routing compares price, throughput, latency, availability, tools, and data policy. LiteLLM and Portkey add load balancing, retries, fallbacks, and budgets.
3. Model selection. Which model should receive this task? RouteLLM predicts whether a stronger model will beat a cheaper one. OpenRouter's Auto Router uses the task type and seven days of aggregate spend, filtered by the requested cost-quality tradeoff. Its Pareto Code router groups coding models into benchmark tiers, then picks the cheapest available model or the fastest with Nitro.

Model access, provider choice, model selection

01Model access

Who can use which models?

policy + budget

02Provider choice

Where should it run?

price + runtime

03Model selection

Which model gets the task?

task + benchmark + demand

After selectionDid the task succeed?Use the result in the next route.

Access routing uses policy and budgets. Provider routing uses price and runtime. Model selection uses benchmarks, learned preferences, task type, or demand. These signals arrive before the task is done. The result brings new evidence.

Task spend measures demand, not task success

OpenRouter groups requests into tasks such as debugging, data extraction, and multi-step planning, then ranks models by share of spend within each category.

The category describes the prompt, not the result. Share of spend is closer to trading volume than an audited financial statement: it reveals demand. It does not say that Model A fixed the bug, passed the tests, or beat Model B on that repository.

The ranking is not a live task result. It uses a trailing seven-day window. OpenRouter's public task-classification and benchmark APIs expose sampled market shares and scores, not absolute task volume or success.

Anyone can copy the rough rule: classify the task, remove ineligible models, then take the cheapest or most popular candidate. They cannot copy OpenRouter's full traffic, live provider health, fallbacks, or a customer's constraints.

The product running the task sees what the wider market cannot. A coding tool knows whether the patch passed. A browser agent knows whether the page reached the required state. That evidence can correct a market-wide ranking for the next similar task.

Price and rankings cannot tell us whether the task worked

Investors do not know a company's exact value. They trade on earnings, research, risk, and expectations. When the price quickly absorbs available information, economists call the market informationally efficient.

The price is still an estimate, not an audited fact about the company. And information costs money to acquire. Grossman and Stiglitz showed that if the public price revealed every private fact for free, nobody would pay to find those facts.

Model routing divides information too. A ranking shows what users bought. A provider knows its load, retrieval coverage, or prompt confidence. The product knows which systems completed similar work. No party sees every signal, and some cost money.

Stock markets do not ask the price to do every job. Traders submit orders. Exchanges match them. Clearing agencies use netting to offset what each side owes, then settle the smaller balance. Auditors test financial statements. Disclosure rules and regulators make false claims costly. The SEC does not choose a stock for each investor, and an exchange does not let a seller audit itself.

DeFi calls this the oracle problem. A chain can record the settlement, but an oracle, test, or other verifier must report whether the browser task actually succeeded. Sharing that judgment through consensus adds delay, fees, and repeated work.

For model routing, efficiency has three parts:

1. Information. Do the estimates reflect benchmarks, market demand, provider knowledge, and results from similar work?
2. Allocation. Does the task go to the eligible system with the highest expected value after cost, latency, and risk?
3. Operation. Do routing, inspection, verification, and settlement cost less than the value they add?

A central router may see more traffic and make one cheap decision. A distributed design can keep provider information local and share settlement, but repeated checks cost more. Neither is efficient by default. Both need the task result.

Google DeepMind uses Pandora’s search for model routing

A Google DeepMind paper released in August 2026 studies the cost of evaluating models before routing. A quick score may already exist, but a better score can require retrieval, a fine-tuned evaluator, tool calls, or a short reasoning trace. The paper asks when that check is worth its cost.

The authors connect it to Martin Weitzman's Pandora's Box problem. Pandora pays to open boxes with hidden values, keeps the best value found, and stops when another inspection is not worth its cost. Companies make the same tradeoff with references, interviews, work samples, and vendor pilots.

Suppose a box costs $10 to open and contains $0 or $100 with equal probability. If the best option found is worth (u), only the $100 outcome improves it:

0.5 × (100 - u)

Set that equal to the $10 inspection cost. The answer is $80. With $79 in hand, open the box. With $81, stop.

$10 to inspect

Open at $79. Stop at $81.

Current best

$79

$79<$80

Inspect

Current best

$81

$81>$80

Stop

The general equation is E[(G - u)+] = c. A worse inspected value adds zero. The reservation value (u) is where expected improvement equals inspection cost (c).

It is not a sunk cost. Earlier inspection costs are gone; the next $10 is a marginal decision. The unopened box has option value because we can inspect it, reject a poor result, and keep our current best.

The secretary problem forces an irreversible accept-or-reject choice; Pandora can return to the best opened box. Deal or No Deal has banker offers and no per-box inspection cost, so it is only a loose analogy.

When should a router pay for a better estimate?

In the paper, each specialist is a box. The router starts with a cheap estimate (f) and may pay (c) for a better estimate (g). This is not the final answer or ground truth. It is a better prediction of the specialist's cost-adjusted value.

The paper tests several ways to obtain (g). A math evaluator sees the prompt plus the first 20 reasoning tokens. A retrieval evaluator sees documents from a specialist's private corpus. EmbedLLM uses a small fine-tuned prompt encoder to distinguish among more than 100 open-weight models. The cheap estimate (f) retrieves similar calibration examples with prompt embeddings.

Uncertainty can make inspection valuable because the router may reject a disappointing estimate and keep its current best. It does not make an erratic model better. An irreversible browser action still needs permission and verification.

The paper reports these results:

Lower is better: the measure adds inspection cost to value lost from a wrong choice. The two-model math result matches the margin rule at three decimals. Retrieval helps because documents reveal task-specific information. The large correlated model pool improves only slightly. Pandora inspects only when it may change the decision enough to cover its cost.

Similar benchmark scores can hide different task results

Routing is wasteful only when eligible systems have the same cost-adjusted outcome for this task and more evidence cannot repay its cost. Similar benchmark averages do not meet that test.

For a particular prompt, systems can still differ in price, latency, availability, tool use, private data, privacy policy, and reliability. The model is only one part of the system. The harness, retrieval, memory, tools, and inference budget also shape the result.

Efficient pricing may remove obvious bargains without making every system interchangeable. Some tasks will become commodities; there is no sound probability estimate for full market-wide convergence. Companies hire people with similar ability and buy similar CRMs, yet process, context, incentives, integration, and execution still produce different results.

The paper then moves the costly estimate to the model

The paper next changes who pays to learn more. In Pandora's Router, one central system decides which refined estimates to buy. In Pandora's Bidder, a specialist can use private information such as retrieval results or an early reasoning trace to decide whether refining its own estimate is worthwhile.

For each prompt:

1. The other (M - 1) specialists provide their refined value estimates.
2. The platform publishes the highest estimate as the score to beat.
3. One strategic specialist accepts, declines, or pays to refine its own estimate.
4. It claims the task only if its estimate clears the posted score.

Bid here means deciding whether to claim the task against a value threshold. It is not an API-price quote or a promise to stay within a token budget.

The (M - 1) specialists are fixed competitors. Researchers rotate the strategic role to evaluate each model under the same setup. This is an evaluation method, not production randomization.

A posted score that is too high can drive a capable model away. One that is too low can let the strategic model win when another was better. The paper does not solve lying, collusion, an all-strategic market, or poor work after allocation. Production needs those rules and an outcome check.

Use task outcomes in the next route

The paper stops at allocation. Production must still run the task, judge the result, and learn from it. Cheap estimates can form a shortlist; Pandora's rule is useful only for close or uncertain choices. Otherwise selection may cost more than the task.

The task then moves through five steps:

1. A task contract states the outcome, budget, deadline, allowed data and tools, and success check.
2. Public rankings and benchmarks provide a starting estimate. Providers add predicted success, expected execution cost, model version, and the cost of refining their estimate.
3. The allocator removes ineligible choices and any choice that costs more without improving the expected result. It buys another estimate only when the expected improvement exceeds inspection cost.
4. The selected system returns the result with a signed run log naming its model version, tools, data sources, and final state.
5. A verifier checks the outcome. The settlement rule pays the provider or applies a chargeback, updates its forecast, and changes the next route. Providers can appeal disputed grades.

After the task

Verify task completion, then update the next route

1. 01Task
2. 02Route
3. 03Run
4. 04Check
5. 05Settle

↩

Update the routertask fit · success · cost · latency

Routerfuture choices

Providerfeedback

Marketscore + payment

C Sometimes test a safe alternative. Without that comparison, the router cannot learn what it missed.

The remaining choices form a Pareto frontier: none can improve expected task value without giving up cost, speed, or another requirement.

Verified task completion updates three records. The router keeps the task, system, budget, and outcome. The provider receives feedback. The market receives a safe aggregate for calibration and reputation. A provider may contest the grade, but it does not issue it.

A calibrated 90 percent forecast should fail about one time in ten. Judge repeated forecasts within comparable task groups using a strictly proper scoring rule, which rewards honest probabilities. Brier and logarithmic scores are two examples.

A contractual breach is different from a probabilistic miss. A fabricated log, forbidden tool, unapproved transfer, or hard SLA miss can trigger a chargeback, a loss from a performance reserve, a reputation adjustment, or debarment. An ordinary miss updates calibration; misconduct changes payment and eligibility.

A related reverse-auction proposal lets providers report success and cost, then settles against a pass-or-fail evaluator. It assumes providers weigh equal gains and losses alike, permits negative transfers so a provider can owe money, exposes prompts to losing bidders, and may reward pleasing the evaluator instead of the user. Graded evaluations and bounded penalties remain open.

The router must sometimes test choices it would otherwise ignore. On safe, repeatable tasks, an unselected model can process a copy without taking the final action, or be graded offline. This may show that Model C can finish for half the cost. Never duplicate an irreversible action just to collect data.

Centralized versus decentralized routing and verification

No single institution runs a stock market from end to end. Exchanges match orders, clearinghouses settle trades, auditors check company reports, and regulators enforce common rules. DeFi can move matching and settlement into protocols run across a network. Neither design can tell us whether a model completed a task.

Model markets can divide the work too. Task assignment, private model checks, result verification, and settlement do not have to live in the same system.

A centralized model platform can combine demand, prices, provider health, and customer policy, then make one quick choice. That is both an information advantage and an operational one. Central clearing is not automatically inefficient either. DTCC reports that netting reduced about $2.2 trillion of average daily 2024 trade activity to $33.5 billion of settlement obligations.

The cost is concentrated control. One operator owns the ranking rules and traffic data. It can favor its own inventory, change the ranking without notice, exclude rivals, or fail. A ranking based on OpenRouter spending also reflects OpenRouter users, not the whole market.

A provider can keep its self-assessment local. It may inspect a private corpus, current load, or early reasoning without sending the raw information to the router. Objective result checks can also be distributed. Several checkers can run the tests, compare the final record, or inspect the browser state.

Distributed verification still costs more because checkers repeat work. It also creates questions about fake identities, collusion, and what happens when checkers disagree. A blockchain can record the grade, but an outside verifier still decides what grade to send. Subjective work needs an agreed evaluation process and human review.

Decentralization does not make a score honest. Providers could optimize for the evaluator, subsidize usage to lift a spend ranking, or coordinate with weak checkers. Proper scoring rules, performance reserves, and public histories make repeated overclaiming costly. They cannot guarantee that one bad signal will never move the market.

For rtrvr, I would keep the fast routing decision central, let providers estimate locally, and pay for independent verification only when the task warrants it. Shared rules can govern payment, performance reserves, disclosure, and appeals. A blockchain is useful only when participants need one settlement record and do not trust one operator to keep it.

How rtrvr is laying the foundation for model routing

People use rtrvr for knowledge work in a browser: compare information, extract structured data, work through multi-step sites, and confirm that a requested change happened. A task may start in the extension, API, MCP, CLI, cloud browser, or Rover, and use a managed model, open-weight model, closed provider, OpenRouter, or custom endpoint.

These tasks need different systems. A router may favor a small fine-tuned model for extraction, retrieval for research, or a larger reasoning budget for a long browser flow. The useful unit is the model and its tools for this task.

A router learns only from checked outcomes. Recording "Model B was selected" is not proof that the work was completed.

That is why we use code to run and verify browser tasks. Code-as-plan turns a model's plan into JavaScript inside our sandboxed execution harness. At the end, code checks fresh browser state: the form is saved, the record exists, or the extracted data matches its schema. The browser supplies the evidence; the model does not grade itself.

rtrvr Data puts the task, model, code, tool results, cost, timing, and final check in one trajectory. Verified runs can reveal useful categories. "Data extraction" may separate into tables, authenticated records, multi-page research, and document transformation because each group favors a different system.

We do not need to wait for a global model exchange to start learning. We need a reliable record of the work rtrvr already runs and checks.

We are laying the routing foundation in four steps:

1. Describe a checkable outcome, budget, time limit, allowed tools, and data rules.
2. Record which LLM, provider, prompt, tools, retrieval, and inference budget were used.
3. Check the current browser state when the task permits it. Otherwise use an agreed rubric or human review.
4. Improve the next route with those results. Buy a better estimate only when it could change the choice, and test alternatives first on safe, repeatable tasks.

The customer question is simple: which LLM completed this kind of work, at what cost and speed, and did it follow the rules? Once rtrvr can answer from verified runs, every completed task can improve the next route. That is the model-routing foundation we are building.