The AI inference management layer

What the router does across a session

Moji Router sits in the request path and cuts and controls what you spend. It reads the whole session rather than a message at a time, and routes every turn to the model and provider that answer it best for the least cost. A router that sees one message on its own cannot reason across a long task. Moji Router holds the session in view and keeps the frontier model on the turns that need it, so the bill comes down without the answers getting worse. It only ever considers models that can hold the full context of a turn; a large or document-heavy turn is never sent to a model too small to take it. Repeated context also costs less to send, because providers cache it at a fraction of the price, so a session that resends context is cheaper to run.

The saving holds on a budget you fix in advance: a single-provider team benefits too, and it grows once you route across more than one provider.

Who it is for

Moji Router fits companies whose cost of goods is dominated by frontier-API spend, running multi-turn or agentic products across the providers they already use.

• Coding agents: long sessions with heavy context reuse.
• Agentic SaaS: products where inference is a large share of operating cost.
• Long-session assistants: multi-turn work with context that keeps growing.
• Retrieval-heavy products: tools and documents sent every turn, whether the same set repeats or a fresh set is retrieved each time.

The same control applies to an internal platform team running a fleet of always-on agents for its own organisation. The budget is set over a continuously-running workload rather than a single session, and the router holds every turn of that workload inside it.

Three operating points

For each workload the router plots the options by cost and quality, then holds the operating point you choose, turn after turn.

• Saver: the cheapest path that clears the quality floor.
• Balanced: the most quality per dollar, the default.
• Quality-max: the highest quality inside the budget cap.

A budget and a quality floor

You set a budget and a quality floor, and the router stays inside both, so the model bill becomes a figure fixed in advance instead of a number you discover at the end of the month. A routine turn moves to a cheaper option only where the answer still clears the bar you set, and the readout shows quality against the floor turn by turn.

Drop in, and start a pilot

Point your existing model calls at the router, or use the SDK. It runs in front of the providers you already use, over your existing endpoints; your application code stays as it is. For an OpenAI-compatible client, the change is the base URL and the key. The routing envelope, the operating point, the monthly budget, and the quality floor, is set alongside the request:

# Only the base URL and key change.
client = OpenAI(
    base_url="https://api.mojirouter.com/v1",
    api_key=MOJI_ROUTER_KEY,
)

# The routing envelope, held turn after turn.
response = client.chat.completions.create(
    model="auto",              # let the router pick
    messages=messages,
    extra_body={
        "operating_point": "balanced",   # saver | balanced | quality-max
        "monthly_budget_usd": 20000,     # the bill, fixed in advance
        "quality_floor": 0.9,            # the router stays above this
    },
)

Starting is a base-URL change on one workload, so you can put the router in the request path without rewriting your application. Get in touch and we will set one up with you.

The savings readout

The router reports what it saved. You see what each routing decision cost against the model you would otherwise have called, so the saving is visible rather than taken on trust. The same readout reports quality against the floor you set, turn by turn, so you see a dip before your users notice it.

Failover when a provider degrades

If a provider slows down or starts returning errors, the router moves the turn to another option that clears the quality floor. The session carries on inside the same budget, with the fallback handled for you.

Overhead in the path

The router is a thin layer in the request path, so it adds little time to a call. We measure its own overhead and report it alongside the saving, so you see what it costs in time as well as what it cuts in spend before you commit.

Calibration to your own traffic

Once it is running, the routing calibrates to your workload, so the saving and the quality both hold up over time. The budget and quality floor you set stay fixed throughout; only the routing choices inside them improve as the router sees more of it.

The next layer

Routing is the first layer of managing your inference, and the engine reaches further. We are a research team, and the same platform grows on the same drop-in layer and the same budget and quality floor.

• Session routing: pricing the whole session to keep context warm across every turn and every provider.
• Model training: we train models that scale intelligence continuously on demand. Intelligence becomes a dial the router sets per turn: turned down it cuts the bill at equal quality, turned up it buys more quality for the same spend.
• Agent routing: as you run fleets of agents, the same layer routes each sub-task to the model that fits it, inside a cost envelope you set.

What you adopt today extends as your inference grows: the layer that cuts the bill now is the one that manages it as your product scales.

Where we stand

Our routing engine scores above published state-of-the-art routers on a public router benchmark (2026). To talk through what it could do for you, get in touch or email [email protected] with a line about your workload.