Appearance
Model Specializations: Tag Models for Smart Routing
Tell the router what each model is good at, so a coding request lands on a coding model and a legal question lands on a legal one — using a fixed, platform-wide vocabulary instead of free-text keywords.
Why this exists
Smart routing can only prefer a "coding model" if your models say, in a machine-readable way, that they are coding models. Free-text tags don't survive contact with real teams: one admin writes coding, another Code, a third software, and the router treats those as three unrelated things. Specializations fix this with a canonical vocabulary — every model carries codes from one fixed list, and common variants are recognised automatically.
The older free-text Keywords field still exists on each model, labelled legacy. It is not used for routing decisions. Re-tag your models with specializations; the keywords field will be retired once migration is complete.
Tags are a claim, benchmarks are a measurement
With task-aware routing, the model configuration dialog shows what benchmarks and your own data say about each tag, and flags tags that no evidence supports.
The vocabulary
Specializations are grouped by category. The list is platform-managed — you pick from it, you don't invent entries:
| Category | Codes |
|---|---|
| Technical | coding, debugging, architecture, devops, technical-writing |
| Cybersecurity | cybersecurity, incident-response |
| Legal | legal, contract, compliance |
| Medical | medical |
| Research | research, data-analysis, long-context |
| Business | business, finance |
| Creative | creative-writing, marketing |
| General | general, reasoning, math, summarization, translation, multimodal |
Each code has aliases that resolve to it automatically in spreadsheet imports — for example code, programming, software and dev all become coding, and security, infosec and appsec all become cybersecurity. You never need to remember the aliases in the UI: the picker only offers canonical entries.
Tagging a model in the UI
- Go to Admin → AI Providers and open a model's edit dialog.
- Find Specializations under Routing & Configuration.
- Tick every domain the model is genuinely good at. Hover a label for its description.
- Save. The change is recorded in the audit log (who, when, from → to), because a specialization edit changes where production traffic is routed.
Example — a coding-focused deployment: for a model you bought specifically for your engineering teams, tick coding, debugging and reasoning. When smart routing later handles a request from a coding tool, models tagged coding are preferred over general ones.
Pick honestly, not generously
A model tagged with everything is preferred for nothing. Tag the two to five domains the model demonstrably handles well; leave general for genuine all-rounders.
Tagging models in bulk (spreadsheet)
The provider Excel/CSV files have a Specializations (comma separated) column, next to the legacy Keywords column:
csv
..., Keywords (comma separated), Specializations (comma separated), ...
..., "general,coding,creative", "coding,creative-writing", ...Import behaviour:
- Aliases are resolved for you. A cell containing
Code, securityis stored ascoding, cybersecurity. - Unknown terms are reported, never guessed. A term that matches no code and no alias (say,
quantum-alchemy) is dropped from that row, and the import response lists it underspecializationWarningswith the affected provider/model. The rest of the sheet imports normally — one typo does not block 200 rows. - A blank cell keeps the model's existing specializations. Blank means "no change", exactly like the watermark columns. To clear a model's specializations deliberately, do it in the UI.
- Re-importing an exported file round-trips the column without loss.
Who can edit what: the curator role
Tagging models and rotating provider API keys are now separate permissions:
| Capability | Company owner / admin | CATALOG_CURATOR role | catalog.models.edit permission |
|---|---|---|---|
| View the model catalogue | ✓ | ✓ | ✓ |
| Edit specializations, pricing, capability flags | ✓ | ✓ | ✓ |
| Set or rotate a provider API key | ✓ | — | — |
| Delete a model configuration | ✓ | — | — |
CATALOG_CURATORis a user role for someone whose job is catalogue quality — tagging models, maintaining pricing and capability flags — without any access to provider credentials.catalog.models.editis an access-profile permission: an admin can grant catalogue editing to, say, a lead engineer through their access profile, without changing their role at all.
API keys are managed through their own endpoint and their own audit trail. If a catalogue edit includes a real API key, it is rejected with a clear error rather than saved — credentials never travel with catalogue edits.
Use cases
- Vibe-coding / IDE traffic: gateway keys used by coding tools route with a preference for
coding-tagged, tool-capable models. Tagging your models is what makes that preference mean something. - Regulated content: tag your EU-hosted, non-training model
legalso contract questions prefer it over a cheaper general model. - Delegated curation: give your platform team
CATALOG_CURATORso they keep the catalogue accurate while key custody stays with account admins.