Router
The router resolves how a run reaches an executable model path.
That path may be local, remote, linked through an account, or adapted through a provider-specific protocol.
Model References
Decubed treats a model reference as structured data, not a loose display string.
A model reference includes:
- the provider identifier
- the model identifier
- optional serializable metadata
The runtime uses that reference to resolve the executable provider path.
Execution Planning
Before dispatch, Decubed derives an execution plan from the selected catalog entry.
That plan owns decisions about:
- context and token budgets
- reasoning behavior
- tool-call support hints
- attachment eligibility
- modality boundaries
This is where capability metadata turns into runtime policy.
Why The Router Exists
If model switching is treated as a UI toggle, every provider difference leaks into the product.
Decubed uses a routing layer so the rest of the workspace can stay stable while the execution path changes underneath it.
That is how the product can keep the same:
- thread trail
- memory policy
- tool surface
- approval flow
- environment structure
even when the chosen provider changes.
Provider Families
The shared runtime can adapt multiple provider families, including:
- OpenAI-compatible transports
- Anthropic-style transports
- linked-account responses flows
- local runtime adapters
Those paths can differ in transport and auth, but they should not force the workspace to abandon its own contracts.
What Users Get
With a stable router layer, users can:
- move between providers without resetting the workspace
- compare execution paths inside the same product
- keep local and remote options under one operational model