Why model choice becomes lock-in
Lock-in is rarely the API key. It is the agent written against one SDK, the prompt format that only one provider accepts, and the missing trace that would tell you whether a cheaper model is actually worse. Without a comparison on the same task, switching feels like a rewrite because it is one.
How to route one task across models
Freeze the agent: same instructions, same knowledge scope, same tool grants. Change only the endpoint. Run the task. Read latency, token cost, the sources retrieved, and whether the tool calls succeeded. If you send the task to more than one model, compare those traces before you pick a default. Sample charts in the product are labeled illustrative; your traces are the measurement.
What should stay stable
- Instructions and output constraints live on the agent, not inside a vendor client.
- Knowledge collections stay scoped the same way for every endpoint you compare.
- Tool grants and schemas do not change just because the model did.
- The execution record is what you compare, not a screenshot of two chat windows.
How Obliq keeps the agent when the endpoint moves
The runtime is architecturally model-agnostic. Connect a frontier API with your own key or a private endpoint. Replay a previous execution against the new model and read both trails. The agent identifier does not have to change for the comparison to be valid.
Questions
What is model routing?
Model routing sends one task to one or more endpoints and keeps the surrounding agent fixed. You compare the runs, then keep the endpoint that fits quality, latency, cost, and groundedness.
How do I avoid model provider lock-in?
Do not encode the provider SDK into the agent. Assign an endpoint. Bring your own key or a private URL. Instructions, knowledge scope, and tool policy stay where they are.
Are Obliq model comparisons official benchmarks?
No. Interface examples are illustrative. Use your own execution traces when you need a number. Published research will say so when a measurement exists.