Practical Claude Code configuration for the tasks you actually repeat every day
The Vibe Coder’s Token-Saving Settings Guide that can save lots of token consumption for your daily work0. Why vibe coding is where token waste compoundsVibe coding is building fast and mostly conversationally, letting the assistant hold the plan that means many short sessions per day instead of a…
The Vibe Coder’s Token-Saving Settings Guide that can save lots of token consumption for your daily work0. Why vibe coding is where token waste compoundsVibe coding is building fast and mostly conversationally, letting the assistant hold the plan that means many short sessions per day instead of a few long ones, each re-explaining project conventions, re-opening the same files, and re-granting the same tool access.None of that is wrong; it’s just where the token bill actually lives. A vibe coder rarely reads a scanner’s raw JSON, rarely diffs a recon tool’s full output, and almost never turns off the MCP connectors they aren’t using this session.So, every one of those things stays in context anyway, on every turn, for free-riding cost. This is the practical companion to “Every Token Counts”, which covers the underlying architecture (caching, isolation, compaction).This article is the settings you actually type in, organized around five workflows: coding, secure review, pentesting/recon, diagramming, and cross-tool ops, and four more security-engineer workflows, the cases where optimizing actively hurts, and what model routing does and doesn’t do for you automatically.This image would give you a glimpse of what we are going to discuss in this article.1. General coding loop (write / edit / debug / refactor / test)What an unoptimized session looks likeEvery new chat re-explains “we use pytest with fixtures in conftest.py, run make lint before commit, don't touch legacy/" verbatim, every time, because it's not written down anywhere durable.A file-search sub-task ("find every place this function is called") runs inline, dumping every matched file's content into the main conversation.The whole session runs on Opus by default because nobody switched it. A npm test run with a 400-line failure log gets pasted whole into context by the shell tool.Let Fix itSkills for repeated workflows. A .claude/skills/run-tests/SKILL.md or .claude/skills/release-checklist/SKILL.md costs only its name + description (≤1,536 chars) in context until invoked; unlike a CLAUDE.md paragraph explaining the same thing, which is loaded on every single turn regardless of relevance.Lean CLAUDE.md, correctly scoped. Project-level CLAUDE.md (repo conventions, build/test commands, architectural notes) vs. user-level ~/.claude/CLAUDE.md (personal preferences that apply across all projects). Keep both short: this file is concatenated into context on every turn of every session in that scope, with no lazy-loading.Move anything workflow-shaped (a checklist, a multi-step procedure) into a skill instead; keep CLAUDE.md to facts a model needs on every turn (stack, conventions, hard constraints).Explore-style read-only subagents for search-heavy sub-tasks. Claude Code ships a built-in Explore agent pattern for file discovery/code search: read-only tools only (Write/Edit denied), model inherited from the main conversation.Delegate "find all callers of X" or "trace how this config flows through the codebase" to it, the file reads and grep noise stay in the subagent's isolated context, and only the summary returns [source: code.claude.com/docs/en/sub-agents.md].tools:/disallowedTools: on custom agents. A refactor-suggestion agent needs Read, Grep, Glob and nothing else:---name: code-improverdescription: Scans files and suggests improvements for readability, performance, and best practicestools: Read, Grep, Globmodel: sonnet---This is a real, doc-verified example [source: code.claude.com/docs/en/sub-agents.md]. Omitting Write/Edit isn't just a safety rail, every tool outside the allowlist is never declared to the model, so its schema tokens are never sent.Model selection per task. Pin narrow agents to model: sonnet (routine edits, mechanical refactors) and reserve Opus for genuinely hard architecture/debugging calls, either via agent frontmatter model: opus or /model mid-session switching. Resolution order: per-invocation parameter → agent frontmatter → CLAUDE_CODE_SUBAGENT_MODEL env var → main conversation's model [source: code.claude.com/docs/en/sub-agents.md].bashOutputMaxChars caps how much of a shell command's stdout/stderr is inlined into context, a verbose npm test failure log gets truncated instead of consuming your whole budget [source: code.claude.com/docs/en/settings-reference.md].maxTurns on any autonomous/background coding agent (an agent you kick off and let run, e.g. "fix all the lint errors") bounds a runaway retry loop; on hitting the limit the agent returns partial output rather than continuing indefinitely [source:code.claude.com/docs/en/sub-agents.md].Quick win: move your project’s “how we test / how we deploy” paragraph out of CLAUDE.md and into a skill. That’s zero-cost on every turn that isn’t a test/deploy turn and CLAUDE.md is loaded on all of them.Same coding task, same outcome: the top path pays full context cost on every turn; the bottom path pays only for what that turn actually needs.2. Secure code review / SASTUnoptimized session“Review this whole repo for security issues” — every file gets read into the main context, the SAST tool’s raw JSON output (often thousands of lines for a real codebase) gets pasted in for triage, and each finding gets written up as unstructured prose that re-derives the same boilerplate (severity language, remediation phrasing) each time.Fixes:Scoped review skills, not “review everything.” Phase-scoped commands — auth-only, business-logic-only, dependency-only, header-only passes — each load a narrower instruction set and reason over a narrower slice of code than an unscoped full-repo pass. Narrower scope means fewer files read into context and a tighter, more consistent finding set per pass.Review diffs, not full files. git diff against the base branch is almost always what a review actually needs — the lines that changed, not the whole file tree. Point the review skill/agent at the diff by default and fall back to full-file reads only for the specific files a diff touches, when surrounding context genuinely matters (e.g., checking whether a new call site is inside an existing auth check).Delegate the scanner run + triage to a subagent. SAST tool output (Semgrep/Bandit/etc.) is typically large, repetitive JSON. Run the scanner and do first-pass triage (dedupe, drop known false-positive patterns, rank by severity) inside an isolated subagent — the raw scanner output never touches the main conversation; only the triaged, condensed finding list returns [source: base article §3 subagent/fork pattern].Structured findings output over prose. A ReportFindings-style fixed schema (title, severity, location, evidence, remediation) is shorter per finding than free-form prose, produces consistent output length across findings, and avoids the model re-generating the same explanatory boilerplate ("This is a security concern because...") on every single item.Quick win: default your review skill to git diff main...HEAD instead of the repo root. On a mid-size PR this alone can cut what's read into context by an order of magnitude.3. Pentesting, recon & other security workflowsThe recon pattern below applies to scanning against targets you’re authorized to test; it’s tool-agnostic and doesn’t depend on which specific scanner you run. The same shape a tool or corpus produces far more output than the decision actually needs. recurs across five security-engineer workflows; they all reuse the same handful of mechanisms: subagent isolation, diff/scope narrowing, parallel batching, model routing, tools: allowlists, bashOutputMaxChars.3.1 Pentesting / authorized reconUnoptimized session: an nmap -A or dirbuster run against a target pastes its full raw output, often hundreds to thousands of lines of banner grabs, wordlist hits, and noise straight into the main conversation, then each subsequent recon step is a new inline tool call that re-sends the growing transcript as context.Fixes:Always isolate recon tool output in a subagent/worker. Scan output is a textbook case of “token-heavy work that produces a condensed decision”, the same isolation principle as SAST triage. Run the enumeration tool inside a worker, have it summarize (open ports + service versions, discovered paths, notable headers) and return only that summary [source: base article §3, orchestrator/worker pattern].Batch independent recon calls in parallel. If port scan, subdomain enumeration, and header inspection don’t depend on each other’s output, issue them as parallel tool calls rather than sequential round-trips , each round-trip re-sends the accumulated conversation as context, so serial execution multiplies that overhead by the number of steps.Model routing by task type. Mechanical enumeration and output parsing (turning a scan into a structured list) doesn’t need your most expensive model; route it to a cheaper/faster one (model: sonnet or a narrow-task alias on the recon subagent) and reserve escalation to a stronger model for the step that actually requires judgment: chaining findings into an exploit path, assessing exploitability, or writing the attack narrative.Quick win: never let a scan tool’s stdout hit the main conversation directly, route every recon tool call through a subagent whose job is “run this, summarize it, return the summary.”3.2 Incident / log triageUnoptimized session: you grep a 2 GB access log or paste a SIEM CSV export into the chat and ask "what happened here." The raw matches thousands of near-identical lines and land in the main conversation, and every follow-up question ("now correlate that with the auth log") re-sends all of it as context before the model does any new work. Two or three pivots in, most of your window is log lines you already reasoned past.Fixes:Isolate the search in a subagent. A triage worker with tools: Bash, Read, Grep runs the greps and correlations in its own context and returns a timeline: timestamps, source IPs, the specific lines that matter , not the match set [source: base article §3, orchestrator/worker pattern].bashOutputMaxChars as the backstop. Even inside the worker, a mis-scoped grep can dump the whole file; the cap truncates it rather than blowing the worker's context too [source: code.claude.com/docs/en/settings-reference.md].Filter in the shell, not in the model. grep | cut | sort -u | head costs zero model tokens. Let the tool do the reduction the model would otherwise pay to read.Batch independent pivots. Auth log, WAF log, and process-execution log for the same time window don’t depend on each other — issue them as parallel calls, not three sequential round-trips each re-sending a growing transcript.Quick win: never cat a log. Pipe through sort -u/head first — de-duplication alone often cuts an incident's log volume by an order of magnitude before a single token is spent.3.3 Secrets scanning across repo historyUnoptimized session: a full-history scan (gitleaks/trufflehog across every commit) on a repo with years of history emits thousands of findings, most of them the same rotated test key committed and reverted forty times. Pasted whole into the main conversation, that output is both enormous and mostly noise — and it carries a second problem SAST output doesn't: a secrets scan's raw output contains the secrets. Everything it prints becomes conversation history.Fixes:Same isolation principle as SAST triage, with sharper motivation. Run the scan inside a subagent and have it return findings as locations and types — file, commit, secret class, whether it’s live — not the secret values. Raw candidate strings stay in the worker’s isolated context instead of persisting in your main transcript [source: base article §3].Structured findings over prose, as in §2: a fixed schema (path, commit, rule, verified true/false) makes deduping thousands of hits of the same rotated key mechanical.Split verification from enumeration by model. Grouping and deduping raw hits is mechanical work for a cheaper model; deciding whether a live credential in a public repo is an incident is not. See §7a before you route the second half anywhere cheap.Quick win: have the secrets-scan subagent return path:commit:rule:verified rows, never the matched string. Cheaper and it keeps credentials out of your transcript.3.4 Compliance / audit evidence gatheringUnoptimized session: “gather evidence for the access-control control set” turns into thirty sequential lookups — a Confluence page, a Jira ticket, an IAM policy dump, a screenshot description — each a separate round-trip re-sending everything gathered so far, and each full document read inline when what the control needs is one paragraph.Fixes:Batch the read-only lookups. Evidence gathering is almost entirely independent reads; §5’s parallel-batching argument applies directly and is the single biggest win here.Scope MCP servers to the systems in scope. An audit pass touching Jira and Confluence has no reason to carry the email or cloud-console tool schemas — mcp__jira__* in the allow list, the rest denied [source: code.claude.com/docs/en/permissions].A skill for the evidence format. The mapping from control ID to “what counts as evidence” and the output shape is a durable procedure, not a per-turn fact — it belongs in a skill, invoked on audit turns only, not in CLAUDE.md [source: code.claude.com/docs/en/skills.md].But watch the compaction tradeoff. Audit evidence is the one workflow where the raw trail is the deliverable. See §7a.Quick win: one skill holding your control-to-evidence mapping turns “gather evidence for X” from a re-explained prompt into a one-line invocation.3.5 DAST / fuzzing loopsUnoptimized session: an iterative scan-observe-adjust loop, run the fuzzer, read the responses, adjust the payload, run again; where every iteration’s full output stays in the conversation. Iteration twelve is reasoning over eleven iterations of response bodies it has already drawn conclusions from, and an unbounded loop can keep going long after it stopped learning anything.Fixes:One isolated worker per iteration, not one context for the whole loop. Each iteration returns “payload class X produced a 500 on endpoint Y, here’s the response fragment that matters” — the full response corpus stays behind the subagent boundary [source: base article §3].maxTurns on the loop. A fuzzing agent is the canonical runaway-loop case; the ceiling returns partial output instead of iterating indefinitely [source: code.claude.com/docs/en/sub-agents.md].bashOutputMaxChars caps a single verbose scanner run the same way it caps a build log.Keep the iteration prompt stable. If the harness instructions don’t change between iterations, that prefix stays cache-eligible across the whole loop; rewording it per iteration forfeits the discount on every one.Quick win: set maxTurns on any fuzzing/DAST agent before you start it, not after you notice the bill.You can save this diagram for quick reference4. Diagramming (architecture / threat model / DFD)Unoptimized session: asking the model to “describe the architecture” in prose, then again, then again as the design shifts, each description is regenerated from scratch, verbose, and not reusable. Diagram style rules (“use this color for trust boundaries,” “always label data flows with the protocol”) get re-explained in the prompt every time because they live nowhere durable, or worse, get pasted into CLAUDE.md where they cost tokens on every unrelated coding turn too.Fixes:Generate diagram source, not prose descriptions. Mermaid syntax or Excalidraw JSON is a small, regenerable artifact — you can hand it back to the model for a targeted edit (“add a trust boundary around the payment service”) without regenerating the whole description from scratch, and it renders directly instead of requiring a human to translate prose into a picture.A dedicated diagramming skill, not CLAUDE.md. Diagram conventions (node shapes, boundary styling, labeling rules) belong in a skill invoked only when diagramming, not in CLAUDE.md where they’re loaded on every turn including ones that have nothing to do with diagrams. This is the same lazy-load argument as §1’s testing conventions, applied to a domain that’s naturally bursty (you diagram in short bursts, not continuously).Keep the diagram-generation prompt stable across iterations. If the skill’s system instructions/style guide don’t change between “draw the DFD” and “now add a trust boundary,” that shared prefix is cache-eligible — varying wording per request (even cosmetically) breaks the strict prefix match and forfeits the cache discount on every iteration [source: base article §2, cache mechanics].Quick win: if you find yourself typing the same “make trust boundaries dashed, external entities as rectangles” instruction more than once, that’s a skill, not a recurring prompt fragment.5. Mundane cross-tool tasks (email / Jira / Confluence / routine ops via MCP)Unoptimized session: every MCP connector you’ve ever configured (mail, Jira, Confluence, calendar, cloud console) stays enabled for every session, so their tool schemas are declared to the model on every call regardless of whether this session touches any of them.MCP tool schemas are billed like any other tool definition. A “check my inbox and triage” task reads every message inline into the main conversation instead of doing the enumeration elsewhere. Ten independent “what’s the status of ticket X” lookups run as ten sequential round-trips.Fixes:Scope MCP servers/tools per agent or session — don’t enable everything by default. The same tools:/disallowedTools: frontmatter mechanism that restricts coding-agent tools applies to MCP: mcp__, mcp____*, and mcp__* patterns let you allow or deny at the server or wildcard-tool level [source: code.claude.com/docs/en/sub-agents.md, verified live]. Settings-level permission rules support matching wildcard patterns for allow/deny lists — with one asymmetry worth knowing: a bare mcp__* wildcard is valid in deny/ask rules, but an unanchored allow rule like "mcp__*" is skipped with a warning and grants nothing; allow rules need an explicit server name (mcp__jira__* is fine, bare mcp__* is not) [source: code.claude.com/docs/en/permissions, verified live]:{ "permissions": { "allow": ["mcp__jira__*"], "deny": ["mcp__email__send_message"] }}A session doing pure code review has no reason to carry Jira and Confluence tool schemas into every call.Delegate multi-step triage to a subagent. “Check my inbox and triage” or “update these five Jira tickets” is exactly the enumerate-then-summarize shape that belongs behind a subagent boundary: the worker reads every message/ticket in its isolated context, and only the actionable decisions (what needs a reply, what ticket status changed) return to the main conversation [source: base article §3].Batch independent read-only lookups in parallel. Five independent Jira ticket reads or Confluence page fetches that don’t depend on each other’s results should be issued as parallel tool calls, not five sequential round-trips each re-sending the growing conversation.Turn off skills/MCP tools not relevant to the current task. A maximal, permanently-loaded toolset is the cross-tool equivalent of an unscoped SAST pass — convenient once, costly every turn after. Scope down to what today’s session actually needs.Quick win: if a session is pure coding, explicitly deny the Jira/Confluence/email MCP servers for that session rather than leaving them on “just in case.”6. Starter kit: settings.json / CLAUDE.md / agent frontmatterA realistic combined starting point. Field names/keys below are verified against current docs; numeric values are illustrative defaults to tune, not documented platform defaults — the settings reference page does not publish fixed default numbers [source: base article §4, note on settings-reference.md]..claude/settings.json (project-level):{ "autoCompactEnabled": true, "autoCompactWindow": 0.85, "bashOutputMaxChars": 8000, "skillListingBudgetFraction": 0.15, "skillListingMaxDescChars": 500, "permissions": { "allow": ["mcp__jira__*"], "deny": ["mcp__email__*", "mcp__confluence__*"] }}CLAUDE.md (project-level, kept lean, facts needed every turn only):# Project conventions- Stack: Python 3.12, FastAPI, pytest- Never touch `legacy/` without explicit approval- Full test/lint/release procedures: see skills (`run-tests`, `release-checklist`).claude/agents/code-improver.md (narrow, read-only, cost-bounded):---name: code-improverdescription: Scans files and suggests improvements for readability, performance, and best practicestools: Read, Grep, Globmodel: sonnetmaxTurns: 15---You are a code improvement specialist. For each issue you find, explainthe problem, show the current code, and provide an improved version..claude/agents/recon-worker.md (isolation for noisy scan output):---name: recon-workerdescription: Runs recon/enumeration tools and returns a condensed summary onlytools: Bash, ReaddisallowedTools: Write, Editmodel: sonnetmaxTurns: 20---Run the requested recon command. Return only: open ports/services withversions, discovered paths, and anything unusual in response headers.Do not return raw tool output.Token-LifecycleThe lifecycle is the whole point: CLAUDE.md is a recurring tax, settings.json is a one-time session cost, and skills/agents are pay-per-use — put content in the cheapest tier that still gets it applied when needed.7. Reference checklistImage speaks more than 100 words ;)Checklist table in case you want to keep it handy7a. When not to optimizeEvery technique in this guide trades some accuracy or completeness risk for token savings. Usually that trade is fine, a summarized scan result is as good as the raw one for deciding what to do next. Sometimes it isn’t, and in security work the failure mode is asymmetric: you don’t get a wrong answer; you get a confident answer with a finding quietly missing from it. This section is the exception list.You must understand when optimisation is not needed or to avoid.This is operational judgment, not vendor guidance. Nothing below is a documented Anthropic caveat or a published failure mode. It’s reasoning about where these mechanisms interact badly with security work, offered so you make the call deliberately rather than by default. Treat it as opinion to argue with, not fact to cite.The common thread: these techniques all reduce what the model sees, and they’re safe exactly when you already know what it doesn’t need to see. Early in any investigation, you don’t. Optimize the second pass, not the first.It’s not the optimisation that you needOne question decides most of §7a’s table: do you already know what the model doesn’t need to see? If not, every optimization below is a bet against your own uncertainty; pay full price until you know enough to bet safely.7b. Model routing: what’s automatic, what isn’tStart with the correction, because this is a common misconception: there is no automatic runtime model routing. No first-party Claude Code, API, or SDK feature inspects a task, judges its complexity, and silently picks a model for you.Every model choice traces back to something you configured — settings, agent frontmatter, an explicit parameter, or a prompt telling an orchestrator how to decide. If you’ve been assuming a hard task gets escalated on your behalf, it doesn’t.What does exist is two documented strategies for combining a cheap model with an expensive one [source: platform.claude.com/docs/en/about-claude/models/optimizing-for-cost-and-intelligence]:Advisor strategy. A lower-cost executor model runs the main loop and handles most turns; when it hits a decision needing deeper judgment, it consults a higher-intelligence advisor model, then continues. Most tokens bill at executor rates; only the consultations bill at advisor rates.Orchestrator strategy. A frontier model holds the loop, decomposes the task, dispatches subtasks to cheaper worker models, and merges results. The orchestrator’s own transcript stays short because the workers absorb the token-heavy exploration.One important nuance on the advisor strategy: it is not purely hand-rolled. Anthropic ships it as a server-side beta tool, add {"type": "advisor_20260301", "name": "advisor", "model": ""} to tools with the beta header advisor-tool-2026-03-01, and the whole strategy runs inside a single /v1/messages request: the executor emits the tool call, Anthropic runs the advisor inference server-side, and the executor continues with the advice. You write no orchestration code [source: platform.claude.com/docs/en/agents-and-tools/tool-use/advisor-tool].That’s still not automatic routing, and the distinction matters: the executor model decides when to call the advisor, exactly as it decides when to call any other tool.Nothing is measuring task complexity. You get a model-driven escalation decision, which is a different thing from a platform-driven one — and it’s only as good as the executor’s own judgment about when it’s out of its depth.Implementing routing yourself in Claude CodeInside Claude Code, the lever is the subagent model resolution order, where the per-invocation model parameter is the highest-priority override — above frontmatter model:, above CLAUDE_CODE_SUBAGENT_MODEL, above the main conversation's model [source: code.claude.com/docs/en/sub-agents.md]. An orchestrating agent can therefore pick a different model per subagent spawn, at spawn time.That’s the mechanism. The decision is a prompt you write. In the orchestrator’s instructions:When you delegate a sub-task, choose the subagent's model explicitly:- Mechanical work — parsing scanner output, deduping findings, reformatting into the report schema, enumerating files — spawn with a cheaper model.- Work requiring security judgment — severity assignment, exploitability assessment, exploit-chain construction, ambiguous business-logic review — spawn with the strongest available model.- If you are unsure which category a sub-task falls in, treat it as judgment work and use the stronger model. State which you chose and why.Be clear-eyed about what that is: a prompted heuristic, not a platform feature. It’s the orchestrator’s own reasoning, and it can be wrong — a sub-task that looks like mechanical extraction (“pull the affected parameters out of these findings”) can quietly require judgment (“…and drop the false positives”).The last rule in that snippet is default to the stronger model when the category is unclear is doing real work; without it the heuristic biases cheap, which is the wrong direction for security output.This is the orchestrator’s decision rule made visible — a prompt, not a platform mechanism. The “unsure → strongest model” branch is the safety valve; without it, ambiguous tasks default to cheap, which is backwards for security output.Which is the §7a point restated: routing to a cheap model is precisely the decision that needs the judgment-call framing from the previous section, not a blind complexity heuristic. The cost of a wrong route isn’t a higher bill, it’s a severity rating nobody questions.8. Related readingThis article assumes the underlying mechanics from “Every Token Counts” — A token-efficiency playbook for Claude apps: how prompt caching actually invalidates on prefix changes, why subagent isolation is architecturally the highest-leverage lever, and how compaction/context-window math works. Read that first if any of the “why” behind a setting here isn’t obvious from the “what.”9. This is what it looks like in my terminal:It tells me how much it’s gonna cost for some task, which model suggestion, etc and at the end of the task it shows how much it spent. It keeps me aware of the token consumption and get little satisfaction personally.What do you think about these optimisation tips? Any thoughts?This story is published under the Generative AI publication. Connect with us on LinkedIn and follow Zeniteq to stay in the loop with the latest AI stories. Let’s shape the future of AI together!Practical Claude Code configuration for the tasks you actually repeat every day was originally published in Generative AI on Medium, where people are continuing the conversation by highlighting and responding to this story.Source: Generative AI Pub — Published — Category: Image AI