Model Selection, Retries, and What NoirCode Does Not Route

A NoirCode request does not pass through a routing engine that classifies difficulty, estimates tokens, checks a budget, and picks a model. The path is shorter:

prompt
  -> session on the local server
  -> agent and permission checks
  -> tools, when the model asks for them
  -> the provider adapter for the selected model
  -> streamed reply

The model is an input you set, not an output of the request.

Selection

These are the controls that exist:

• /models sets the session model. The choice is not written back to the config file.
• model in noircode.jsonc is the default for new work. The root value stores the provider and model, not a variant.
• --model provider/model on noircode run covers that command.
• An agent definition can name a model. Launching that agent uses it. Selecting a primary agent by id does not replace the model already stored on the session.
• #variant selects a named option on that model, often reasoning effort. The names come from the catalog. You can add variants in the provider’s model settings.

Availability is per project. The model must be enabled, and its provider must be configured here. A policy with provider.use deny removes that provider from the list.

When the configured default cannot be used, NoirCode falls back to the newest available supported model. That is the product’s fallback. There is no rule table that sends “rename a variable” to one model and “review auth” to another, and there is no runtime classifier emitting difficulty scores.

Different models for different jobs

If you want a cheaper model for one job and a stronger model for another, you configure that yourself:

• a default model for ordinary sessions
• a reviewer agent whose frontmatter sets another model
• noircode run --model ... in a script

Subagents are how a session uses a second profile. Explore searches without editing. A custom reviewer can be denied edit and shell. They run because the primary agent launches them or you ask it to. They are not a validation stage inserted under every response.

Retries

Providers fail. NoirCode records session.retry.scheduled with the assistant message, an attempt number, and the error, and it tries that step again. The retry stays on the selected model. It does not walk a ladder from Claude to GPT to Gemini to a local model, and it does not move traffic between regions or endpoints you did not configure.

A private endpoint is a custom provider baseURL. Health, capacity, and regional failover of that endpoint are the host’s problem. NoirCode does not open a circuit breaker, measure utilization, or balance across replicas.

Context still matters, and you choose the model that can hold it

Large repositories are handled by tools and compaction, not by swapping in a “large context” model automatically. The agent reads and searches. Compaction summarizes older conversation and keeps about 15,000 recent tokens. If a task needs a long context window, select a model that has one.

Tool use depends on the model you picked. Models differ in how reliably they call tools. NoirCode does not detect that and reroute. You change the model when the one you chose is a poor fit.

What to ignore from a generic “AI router” design

These are not NoirCode features:

• cost-based or latency-based routing
• daily budget switches that force a local model
• consensus across several models
• a reviewer model on every response
• load balancing and regional failover
• automatic provider fallback chains

The reliable version of “use the right model” in this app is explicit: set the default, override it per agent or per run, and let retries repeat the same call when the provider errors.