Model overrides

A model override lets you pin the sampling parameters a model is called with — things like temperature, top_p, top_k, or a provider-specific setting like Ollama’s num_ctx (context length). You write the parameters once, say which models they apply to, and Catalyst merges them into every request to a matching model — no need to remember to set them each chat.

Open Settings → Model overrides to manage your own.

Sampling parameters, in plain terms

These are the dials that shape how a model responds — how random or focused it is, how much it can read at once, and so on. A lower temperature makes answers more deterministic; a larger context length lets the model consider more text. Each provider documents its own set.

How matching works

Each override has a match pattern — a regular expression tested against the model name being sent to the provider (for example claude-sonnet-4-6 or gemma4:31b). When the pattern matches, that override’s parameters are applied. A pattern like (?i)gemma matches every Gemma model regardless of size or capitalization; ^claude matches anything starting with claude.

If several of your overrides match the same model, they merge in priority order — higher priority wins on any parameter they both set.

Creating an override

1. Name it and, optionally, add a description so you remember what it’s for.

2. Set the match pattern — the regex that decides which models it applies to.

3. Write the sampling parameters as a JSON object, e.g.:

   {
     "temperature": 0.2,
     "top_p": 0.9
   }

4. Set a priority (higher wins when overrides overlap) and leave it Active.

The parameters are open-ended

Catalyst does not restrict you to a fixed list of parameters. Whatever keys you put in the JSON are passed straight through to the provider. That means when a model introduces a brand new setting — say a hypothetical reasoning_limit — you can use it the same day, with no update to Catalyst:

{
  "reasoning_limit": 2048
}

If the provider understands the key, it takes effect; Catalyst’s job is to deliver it.

One reserved area: thinking

Whether a model thinks (and how hard) is controlled by the reasoning-effort control in the chat composer, not by an override. So reasoning_effort, thinking, and think keys in an override are ignored in favor of what you pick in the chat. Every other parameter passes through normally.

Testing before you rely on it

Use Test resolution: type a model name and Catalyst shows the exact set of parameters that would be sent — the merged result of every matching override. It’s the quickest way to confirm your regex matches the model you meant and that the final values are what you expect.

Yours layer on top of the workspace defaults

Your workspace can ship its own built-in overrides (curated by an admin) so models behave sensibly out of the box. Your overrides layer on top of those:

• A parameter only the workspace sets is kept.
• A parameter you both set uses your value — yours win.

So you never lose the workspace’s sensible defaults; you only adjust the specific dials you care about.

Stays out of your way

Set it once; it applies automatically to every matching model, in chat and in workflow nodes.

Future-proof

Any parameter a provider accepts works — new model settings need no Catalyst update.

Personal

Your overrides are yours alone. They never change a model for anyone else in the workspace.

Reversible

Toggle an override off, or delete it, and the model goes straight back to its defaults.

Next

• Models & providers — set your default model and pin favorites at the picker; model overrides handle the sampling-level tuning.
• Memory, Skills, and Prompts — the other ways you tailor how Catalyst works for you.