Router Configuration
The router is configured with YAML plus environment-loaded secrets. Keep provider credentials in the deployment environment, a secret manager, or a protected runtime env.json; the checked-in env.example.json is only a shape template.
config.example.yaml is the shipped reference config and the source of truth for example field values. The examples in this section are partial subsets unless a code block is explicitly titled config.example.yaml.
Model group names are deployment-defined. Names such as default, fast, small, medium, high, big-coder, or vision may appear in reference examples because a sample or hosted deployment uses them; the product does not require those names.
For admin authentication, admin authorization, and PII filtering, see the canonical Security And Governance pages: Admin Authentication, Admin Authorization, and PII Filtering.
Metrum can help design a production routing policy. Contact contact@metrum.ai.
File Layout
The top-level config shape is:
server: listener, default model group, cache, logging, usage persistence, license enforcement, decision telemetry, upstream timeouts, diagnostics, traffic shaping, admin auth, content capture, retention, and admin reports.state_path: local router state path.providers: upstream provider skins, credentials, model catalog metadata, capability metadata, pricing metadata, and shared provider traffic shaping.models: deployment-defined caller-facing model groups and target selection strategy.users: explicit user or service-account records.projects: explicit project records.project_memberships: user-to-project role/status bindings.callers: bearer-token subjects, owner/project binding, allowed model groups, metrics/content roles, rate limits, quotas, and caller traffic shaping.
Module References
Use these pages as the canonical homes for each configuration area:
| Topic | Canonical page |
|---|---|
| License enforcement | License |
| Provider skins, model catalog metadata, modalities, tools, pricing fields | Provider Catalog |
| Shared provider/model/target capacity controls | Provider Traffic Shaping |
| Model groups and weighted routing | Model Groups |
Caller tokens, users, projects, memberships, allow lists, /v1/models visibility | Caller Tokens |
| Caller burst smoothing and bounded queueing | Caller Traffic Shaping |
| Cache, usage DB, decision telemetry, diagnostics, content capture, retention | Cache And Usage Store |
| Model-group quality contracts | Model Group Contracts |
| Reasoning eligibility | Reasoning Routing |
| Dynamic-score routing | Dynamic Score Routing |
| TypeScript routing | TypeScript Routing |
| External policy services | External Routing Policy |
| Self-hosted OpenAI-compatible upstreams | Self-Hosted Upstreams |
| Image/VLM routing | Image Analysis And VLM Routing |
Operational Notes
Change config with structured YAML tooling, validate the result, run the router test suite or the relevant smoke tests, and keep public docs plus operator runbooks in sync when behavior changes. For a strategy-by-strategy ownership guide that ties caller access, group-local routing, validation, policy services, and rollback evidence together, see Customer-Controlled Routing.