Choosing the model and the depth of reasoning is a balance of quality, speed and cost, and it starts with an honest rule: the available models and effort levels depend on the model catalog, the account and the surface. Do not fix an old screenshot as a contract: what was true yesterday or for a colleague may be false for you. The current set is checked live - with the /model command and a /status check - not carried over from someone else's config as a given.

The base model setup lives in config.toml and reads as an explicit profile. The model and model_reasoning_effort keys set which model and with what reasoning depth works by default, and personality affects the answer's style. It helps to see such a fragment in full once: it makes the choice reproducible and explainable. But the earlier rule applies here too - a specific model name is checked live, because the catalog changes faster than any recorded example.

Reasoning effort is worth understanding by purpose, not by the feeling that "more is better". High effort is justified where the task really requires reasoning: ambiguous architecture, a security review, complex debugging. There it pays off in quality. But for a read-heavy scan or a mechanical edit high effort may only increase latency and spend without adding anything to the result. The level is chosen for the nature of the task, not cranked to the max just in case.

It helps to see a conscious model profile in config.toml once. Below is a fragment with the model, the effort level and personality. You return to this form when tuning behavior for a task: it sets behavior explicitly rather than leaving it to a random choice from the previous session. The comment next to it recalls the main point: the specific model and available effort levels are verified via /model and /status, because they depend on the account and the surface.

The Fast tier is a separate speed switch with its own consequences. The /fast command speeds up work where it is supported, but faster does not always mean cheaper or more accurate: the accelerated mode may have its own price and its own limits. You enable it consciously, for a task where responsiveness matters, not by default. As with the model, the effect is checked, not assumed: what speeds up one scenario is not obliged to improve another.