Task Matching

Task matching is the rule engine behind the task-optimized routing strategy. It is not a strategy of its own, and it is not a metrics dashboard.

When a routing rule is set to task-optimized, the gateway resolves the candidate pool as usual and then hands it here to be re-ordered. Nothing is ever removed. The gateway then walks the reordered chain until something answers.

Three consequences follow immediately, and the page states all three because each of them makes the feature silently do nothing.

It only runs where at least two candidates survive filtering. With one route left there is nothing to re-order, and no rule is even consulted.
It only affects traffic through routing rules set to task-optimized. If no enabled rule uses that strategy, nothing on this page reaches a request.
Only one rule set is ever used. If several are enabled, exactly one is consulted and which one is not defined. Enable one.

The console checks all three on load and says which, if any, is the problem.

Where the model data comes from

Not from live measurements. Three layers, in order:

A curated table compiled into the build — 37 entries keyed on model and provider, each carrying a tier (frontier, strong, mid, fast, economy), a set of strengths, quality scores from 0 to 100 per strength, and a latency class (instant, fast, standard, slow). These are editorial judgements. They are not editable from the console or the API, and change only when you upgrade.
A price-derived fallback for models in the shipped catalogue that are not in the table. Tier and a base quality figure come from the input rate:

Input rate, per 1M tokens Tier Base score
≥ 3 with a reasoning capability frontier 90
≥ 2 strong 82
≥ 0.5 mid 72
≥ 0.1 fast 62
below that economy 52

Strengths are inferred from capabilities. Latency class is always standard for a derived model, so a derived model can never satisfy a rule asking for instant or fast.
Nothing else. Provider health is deliberately not used: it measures a round trip to a listing endpoint, which is reachability, not generation speed.

Input rate, per 1M tokens	Tier	Base score
≥ 3 with a `reasoning` capability	frontier	90
≥ 2	strong	82
≥ 0.5	mid	72
≥ 0.1	fast	62
below that	economy	52

The one deployment-specific input is price, read from your own model catalogue and falling back to the shipped figures.

Rules

A set has a name, an enabled flag and a list of rules. A rule has a name, an enabled flag, a priority from 1 to 100, at least one filter, and an action.

Filters

A rule matches when every filter matches. Rules are considered by priority ascending, and the first full match wins — nothing below it is evaluated.

Condition	Compared against
`task-type`	The detected task — see below
`prompt-length`	Prompt length in characters, not tokens
`max-tokens`	The caller’s `max_tokens`, or `0` if they sent none
`budget-max-cost`	Nothing, at this stage
`latency-required`	Nothing, at this stage

The last two describe the model, not the request, so they impose no gate on whether a rule matches. They are applied during scoring instead. (Evaluating them as request filters was what previously made any rule carrying either of them permanently inert.)

Operators are eq, gt, lt, gte, lte and in. in takes a comma-separated string, not an array.

Task detection

The prompt is classified by pattern matching into coding, math, creative, reasoning, extraction, or — for anything unmatched, and for an empty prompt — conversation.

Actions and scoring

Each surviving candidate is scored, highest first:

Condition	Score
Named in `specificModels`	1000 — jumps to the front
Named in `excludeModels`	0 — sorts last
Fails a `budget-max-cost` or `latency-required` constraint	0 — sorts last
In neither catalogue	25, flat
Tier in `preferredTiers`	+30
Any strength in `preferredStrengths`	+25
Quality at the detected task	+ half the quality score, so 0–50
Detected task among its strengths	+20
Below `minQualityScore`	50 subtracted, floored at 1

Nothing is excluded — only ranked. excludeModels, a budget ceiling and a latency ceiling all sort a candidate to the back rather than removing it. If a ceiling disqualifies every candidate, the pool comes back in its original order and the request is still served, by something over budget. The gateway records that case and names the rule that produced it.

Two constraint details worth knowing:

budget-max-cost compares the dearer of the input and output rates, not an average. A model with no price recorded anywhere fails the constraint.
latency-required ranks instant < fast < standard < slow, so lte fast admits both instant and fast. A model in neither catalogue fails.

If no rule matches, the pool is returned untouched.

The fallback strategy field

A set carries a fallbackStrategy. Nothing reads it. When no rule matches, the pool comes back in the order the routing rule listed it, whatever this is set to. The field is stored, the editor shows it, and the hint beside it says so.

Cache

A change takes up to a minute to reach a running gateway process. Saving invalidates the shared copy immediately, but each process also holds its own sixty-second copy.

Endpoints

Method	Path	Permission
`GET`	`/api/admin/model-intelligence`	`model-intelligence:read`
`GET`	`/api/admin/model-intelligence/:id`	`model-intelligence:read`
`POST`	`/api/admin/model-intelligence`	`model-intelligence:create` + deployment scope
`PUT`	`/api/admin/model-intelligence/:id`	`model-intelligence:update` + deployment scope
`DELETE`	`/api/admin/model-intelligence/:id`	`model-intelligence:delete` + deployment scope

Not licence-gated. Task-optimized routing is what the gateway does, not an enterprise integration, and capability is never an entitlement.

Changes are audited under the model-intelligence resource.

No built-in role below super-admin carries the model-intelligence permission. Granting it to a custom role requires the rbac entitlement.

Routing — where a rule selects task-optimized
Routing Strategies — all eleven
Models — the pricing this reads