Decision models and routing mechanism
简体中文 · Custom extension API · Official Jev extension
HiRoute uses a decision model to choose the models for the current task and, when enough evidence is available, assess the preceding execution stage. You configure the task conditions and model groups; HiRoute applies them on each new user turn.
Connect a decision model
- Open Models → Decision models and add a connection. Built-in connections support Bailian, OpenAI, OpenRouter Jev, TypeSafe, and compatible endpoints that use the System One or OpenAI decisions protocol.
- Choose the credential source: reuse the keys of an existing API connection, or enter a key for this decision model only. Confirm the model, complete endpoint and protocol, then save and test the connection.
- Select the saved connection in a routing plan and configure difficulty routing or custom task branches with their execution models.
- Publish the plan to apply it. Editing a connection or a draft takes effect only after the plan selects that version and is published again.
Built-in decision models need no self-hosted service. The connection test checks the saved connection's transport and required response fields with synthetic input; it does not establish the accuracy of decisions on your tasks. The context window follows the model metadata automatically: current input and decision questions take priority, and history uses the remaining space.
A custom extension is an optional HTTP service that integrates its own provider and chooses the category and regular/primary group from the route shape sent by HiRoute. Its optional stage score is used only for observation. Add it from the same page using its complete endpoint. The form provides copyable request examples and an OpenAPI download. The official Jev extension is a deployable reference implementation.
Choose a routing mode
| Mode | What the decision model judges | Execution models |
|---|---|---|
| Difficulty routing | Whether the current task is simple or complex | Economy and primary groups |
| Custom branches | The current task category, then its required degree when it has two groups | Regular models and optional primary models per category |
With a built-in decision model, each new message gets three independent answers along the task's timeline:
| Question | Example | Effect |
|---|---|---|
| How did the last step go? | A draft has useful structure but unsupported claims | A competence score that also feeds model reports and trust suggestions |
| How hard is this step? | A local wording edit or a full argument review | A simple probability; only simple-enough work can go to the regular group |
| Will the last step's problem carry into the next? | Evidence the last step missed is still needed now | If it does, low-score protection hands the turn to primary; if not, protection is released and difficulty decides |
HiRoute applies the published plan's thresholds, chooses the group and runs it, so you can retune routing without rewriting prompts. Custom branches first decide which category the current task belongs to, such as writing or reviewing, and then choose a model group within that category.
For custom branches, overlapping conditions are resolved by the current request's main intent; no match uses the configured default branch. A category with only regular models skips degree evaluation and can still collect competence scores. Difficulty routing uses one task scope, so simple and complex are not separate task branches.
How HiRoute selects and executes models
For a built-in decision model with two groups, regular/economy models are selected when this call's simple probability meets the threshold (set by trust; 0.8 by default for a new plan) and there is no applicable complete score below the competence floor (default 0.5). Otherwise HiRoute selects primary models. Low-score protection uses only a fresh score for the preceding actual stage with the same category, published plan version and assessment standard. Missing assessments remain unscored; assessments based on partial evidence retain that marker and are excluded from averages. Neither is treated as zero or triggers low-score protection. A saved old score does not become a fresh low score on later turns. A writing score does not upgrade a review task.
With valid difficulty, HiRoute evaluates an eligible low score regardless of whether the task is simple or complex. Earlier problem relevance below 0.5 means the last step's problem does not carry into this one. It releases the historical constraint; the difficulty result still determines the group, so complex work remains Primary. Unavailable relevance retains protection. The previous actual stage may itself have used Primary; that never creates a third group.
Each new user message is decided again and may choose either group. Tool continuations and same-turn replay reuse the frozen decision only when HiRoute can recognize the same turn and that decision remains reusable. Discontinuous reconstructed history or a decision that cannot be inherited requires a new judgment. The preference to keep the current model applies only among eligible models in the newly selected group.
HiRoute tries the selected group's candidates in order. If regular/economy candidates are exhausted, it can relay to the same category's primary group. Primary exhaustion fails the request. Starting in primary keeps relay within that group; a single-group category fails when its candidates are exhausted. A candidate failure does not create a competence score.
For built-in models, if the category is valid but its degree result is unavailable, HiRoute uses that category's primary group. If the whole decision fails, difficulty routing uses its heuristic rules; custom branches use the default category and its primary group when configured.
Adjust judgment settings and inspect results
For built-in decision models, Trust in the route editor sets how much work goes to the regular group: further right sends more tasks to Regular. It is saved as a simple-probability threshold, with five presets, Trial (0.9), Familiar (0.8), Trusted (0.65), Hands-off (0.5) and Entrusted (0), or an exact value. Applicable low-score protection applies at every level. Judgment settings start collapsed. Expand them to edit the simple/complex criteria, competence floor (default 0.5), assessment instructions and the 0 / 0.5 / 1 competence anchors. Category conditions describe task intent, degree conditions describe work within a category, and competence standards assess work that has already happened.
With built-in models, custom categories follow the plan's judgment settings by default. Independent editing copies the complete settings; resetting resumes following the plan. Difficulty routing also offers explicit heuristic rules, which do not produce model competence scores.
Published definitions, connection versions and assessment standards are frozen. Session and plan views show why a group was selected, the group and model that actually executed, and any later score for that stage. Later scores and draft edits do not rewrite earlier selection reasons.
Built-in integration and custom extension responsibilities
| Responsibility | Owner |
|---|---|
| Categories, conditions and model groups | HiRoute, from the published plan |
| Custom-extension category/group decisions and optional scores | The extension, using its own policy |
| Built-in assessment standards and thresholds | HiRoute, from the published plan |
| Selection, eligibility, availability relay and actual-stage observations | HiRoute |
| Direct System One provider calls and answer mapping for built-in connections | HiRoute's built-in adapter |
| Provider calls, answer mapping and necessary history trimming for a custom connection | The custom extension, using its own policy within the published categories and groups |
The custom extension API can return the current decision and a preceding-stage assessment in one call. Its current v1 has one request shape; the canonical examples and OpenAPI describe that boundary. Complete current input is preserved, while missing target evidence must remain visible as partial. The routing guide describes the product configuration.
Tool subset selection is future protocol documentation only; it has no supported runtime or product entry.
Custom-extension routes show categories, conditions and candidates only. Their judgment settings stay parked for a later switch back to a built-in connection. Extensions return category, group, optional reason and optional {score, partial} assessment; HiRoute applies no threshold or competence protection to this decision.