Output styles — Tune verbosity

What it does

Output styles let you control how verbose Claude's responses are—from terse one-liners to detailed explanations. Claude Code ships with three built-in styles: Terse (minimal, code-focused), Balanced (default, task-oriented), and Detailed (explanations, context, reasoning). Each style tunes not just word count but also what Claude prioritizes: Terse skips pleasantries and summaries, Detailed adds background and thought process. You can also define custom styles in settings to match your exact preference—e.g., a "Research" style that always includes source citations, or a "Mentor" style that teaches more than it codes.

When to use it

Use Terse when you're in the flow: iterating fast, following up on work mid-session, or running commands you just reviewed. It cuts context weight and gets straight to changes. Use Balanced for most feature work—it's the sweet spot between speed and clarity. Use Detailed when learning unfamiliar code, debugging a tricky bug, or you need Claude to show its reasoning (especially useful before running risky commands). Custom styles shine when your team has conventions—e.g., a "PR review" style that always formats findings as inline comments, or a "compliance" style that never skips security rationale.

Switching mid-session is free: if you start with Terse but realize you're lost in a refactor, flip to Detailed for that context, then switch back once you're oriented.

Try it yourself

Open Claude Code settings and look for the "Output style" option. Cycle through the presets on a real task—run a small fix or ask a question in Terse mode, then re-run the same request in Detailed mode and compare the output shape. Once you feel the difference, try editing your personal settings to create a custom style that matches how you like to work. You can toggle between styles mid-conversation without losing context.

Gotchas

Terse doesn't mean faster. It reduces Claude's output length, but token usage is often higher because terse responses skip structure and examples, forcing you to ask follow-ups. Balanced often costs fewer tokens overall by getting context right the first time.

Custom styles can drift. If you define a "mentor" style with "always explain why," you'll get explanations even when you don't want them (e.g., during a sprint push). Periodically audit your custom styles against your actual workflow—delete styles you stopped using.

Output style is not the same as reasoning effort. A Terse response doesn't reduce thinking time; it just truncates the output. If you're debugging a complex bug, Detailed output helps because Claude can show more work, not because it thinks differently. Pair output styles with effort settings when you need both brevity and rigor.

Switching can break continuity. If you flip from Detailed to Terse mid-implementation, Claude loses context about why decisions were made. Switch at natural boundaries (after a feature is merged, before starting new work).