Choose the answering model

The router selects between the two models in the model reference. It uses task analysis and prompt/playbook metadata. This is a heuristic selection mechanism, not a measure of answer correctness.

For terminal use, start with ask.sh, devai.sh, and plan_exec.sh. Those scripts are the primary local workflow: they send requests to this router and report the actual model selected.

Automatic selection

Omit model from the query body. Inspect the returned model and routing_info. The rules default to qwen3.5:2b; coding signals may favor qwen2.5-coder:3b.

Request a specific model

After setting your terminal credential:

curl --fail-with-body http://localhost:8000/api/v1/query \
  -H "Authorization: Bearer $API_KEY" -H 'Content-Type: application/json' \
  -d '{"query":"Write a Python function that adds two integers.","model":"qwen2.5-coder:3b","user_id":"lab-user"}'

Availability validation can substitute another model. Explicit selection is not an unconditional promise to run an unavailable model.

Preview a routing decision

The preview endpoint takes URL query parameters, not a JSON body:

curl --fail-with-body -X POST \
  'http://localhost:8000/api/v1/router/test?query=Write%20a%20Python%20function' \
  -H "Authorization: Bearer $API_KEY"

Inspect routing_test.selected_model. This previews rule scoring; the actual query route also checks model availability and supplies additional analysis signals, so results can differ.

Refresh after downloading models

curl --fail-with-body -X POST \
  http://localhost:8000/api/v1/router/refresh-models \
  -H "Authorization: Bearer $API_KEY"

Single-model operation

Set ENABLE_MODEL_ROUTING=false and OLLAMA_MODEL to your chosen model, then restart the backend. With routing disabled, the per-request model override is not used. DEFAULT_MODEL is currently read for logging but does not configure the routing rules; changing it alone will not change the default.

Next: Compare routing decisions in a lab.