Models and role activation

Role-model only works as well as the active model and role inventory you give it.

The operator job here

Before benchmarking or routing, the operator needs to make four things true:

• the provider or local backend is connected
• the target models or endpoints are actually active
• the intended roles are assigned
• the candidate set reflects real production intent

Default role assignment

Newly added or loaded models default to all roles in taxonomy V1. This keeps first-run setup simple: a model is usable immediately, and operators can remove roles only when they know the model should not compete for that work.

The UI exposes this as visible checked role controls grouped by taxonomy group, plus an All roles control. Persisted role assignment uses all/include/exclude semantics:

This all/include/exclude model avoids ambiguity between "default all roles" and "intentionally no roles." Policy-sensitive roles such as security, legal, finance, recruiter, and health are labeled so they can be reviewed deliberately.

Why role activation comes before benchmarking

The benchmark should grade the same role-aware candidate set that Router will later use.

If the role assignments change after the benchmark, your benchmark story and your routing story will drift.

Useful taxonomy V1 roles

Useful first-run checks include:

• coder with tasks such as coder.edit and coder.review
• security with tasks such as security.audit
• product with tasks such as product.requirements
• researcher with tasks such as researcher.web_research.current
• support with tasks such as support.ticket.reply

Task details are shown after models are configured. The model page should keep add/load flows compact, then let operators drill into tasks by role when they need to inspect coverage.

Next

Continue to Benchmarks and evaluation.