Claude Opus 5 Output Style: Kill the Jargon Wall

I asked Claude Opus 5 a boring question:

Why had a client's email open rate dropped month over month?

The answer was technically useful.

It also arrived wrapped in enough terminology—MPP, send-time optimization, geo signals, device data, unique opens—that I had to translate it before I could send it to a marketing manager.

That is the frustrating part of Opus 5.

The model can be right and still make you do editorial work after the answer arrives.

Anthropic itself now documents this behavior. Its current prompting guidance says Claude Opus 5 is an exception to the newer Claude family's generally concise style: its default user-facing responses tend to run longer than earlier models, and changing effort does not reliably make the visible response shorter. Anthropic recommends prompting explicitly for conciseness instead.

That means there are really two problems to solve:

Verbosity: Claude says more than you need.

Jargon density: Claude assumes more domain knowledge than your reader has.

Those sound similar.

They need different controls.

And as of September 2026, Claude Code gives you much better controls than repeatedly typing:

Be concise and explain this simply.

The right setup is a combination of:

• built-in output styles;
• custom output styles;
• skills;
• CLAUDE.md;
• and, occasionally, a one-off prompt.

The important part is knowing which layer should own which behavior.

First: Opus 5 Really Is More Verbose

This is not just community perception.

Anthropic's current model guidance explicitly calls out Opus 5's response length.

Claude's newer models generally became more direct and natural, but Anthropic describes Opus 5 as an exception on verbosity. Lowering effort does not reliably reduce the amount of user-facing prose. If you want shorter visible answers, Anthropic recommends asking for that directly.

That distinction matters.

effort primarily controls how much work Claude spends reasoning about the task.

It is not a reliable "talk less" slider.

You can therefore have:

Low effort + long answer

or:

High effort + concise answer

depending on how you steer the final response.

That is useful because I do not want to make Claude think less just because I want it to speak more clearly.

Verbosity Also Has a Cost

Claude Opus 5 currently costs:

• $5 per million input tokens
• $25 per million output tokens

through the Claude API. Thinking tokens are also billed as output tokens.

That does not mean every Claude Code user receives a direct per-token invoice—subscription plans have their own usage model.

But for API workloads, unnecessary output has a direct dollar cost.

And everywhere, it has an attention cost.

Suppose two answers are equally correct.

One takes 180 tokens.

The other takes 900.

The second response costs more through a metered API and takes longer for a human to inspect.

That becomes especially painful when you are supervising several Claude Code sessions.

The problem is not simply:

Claude writes too much.

It is:

Claude spends tokens and human attention on words that do not improve the decision.

Before Building Anything: Try the Built-In Concise Style

This is the first thing I would do today.

Claude Code added a built-in Concise output style in v2.1.237.

Its purpose is straightforward: Claude leads with the result and removes much of the preamble and narration while still performing the underlying task thoroughly.

If your complaint is primarily:

Stop narrating everything and give me the result.

you may not need a custom style at all.

Switch to Concise and test it first.

That is a better starting point than maintaining your own 40-line prompt for behavior Anthropic now ships directly in the product.

Important September 2026 Update: /output-style Is Back

This article originally contained what was, at the time, correct advice:

The /output-style command was removed. Use /config.

That has already changed.

Claude Code v2.1.269, released September 11, 2026, reintroduced:

/output-style [name]

for listing and switching output styles, including remote, cloud, and other headless sessions.

So on a current Claude Code installation, you can use:

/output-style

or switch directly where supported:

/output-style Concise

There is an interesting documentation wrinkle here.

Anthropic's main Output Styles documentation still says the standalone command was deprecated in v2.1.73 and removed in v2.1.91, recommending /config instead.

The September 11 changelog is newer.

So as of this writing:

Current CLI changelog: /output-style is back.

Current main docs page: still documents its earlier removal.

This is exactly why version-specific Claude Code posts need dates.

You can also continue using:

/config → Output style

or set the style directly in settings:

{
  "outputStyle": "Concise"
}

Those remain valid mechanisms.

What an Output Style Actually Does

An output style changes how Claude responds, not what Claude knows.

Anthropic describes output styles as direct modifications to Claude Code's system prompt controlling things such as:

• role;
• tone;
• format;
• communication behavior.

That makes them appropriate when you keep asking for the same response behavior on every turn.

For example:

Always explain architecture with a diagram.

That is an output-style problem.

So is:

Write client-facing explanations in plain English.

Or:

Lead with the conclusion and remove narration.

By contrast:

This Laravel repository uses PostgreSQL and Redis.

That is not an output-style instruction.

It is project context.

Put it in CLAUDE.md.

CLAUDE.md vs Output Style vs Skill

This distinction is the foundation of the whole setup.

Anthropic's own documentation gives roughly this separation:

That is much more useful than putting everything into one giant CLAUDE.md.

Use CLAUDE.md for Facts

Examples:

Use PostgreSQL.

This project follows a service-repository pattern.

Run Pest after backend changes.

Never edit deployed migrations.

Use Output Styles for Communication Defaults

Examples:

Lead with the answer.

Define unfamiliar acronyms.

Use plain professional English.

Avoid unnecessary preamble.

Use Skills for Situational Transformations

Examples:

Rewrite the previous answer for a client.

Compress this into three decision points.

Explain the missing prerequisite before continuing.

That separation makes the system easier to maintain.

The Most Important Output-Style Setting Most Tutorials Miss

There is one current behavior you should know before creating your own style.

By default, a custom output style can leave out Claude Code's normal software-engineering instructions.

Anthropic explicitly warns that these built-in instructions include behavior around:

• scoping changes;
• comments;
• security issues;
• verification;
• testing and completion behavior.

If you are creating a style merely to change how Claude communicates while it still codes, add:

keep-coding-instructions: true

Anthropic's current documentation explicitly recommends this.

Without it, you may solve your writing problem and accidentally change Claude's engineering behavior.

That is not the trade I want.

Build a Plain-English Style, Not a "Dumbed-Down" Style

I originally called my style ELI5.

The intent was good.

The label is slightly misleading.

What I actually want is not:

Explain everything as though the reader were five.

I want:

Explain it to an intelligent adult who does not already know this particular domain.

Those are different things.

A marketing manager does not need childish analogies.

They need MPP translated once.

A founder does not need networking explained from first principles.

They need the difference between a load balancer and reverse proxy made explicit if the distinction affects the decision.

So I now prefer a Plain English or Client Ready output style.

A Better Opus 5 Plain-English Output Style

Create:

~/.claude/output-styles/plain-english.md

with:

---
name: Plain English
description: Direct, jargon-light explanations for smart non-specialists.
keep-coding-instructions: true
---

# Communication style

Write for an intelligent reader who may not know this domain.

Preserve technical accuracy. Reduce translation work.

## Answer order

Lead with the direct answer.

Then explain only the reasoning needed to understand or act on it.

Put caveats next to the claim they qualify instead of collecting them in a long disclaimer section.

## Technical terms

Use the correct technical term when it improves precision.

When a term or acronym is likely to be unfamiliar, explain it briefly the first time.

Example:

MPP (Apple's Mail Privacy Protection)

Do not replace precise technical vocabulary with vague words just to sound simple.

## Language

Prefer:
- common words
- active voice
- concrete verbs
- one main idea per sentence
- consistent terminology

Avoid:
- unnecessary jargon
- synonym swapping for the same concept
- filler introductions
- repeated conclusions
- phrases such as "it's important to note"
- corporate adjectives that add no information

## Length

Be as short as the task allows without dropping a condition, exception, warning, or step that changes the answer.

Do not shorten by removing information that affects the decision.

## Closing

Do not automatically add:
- a recap
- next steps
- an offer to do more
- a summary of the summary

Add them only when they materially improve the answer or the user requests them.

This style solves a different problem from Concise.

Concise: reduces narration.

Plain English: reduces translation effort.

Sometimes I use one.

Sometimes the other.

Why I Borrow From Simplified Technical English

Part of this style is inspired by ASD-STE100 Simplified Technical English.

ASD-STE100 originated in aerospace technical documentation, where ambiguity can create real operational risk.

The current Issue 9 was released January 15, 2025. Its writing rules emphasize practices such as:

• use words consistently;
• use approved meanings;
• avoid unnecessary jargon;
• keep terminology stable;
• prefer short, understandable technical terms.

I would not claim that the custom style above produces strict ASD-STE100-compliant text.

It does not enforce the full controlled dictionary or every formal rule.

It is STE-inspired.

That distinction matters.

What I want from STE is the principle:

A technical explanation becomes easier to understand when one thing keeps one name and sentences avoid unnecessary ambiguity.

That maps extremely well to AI output.

Do Not Put Hard Word Limits in the Global Style

I learned this the annoying way.

My first attempt said things like:

Maximum 150 words.

Never use more than three bullets.

Keep every answer to one screen.

It worked beautifully until I asked a question whose correct answer required six conditions.

Then it became concise by dropping information.

That is the wrong optimization.

A database migration with seven required stages is seven stages long.

A security warning with three exceptions needs three exceptions.

A yes/no answer with a legally important condition should not become an unconditional yes because the model is chasing a word limit.

The better rule is:

Global style controls clarity.

Skills control situational length.

That is where my /quick, /bro, and /wait-what commands come in.

Current Claude Code Skills Work Differently Than the Old Examples

The first version of this article used frontmatter like:

invocation: user

Do not copy that now.

Claude Code's current skills system uses:

disable-model-invocation: true

when you want a skill to run only when you invoke it manually.

By default:

• you can invoke a skill;
• Claude can also invoke it automatically when relevant.

For a manual transformation such as /quick, I do not want Claude deciding on its own that I apparently need a shorter explanation.

So I explicitly disable model invocation.

Skill 1: /bro — Make the Last Answer Human

Create:

~/.claude/skills/bro/SKILL.md

---
name: bro
description: Rewrite the previous answer in clear everyday professional language without losing facts.
disable-model-invocation: true
---

Rewrite your immediately previous answer for an intelligent person who does not work in this domain.

Preserve every fact, condition, and warning that changes the meaning.

Lead with the point.

Replace avoidable jargon with common language.

For technical terms that must stay, define them briefly.

Remove narration, repeated conclusions, and unnecessary setup.

Do not apologize for the previous answer.

Output only the rewritten answer.

Then:

/bro

That is the command I want when I understood the answer but cannot forward it to somebody outside engineering.

Skill 2: /wait-what — Explain the Missing Assumption

Sometimes jargon is not the real problem.

Claude says:

The worker is starved because the consumer group is rebalancing after lease expiry.

You can translate every individual word and still not understand the system.

The missing information is the prerequisite mental model.

Create:

~/.claude/skills/wait-what/SKILL.md

---
name: wait-what
description: Re-explain the previous answer by identifying and filling the background knowledge it assumed.
disable-model-invocation: true
---

I did not understand your previous answer.

Identify the most important background assumption you expected me to know.

Explain that missing concept first in plain language.

Then explain the original answer again using that context.

Use one concrete example when it helps.

Do not merely substitute simpler synonyms.

Preserve technical accuracy.

Then:

/wait-what

This is different from /bro.

/bro changes the register.

/wait-what repairs the missing conceptual bridge.

Skill 3: /quick — Compress Only When I Ask

For actual compression, use a separate manual skill.

Create:

~/.claude/skills/quick/SKILL.md

---
name: quick
description: Compress the previous response into a requested number of decision-relevant points.
argument-hint: "[number]"
disable-model-invocation: true
---

Compress your previous response into exactly $0 numbered points.

If $0 is missing, use 3.

Rules:

- Order points by importance.
- Use one sentence per point where possible.
- Preserve any condition or exception that changes the decision.
- Remove examples unless they are necessary to understand the point.
- Do not repeat the same idea in different words.

If the requested number would force you to remove information that changes the decision, say:
"That limit would remove decision-relevant information."

Then use the smallest honest number of points.

Output only the result.

Then:

/quick 3

or:

/quick 5

This gives me compression when I want compression.

It does not permanently force every technical explanation through a three-bullet funnel.

Skills Are Cheap Until You Use Them—But Not Completely Free Forever

Claude Code's current skills system is designed for progressive disclosure.

The skill description is what helps Claude discover available skills.

The full SKILL.md body normally enters the conversation only when the skill is invoked.

If you set:

disable-model-invocation: true

Claude cannot auto-trigger it, and Anthropic says its description is not kept in normal model context either.

That is useful for manual helper commands.

One current detail is worth knowing, however:

once you invoke a skill, its rendered instructions stay in the conversation for the rest of that session.

Claude Code does not re-read an identical skill every turn; it keeps that instruction context around, and auto-compaction can carry invoked skills forward within its budget.

So small skills are still better.

Do not put a 200-page writing manual inside /bro.

The entire point is to create a tiny reusable behavior.

Skills Now Hot-Reload

Another useful current improvement: Claude Code watches skill directories for changes.

When you edit an existing SKILL.md, Claude Code can pick up the modification during the current session rather than requiring a full restart.

That makes tuning these small commands much easier.

Try /bro.

See what still annoys you.

Edit five lines.

Try again.

That is a much better workflow than designing a giant "perfect AI communication framework" before using it.

Personal Skills vs Project Skills

Where you store the skill determines its scope.

Personal

~/.claude/skills/bro/SKILL.md

Available across your projects.

Good for:

• /bro
• /quick
• /wait-what
• personal writing transformations.

Project

.claude/skills/client-summary/SKILL.md

Available inside that repository.

Good for tasks tied to a specific team's workflow.

Anthropic also supports enterprise-managed and plugin-distributed skills.

For these communication helpers, I prefer personal scope.

They describe how I consume information, not how the repository works.

What About CLAUDE.md Drift?

The original version of this article argued that style instructions in CLAUDE.md "drift out of attention" while output styles do not.

The modern explanation is more precise.

CLAUDE.md and output styles enter the system in different ways.

Anthropic says output styles directly modify the system prompt, while CLAUDE.md is added as project/context instruction. Output styles also receive adherence reminders during the conversation.

That gives an output style stronger and more appropriate placement for persistent response-shape behavior.

It does not mean CLAUDE.md becomes useless later in a session.

The important issue is semantic ownership.

If something is a project fact, it belongs in CLAUDE.md.

If it is the default way every answer should sound, it belongs in an output style.

That is the cleaner architecture.

Output Styles Do Not Automatically Apply to Every Subagent

One subtle limitation:

Anthropic says output styles apply to the main conversation.

A normal subagent has its own system prompt, so your selected output style does not automatically change how every subagent responds. Forked contexts are an exception because they inherit the parent system prompt.

This matters in agentic workflows.

You may configure beautifully concise main-session output and still see dense internal reports from specialized agents.

Often that is fine.

The user-facing session can summarize those results in your selected style.

But do not assume a global style is a universal policy for every agent process.

Why I Would Not Ban Technical Terms

There is a bad version of "plain language" where everything precise gets replaced with vague language.

Do not do that.

Consider:

The system has a race condition.

Turning that into:

Sometimes two things happen at the same time and cause a problem.

may be easier to understand initially.

It is also less useful if the reader needs to discuss the bug with an engineer.

The better version is:

The system has a race condition: two operations can run at the same time and produce the wrong result.

You keep the term.

You provide the bridge.

The reader now learns vocabulary instead of being protected from it.

That is what I want from a useful output style.

Output Style Is Not the Same as Audience

Another trap: one permanent style cannot automatically know whether the next answer is going to:

• another engineer;
• a CEO;
• a client;
• a six-year-old;
• a security analyst.

Audience still matters.

For my engineering sessions, I often use Default or Concise.

For a client explanation, I switch to Plain English or invoke /bro.

For teaching, Explanatory may make more sense.

For learn-by-doing work, Claude Code's Learning style has an entirely different purpose.

The style is a lens.

It should not become a personality you force over every task.

The Built-In Styles Are Better Than Most People Realize

Claude Code's documented built-ins include:

Default

Normal software-engineering behavior.

Proactive

Claude moves more aggressively, makes reasonable assumptions, and prefers execution over stopping for routine decisions.

Anthropic explicitly notes that this is not the same thing as auto mode; your permission mode remains separate.

Explanatory

Adds educational insights about implementation choices and codebase patterns.

Learning

Uses a learn-by-doing approach and can ask you to implement selected portions yourself.

Concise

Added later in the 2.1.x series to reduce preamble and narration.

Before building something custom, ask whether one of those already solves 80% of the problem.

A custom style is maintenance.

Do not create maintenance for a feature that already exists.

A Better Decision Tree

Here is the setup I would recommend now.

"Claude talks too much."

Try:

/output-style Concise

on Claude Code 2.1.269+, or select Concise from the Output style menu.

"Claude uses too much unexplained technical vocabulary."

Use a Plain English custom output style.

"I usually want technical detail, but this answer needs to go to a client."

Keep your normal style and run:

/bro

"I genuinely did not understand the explanation."

Run:

/wait-what

"This is correct, but I need three decision points."

Run:

/quick 3

"Claude keeps forgetting a repository rule."

That is probably:

CLAUDE.md

not another output style.

Does Shorter Output Actually Save Money?

Through the API, yes—if it actually reduces output tokens.

Opus 5 output currently costs $25 per million tokens.

But there are two cautions.

First, a custom output style itself adds instructions to the system prompt, which increases input context. Prompt caching reduces that cost after the first request, but the instructions are not literally free. Anthropic explicitly notes this trade-off.

Second, "shorter" is only cheaper if it does not create retries.

A 200-token answer that omits a critical condition and requires another 800-token correction is not efficient.

The metric I care about is:

tokens per accepted answer

not:

tokens per first answer.

The same rule applies to human attention.

Why Benchmarks Do Not Capture This Well

Opus 5 can become more capable on benchmarked tasks while still feeling worse to use for a particular person.

There is no contradiction.

A benchmark may measure:

• whether a task was solved;
• whether tests passed;
• whether an answer matched a reference;
• whether an agent completed a workflow.

It usually does not directly measure:

How much editing did a marketing manager need before forwarding this explanation?

or:

How many seconds did an engineer spend locating the actual answer inside the prose?

Those are interface-quality questions.

Output styles let you modify part of that interface yourself.

That is why I increasingly think of them as part of agent UX, not just prompt customization.

Your AI Stack Has an Output Layer

Most AI setups obsess over:

• models;
• context windows;
• MCP servers;
• tools;
• memory;
• agents;
• skills.

Then they accept the model's default communication style.

That is strange.

The final output is the part the human has to consume.

If the agent saves ten minutes of coding and creates eight minutes of reading and rewriting, the stack is not as efficient as the benchmark suggests.

Your communication layer deserves configuration too.

For me, that layer now looks like:

Model
   ↓
Reasoning / tools
   ↓
Project context (CLAUDE.md)
   ↓
Default response behavior (output style)
   ↓
Situational transformation (skill)
   ↓
Human

Different layers solve different problems.

That is much more maintainable than one giant prompt containing everything.

What I Would Set Up in the Next 15 Minutes

First, update Claude Code and check:

claude --version

If you are on v2.1.269 or later, test:

/output-style

The September 11 changelog says that command has been restored.

Then try the built-in Concise style.

Ask Opus 5 something that previously produced too much narration.

If that solves the issue, stop.

Do not over-engineer it.

If the answer becomes shorter but still requires translation, add the Plain English style above with:

keep-coding-instructions: true

Then add /bro.

Those two additions cover most of the problem for me.

Only add /wait-what or /quick after you notice yourself repeatedly typing the correction they represent.

That is my rule for Claude customization:

If I type the same corrective instruction three times, it probably deserves a reusable control.

~/.claude/output-styles/

.claude/output-styles/

disable-model-invocation: true

The Bottom Line

Claude Opus 5's jargon wall is not really one problem.

It is three.

Too much narration.

Use Concise.

Too much unexplained domain language.

Use a plain-language output style.

Too much information for this particular moment.

Use an on-demand compression skill.

Do not force all three problems into one giant prompt.

And do not put every instruction into CLAUDE.md.

Claude Code now gives each type of instruction a better home:

Project facts → CLAUDE.md

Persistent response style → output style

Reusable transformation → skill

One-off constraint → prompt

That separation is the real upgrade.

The model does not necessarily need to become less intelligent.

It needs a better interface between its intelligence and the human reading the answer.

Once I stopped treating Claude's default voice as something I had to accept, the difference was immediate.

I no longer read every response like an editor looking for the useful sentence.

I read the answer.

Then I move on.

That is what a good output layer should do.

Build a Better Claude Code Setup

I work with Claude Code, AI agents, context engineering, skills, plugins, and production development workflows.

If you are building a Claude Code environment for yourself or a team, the highest-leverage improvements are often not another model or another MCP server. They are the small controls that reduce repeated instructions, make outputs easier to consume, and put each type of context in the correct layer.

Related:

• Claude Opus 5 Prompting Shift
• Claude Code Agent Skills Guide
• Claude Opus 5 Benchmarks Breakdown
• Caveman Skill: LLM Token Savings

Let's Work Together

Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io