---
title: "Tuning Claude Code config to your plan"
url: "https://turingblog.org/en/notes/patterns/claude-code-config-by-plan"
date: 2026-11-11
tags: ["Claude Code","Agent","Config"]
description: "Run the main session on a mid-tier model at its default effort, hand search and log reading to small-model subagents, and start a new session at natural breaks."
insight: "Run the main session on a mid-tier model at its default effort, hand search and log reading to small-model subagents, and start a new session at natural breaks."
problem: "My config had piled up across several model generations: the global effort level was a habit from an older model, and subagents inherited the main session's model by default, which is poor value on a Pro plan."
---

I'm on the Pro plan and mostly use Opus 5.5 at medium effort. When Fable 5.2 came out I tried it once, and used the occasion to go through the settings, subagents and CLAUDE.md under `~/.claude` against Anthropic's [article on choosing a model](https://claude.dev/blog/which-claude-model-should-you-build-with/). Below are the changes and the reasons for them. The config can be copied as is.

## Opus at default effort for the main session

The article recommends starting everyday work on Opus 5.5 at its default effort, medium, which matches how I already work. Fable 5.2 costs twice as much per token as Opus, so I keep it for large refactors, migrations and architecture planning.

My `settings.json` still had a global `effortLevel: "high"` from the Opus 5 days. The docs say Opus 5.5 at medium is about equal to Opus 5 at high, so I deleted the line and let each model use its own default.

When a task goes badly I follow the order the article gives. First I check that the model can verify its own work, with a test or a build. Then I raise effort one level. Moving to a bigger model comes last.

## Cheap work goes to small-model subagents

A subagent runs in its own context and is billed at the rate of the model it runs on. A subagent with no model set inherits the main session's model, and so does the built-in Explore. I made two changes.

The first sets a default for subagents that don't specify a model:

```jsonc
// ~/.claude/settings.json
{
  "env": {
    "CLAUDE_CODE_SUBAGENT_MODEL": "sonnet"
  }
}
```

The second defines my own subagent named Explore, which overrides the built-in one and runs searches on Haiku:

```markdown
<!-- ~/.claude/agents/Explore.md -->
---
name: Explore
description: Read-only search agent for broad lookups of files and code locations. Returns conclusions only.
disallowedTools: Edit, Write, NotebookEdit, Agent
model: haiku
omitClaudeMd: true
---
```

I split the work by how much a mistake costs. Finding files, reading logs and summarizing docs produce errors that are easy to spot, so they can go to Haiku. Decisions that need judgment stay in the main session.

| Subagent | Model | Effort | Job |
| --- | --- | --- | --- |
| Explore | haiku | default | Search and locate code |
| researcher | haiku | medium | Read docs and web pages, return conclusions |
| coder | sonnet | medium | Implement an agreed plan |
| reviewer | opus | medium | Review changes against the plan |

## A research agent has to be read-only for real

My researcher only had `Edit` and `Write` disabled. The rule against running commands with side effects lived in the prompt. The agent could reach the web and run Bash, so a line on a web page saying "run this command" might have been obeyed.

I added `Bash` and `PowerShell` to `disallowedTools`. It reads local files with Read, Grep and Glob. When I send it to look for skills, plugins or MCP servers, it reports the source, the maintainer, the last update and the permissions required, and I decide whether to install.

## A running session does not reload config

After I changed the launch arguments of the chrome-devtools-mcp plugin, I restarted its server process inside the current session. It came back with the old arguments. Plugin config is read when the session starts and is not read again. To verify the change without opening a new session, I had to launch the server separately with the new arguments and send it MCP requests.

I added two arguments this time. `chrome-devtools-mcp@latest` makes npx fetch the newest version on every start. `--ignoreDefaultChromeArg=about:blank` removes the blank page that Puppeteer adds by default when it launches Chrome.

## When to end a session

Every turn resends the whole conversation. It is usually cheap because the earlier content hits the cache, and a cache read costs about one twentieth of normal input. Once the cache has expired, the next message writes the whole conversation to the cache again, and that turn is expensive. The article's figures: with 150K tokens of context a turn's cache read costs about $0.03, and with 20K it costs about $0.004.

The lesson I had written down was "never send another message after a task is done", and that was too strict. A follow-up sent right after the work is cheap and belongs in the same session. I open a new one when any of these holds:

- The new request does not depend on anything this session found or decided.
- The deliverable is finished and verified, and the conclusions are in code, docs or memory.
- I'm coming back after a long gap and the context is already large.
- I want to switch models. The cache is per model, so switching rewrites everything.
- The model starts repeating work or citing conclusions that are out of date.

At the end of each task I write the current state and the next step into the project docs, so a new session can pick up after reading them.

## Limits and trade-offs

- When Haiku misreads a search result, the main model opens the wrong file and wastes a turn. In a large repo or one with messy naming, Sonnet is the safer choice for Explore.
- `@latest` is unpinned, so a new release runs straight away in a debug browser that holds my logins.
- This setup is sized for Pro limits. With more headroom, letting subagents inherit the main model is reasonable.
- `/doctor` checks settings and CLAUDE.md and proposes trims. `/doctor prompt-audit` finds instructions written for older models and references to files that don't exist. Both have to be run by hand.