What Vidman AI Adaptive Actually Decides

Every call to Vidman AI Adaptive is really two decisions: which model should answer, and what the answer should cost. The caller sends one request to one endpoint; the router picks the model, and the choice stays invisible unless the response metadata is read.

The promise is the one the hard-coding post argued for from the other side: stop pinning a model ID, let the routing layer pick the best model per request. The caller’s code stops being a model catalog and starts being a task description.

This post is the inside of that decision: what the router weighs, how the choice lands, and where the router’s knowledge ends — the platform post for the routing layer, holding it to the same honesty standard as the rest of the library.

Three answers, in one pass. The model: which of the served models answers this request — the headline, since the same task can land on different models as the request mix changes. The parameters: the settings the request runs with, matched to the model and the task. And the price: the effective rate for this request, following from the model choice and published in the model library.

The decision is per-request, not per-account: two requests from one caller can route differently, because the requests are different. That is the entire point — the routing granularity is the request, not the subscription.

And the decision is observable: the response carries which model answered, so the caller can audit routing against its own expectations. The router is a black box only if the metadata is never looked at.

Three inputs go into the choice. The task: what the request asks for — the router reads it and matches it against the served models’ strengths, so a reasoning-heavy request and a formatting-heavy request do not land on the same model by default. The cost: the per-token rates of the candidates, because routing optimises for cost as well as quality — the cost-per-task discipline this blog applies everywhere, built into the routing layer. And the catalog: the models currently served, their versions, their availability — routing happens within what the library actually serves today.

The balance between quality and cost is the product decision, and it is tuned, not fixed: routing favours the model that fits the task at the rate that fits the workload. The tuning is the difference between a router that saves money and one that downgrades answers.

And the catalog input is what keeps the router honest: when a model leaves the library, routing to it stops the same day — the versioning post’s lifecycle, enforced by the routing layer.

You can — the hard-coding post’s whole argument is that the model choice is yours to make, and a hand-built router is a legitimate architecture. The question is what the hand-built version costs to keep current: the catalog changes, prices move, strengths shift — and the hand-built rules are only as fresh as the last time someone updated them.

The managed router’s advantage is the maintenance: routing logic tracks the catalog and the pricing automatically, so the caller’s code does not. The eval post’s discipline — re-evaluate when models change — is built into the routing layer instead of the team’s calendar.

And the honest boundary: the managed router is a default, not a mandate. A caller wanting a specific model for a specific task can pin it — routing is the baseline, the pin is the override. The router earns its keep on the requests where the caller has no strong opinion.

The router reads the request, not the product. It cannot know the quality bar, the brand voice, the user’s history — context that lives in the application, not in the request text. Routing optimises for the task as stated; the product’s preferences are the caller’s to enforce.

It also cannot know the future: the request that looks simple and turns out to need deep reasoning is routed before the depth reveals itself. The routing is a bet made on the request’s opening, and the bet is sometimes wrong — which is why the metadata matters, and why the pin exists.

And it cannot know the budget the way you do. Routing optimises cost per request within the catalog’s rates; the budget ceilings, spend alerts, and workspace limits are the guardrails layer’s job, applying on top of the routing rather than instead of it.

When the model choice is the product itself. A team that evaluated, fine-tuned, and pinned a specific model for a specific reason should pin it — the router’s generality is a downgrade for a deliberately made decision. The routing layer is for the requests where the choice is not the point.

It is also wrong when the workload needs a guarantee routing cannot make: a fixed model version for compliance, a fixed price for a contract, a fixed behaviour for a certification. The router optimises; it does not guarantee — and workloads needing guarantees need pins.

And it is wrong when the caller is still learning the models. The eval post’s discipline is knowing models by testing them; a team still building that knowledge should route manually and watch where requests land. The router is for after the learning, not instead of it.