Most people pick a model and stop. But the model is one dial among several, and the others — reasoning effort, temperature, how eagerly the agent reaches for tools, how much it's allowed to write — change the outcome just as much. Get the combination right and a "dumber" setup outperforms a smarter one left on defaults.

§1The knobs that actually move outcomes

// reasoning effort

How long it thinks before it acts

The single biggest lever. Low effort answers fast and shallow; high/max effort plans, checks itself, and reconsiders. Costs more tokens and latency — worth it exactly when being wrong is expensive.

// model tier

Raw capability per token

Frontier tier for judgement and architecture; a faster, cheaper tier for mechanical edits and grep-and-report. Matching tier to task is most of the cost savings.

// temperature

Determinism vs variety

Low (near 0) for code, refactors, and anything you want reproducible. Higher only when you want divergent ideas — naming, copy, brainstorming.

// tool-use aggressiveness

How eagerly it reaches for tools

Agentic work wants an agent that greps, reads, runs, and verifies on its own. A quick edit wants it to just answer and stop. This is the knob most people never touch — and it's the difference between "helpful" and "runaway."

// output budget

How much it's allowed to write

A tight cap forces answer-first brevity; a generous cap lets it write the whole file or the full plan. Wrong cap = truncated code or a wall of preamble.

// context budget

How much it loads before working

More context = fewer blind mistakes but slower, pricier turns. Load the rules file and the relevant files — not the whole repo.

§2Reasoning effort — the biggest lever

If you tune one thing, tune this. My rule of thumb maps effort to cost of being wrong, not to task difficulty:

EffortUse forFeels like
lowmechanical edits, formatting, grep-and-report, "just do the obvious thing"a fast, literal junior
mediumeveryday feature work with a clear speca competent engineer
highrefactors with blast radius, tricky bugs, design callsa senior who plans first
maxarchitecture, incident forensics, anything irreversiblea staff engineer who won't be rushed

Most agents expose this directly. In an interactive session I flip it inline; in a config I pin it:

flip effort mid-session, or pin it in config

# interactive, per-task
/effort high        # about to touch something risky
/effort low         # back to mechanical cleanup

# or pinned in a config file
reasoning_effort = "high"
FIELD NOTE — SPEED MODE IS NOT A DUMBER MODEL

A "fast" mode on a frontier model usually keeps the same model and just streams output sooner — you trade some deliberation for latency, not intelligence. Great for mechanical batches; wrong for the change that could break production. Know which one your "fast" toggle actually is.

§3Two saved profiles: speed vs agentic

The thing that made the biggest day-to-day difference: I stopped re-tuning per task and saved two named profiles, then switch between them. One is built for coding speed, the other for agentic, tool-heavy work. Concretely:

Profile A — speed (mechanical throughput)

For grinding through a decided change: low effort, fast tier, minimal tool ceremony, generous output so it writes whole files in one go.

~/.config/agent/profiles/speed.toml

# optimised for throughput on decided, mechanical work
model            = "fast-tier"
reasoning_effort = "low"
temperature      = 0.1        # reproducible edits
max_output       = "high"     # write the whole file, don't truncate
tool_use         = "conservative"   # answer/act, don't go exploring
auto_verify      = false       # I'll review the diff myself
approval         = "auto-edit" # don't stop to ask on every file

Profile B — agentic (tool-heavy autonomy)

For "go figure this out": frontier tier, high effort, full tool access, and self-verification on — the agent is expected to grep, read, run, and check its own work before reporting.

~/.config/agent/profiles/agentic.toml

# optimised for autonomous, multi-step, tool-driven work
model            = "frontier-tier"
reasoning_effort = "high"
temperature      = 0.2
max_output       = "medium"
tool_use         = "aggressive"     # grep, read, run, iterate freely
auto_verify      = true             # reproduce the result before claiming done
approval         = "on-risk"        # pause only for irreversible actions
parallelism      = 4                # fan out sub-agents for big sweeps

switch profile per task, not per keystroke

agent --profile speed    "reformat these 40 files to the new style"
agent --profile agentic  "find every place this API is called and migrate it, verify the build"
PATTERN — PROFILE, DON'T RE-TUNE

Re-deciding six knobs per task is friction you'll skip, so you'll run everything on one compromise setting. Two or three saved profiles — speed, agentic, maybe review — collapse the decision to one word and make sure the tool-use and verification settings always match the job.

§4Temperature & output: small knobs, real bugs

§5The local tier has its own knobs

When a task runs on a local model instead of a hosted one, two extra dials appear: quantization (how aggressively the weights are compressed — smaller and faster vs. more faithful) and context length (how much you can feed it before it slows to a crawl on your hardware). The trade is always the same shape: fit-on-my-machine versus quality, and you pick per task.

Steal this

  • Tune reasoning effort first — map it to the cost of being wrong, not task difficulty.
  • Match model tier to the job; frontier for judgement, fast tier for mechanical.
  • Keep temperature near 0 for code; raise it only for ideas.
  • Save two profiles — speed and agentic — so tool-use and verification always match the work.
  • Set the output cap on purpose; the wrong cap truncates code or buries the answer.
  • Know whether your "fast" mode drops deliberation or just streams sooner.