Build

Every model. One endpoint. Priced before it runs.

Agentic applications need whichever model is right for the task in front of them, and that answer changes every few weeks. Model Factory is a single MCP service that reaches all of them, chooses on the merits, and tells you what the call will cost before it makes it.

Your application
Model Factoryestimate · route · reconcile
Every model
{
  "model": "the routed model",
  "estimate_usd": {
    "floor": 0.0041,
    "expected": 0.0087,
    "ceiling": 0.0192
  },
  "basis": {
    "input_tokens": 1842,
    "max_output_tokens": 4096
  }
}
SPECIMEN, NOT LIVE

You cannot govern a cost you only see afterwards.

Two problems arrive together the moment an application stops calling one model and starts calling the right one.

  • Every provider is a separate integration. Different schemas, different auth, different rate limits, different failure modes, different ideas of what a token is. Each one you add is another thing to keep current, and the model layer now moves considerably faster than your release cycle.
  • Cost is discovered after the fact. This is the harder one. An agent loop has no fixed cost. It retries, it carries context forward, it fans out over a batch, and it makes those decisions at runtime. Every tool available to you today reports what you spent once you have spent it. A dashboard, an alert, a bill. By then the money is gone and the only remaining control is a hard cap that kills a job halfway through.

So model choice gets frozen. Teams pick one model at build time, wire it in, and stop revisiting the decision, because the alternative is an integration project and an unbounded invoice. The application ends up running an expensive model over trivial work and a weak one over work that deserved better.

A single MCP service in front of every model.

  • One endpoint, one schema. Text, vision, image, audio and video models behind a unified parameter surface. Adding a provider is our work, not yours.
  • An estimate before execution. Every request can be costed before it is processed. The estimate comes back in USD, in the tool response, in the agent's own context, while there is still a decision to make.
  • Routing on the merits. The best available rate for the task, where best means the cheapest option that clears your quality bar rather than the cheapest option outright.
  • Reconciliation after the call. Actual cost recorded against the estimate, with the variance visible. An estimate you cannot audit is a guess with a currency symbol on it.
  • Failover that does not become your incident. A provider outage or a rate limit reroutes rather than surfacing as a 500 in your product.
  • Attribution and audit. Every call traced to a tenant, a feature and a purpose, so spend can be explained at the level a finance team asks about it.

How the estimate actually works

Input cost is known exactly. We tokenise the request against the target model's own tokeniser and multiply by that model's input rate. There is nothing approximate about that half.

Output cost is bounded rather than known, because nobody can tell you how long a response will be before the model writes it. So the estimate returns three numbers: a floor, an expected value based on observed output lengths for that task class in your own workload, and a ceiling set by the token limit on the request. The ceiling is the number that matters, because it is the one you can hold a budget against.

Anything with a fixed unit price, which is most image, audio and video generation, returns an exact figure rather than a range.

We will not tell you we know what a call will cost. We will tell you the most it can cost, what it will probably cost, and what it did cost, and we will show you the gap between the second and the third over time so you can see whether our expected values are any good.

What this makes possible

  • Cost aware agents. The price is in the model's context before it commits, so routing can be a decision the application makes rather than a configuration someone set last quarter.
  • A budget a finance team will approve. Cost per unit of work, before launch, with a defensible ceiling. This is usually the thing standing between a working prototype and a funded feature.
  • Thresholds that hold. Refuse above a figure, require a human above another, downgrade the model instead of failing the job.
  • Model changes without integration work. When something better or cheaper ships, it appears behind the same endpoint. Your quality bar decides whether it gets used.

Routing is an evaluation problem

Cheapest is easy and frequently wrong. A model that saves a fraction of a cent and fails one call in twenty costs more than it saves the moment a person has to check the output.

So routing is set against evaluation, not price alone. We build a held out set of real tasks from your workload, score candidate models against it, and establish the quality bar per task class. The router then takes the cheapest model that clears the bar. When a new model appears it runs the same set before it becomes eligible, and you get told what changed.

This is the same evaluation discipline we build into MCP servers, and it is the reason Model Factory is delivered as part of an engagement rather than handed over as credentials. The routing is only as good as the evaluation behind it, and the evaluation has to be built against your work.

Who this is for

  • Product teams embedding models in a shipping application, who need the newest model available without an integration project each time.
  • Enterprises with a spend approval problem, where the AI feature is built and the budget is stuck because nobody can state the unit cost.
  • Platform businesses running high call volumes across mixed task types, where routing on the merits is a margin decision rather than a preference.

The outcome

Your application reaches every model through one integration. Your agents know the price before they commit to it. Your finance team can read spend by feature and by tenant. And when the model layer moves again, which it will, the change lands behind the endpoint instead of in your roadmap.

Bring us one workload where you do not know what the model layer costs per unit of work.

We will cost it against three candidate models and show you the routing decision before you commit to anything.