The product

What the router does across a session

Moji Router sits in the request path. 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 is cache-aware: providers cache repeated context at a fraction of the price, and the router routes with that in mind.

The saving holds on a budget you fix in advance, so a single-provider team benefits too. Routing across providers is an added lever the router uses when it helps, not a requirement.

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. It keeps quality above the floor and spend under the cap, so the model bill becomes a figure fixed in advance instead of a number you discover at the end of the month.

You set a quality floor; the router stays above it, and the readout shows it. A routine turn moves to a cheaper option only where the answer still clears the bar you set.

Drop-in integration

You keep talking to the providers you already use. Point your existing model calls at the router, or use the SDK. The router runs in front of the providers you already use, over your existing endpoints, with no rewrite: your application code stays as it is, and the router decides where each turn lands.

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
    },
)

Integration is scoped with you in a pilot; your application code stays as it is.

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 on your own traffic rather than taken on trust.

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 improves on your traffic. It fits to your own workload, so the saving and the quality both hold up as it sees more of your sessions.

How a first conversation goes

We start by estimating the saving from your token and model usage. No data changes hands for that estimate, and you see the figure before any commitment. If it holds up, a plug-and-play pilot proves it on your live traffic. A contract follows once the pilot has shown the saving on your own numbers.

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 resent on every turn.

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.

Where we stand

Our routing engine scores above published state-of-the-art routers on a public router benchmark. To see your own figure, get in touch or email [email protected] with a line about your workload.