terse - makes Claude speak normally

I struggle with the way Claude Code speaks to me. Every single question comes back as an essay. Slogans, metaphors, a recap of what it just did, "it's not X, it's Y". Every. Single. Time.

Claude's own "concise" mode shortens it, somewhat, but keeps the the rest of the slop.

I tried system prompts, those got forgotten after a couple of turns. I tried looking for plugins but none consistently made Claude speak normally. Some where slash commands, other solved for token use, others solved for neurodivergence. None of them made Claude speak normally.

I just wanted to not read an essay and make Claude get to the point fast, every single time.

So I spent a few weeks nothing down every thing it did that annoyed me and what i want it say instead, and built a Plugin around that. It worked for me. If Claude speaks to you the same way, it is yours.

The rest of this README is co-written by Claude Code using the terse plugin. I take most of the credit, but none for the words.

A Claude Code plugin that cuts reply length in half and removes mannered prose. Fable 5.1: 46% fewer words, 51% lower cost. Opus 5.5: 54% fewer words, 32% lower cost. Measured on 20 prompts against a real codebase. The writing rules apply to replies, documents, commits and subagents. A context meter for the status line comes with it.

The tables use these terms.

• Vanilla is Claude Code with no CLAUDE.md, no plugins and no custom instructions.
• A style violation is a sentence that breaks one of the rules. An Opus 5 judge counts them by reading each reply against the rule list. Counts are per 1,000 words, so long and short replies compare.
• Metaphor is figurative wording where a literal phrase exists. "A 3,000-line merge gets a skim and a prayer" in place of "a 3,000-line merge gets a 10-minute read and no line-by-line review".
• An "X, not Y" reframe is a contrast used as a label in place of an explanation. "This is intent, not behavior" in place of "the docstring says X, the code does Y".
• A slogan is a short line that sounds like a principle and states no mechanism. "The decision is the feature."
• Cadence is rhythm built for effect, such as triads and punchline endings.
• Bloat is a sentence that adds no fact, including narration like "I'll look at the code now".
• First person is "I", "me", "my", "let me" and their contractions. Sentences whose subject is the writer.
• Output tokens are what the model wrote, thinking included. Output tokens are priced about five times higher than input tokens on Opus and Fable.

Measured on 12 public prompts, vanilla Claude Code against terse 1.1.0. Opus 5.5, effort high, one run each.

Tables for Fable 5.1, for Opus 5.5 at effort medium, and for the 1.0.0 rule text: docs/models. Method, prompts and the judge rubric: docs/benchmark.md.

Install

From the Claude directory: open the terse listing and select Add to Claude Code. The plugin is saved to your claude.ai account and downloads the next time you start Claude Code signed in to that account. In a running session, /reload-plugins loads it at once. Anthropic scans and reviews each version before the directory serves it.

From GitHub, in Claude Code:

/plugin marketplace add lowenbjer/claude-terse
/plugin install terse@terse

Both routes install the same files. The writing rules apply to every new session, after /clear, and to an existing session you exit and resume with claude --resume.

For the context meter, run /terse:install-meter once. It copies the 26-line meter script to the plugin's data directory, which plugin updates leave in place, and adds one statusLine entry to your ~/.claude/settings.json. The entry takes effect on save.

What you get

The rules are a reply shape, 22 rules and 18 before/after pairs, 877 words. The shape: one sentence with the answer, then a list or a table, then at most one caveat sentence, then stop. Every sentence has the topic as its subject: no "I", no account of what was checked or would be done. Bullets start with the fact, so no bold lead-ins and no label lines. Plain words in place of coined names. No em dashes, no slogans, no "X, not Y" framing, no self-labeling, no closing offers. Chat replies stop at 150 words unless you ask for a document or a walkthrough. A findings list gets one or two sentences per finding. A redo sends only the delta. Where a rule has a positive form, the text states the form ("The last sentence is a fact.") ahead of the ban. Full text: rules/RULES.md.

The rules ship as an output style. It applies while the plugin is enabled and is part of the main agent's system prompt. Subagents run their own system prompt, so a SubagentStart hook hands them the same text. No hook rewrites or blocks anything.

The reminder exists because the output style is the first part of the context. After 20 or 30 turns it is 100k tokens before the current prompt. The model's own recent replies become its nearest style examples. From there the replies show the answer in the last line, "I checked" sentences, dashes, "X, not Y" and slogans. A UserPromptSubmit hook adds the whole rule set, condensed to 576 characters, to every prompt next to your text. Cost per turn is about 145 input tokens. The text is rules/REMINDER.md.

The meter shows model name and context fill as a percentage. Green below 37%, yellow from 37%, orange from 49%, skull from 60%. The thresholds are set below the usual 50, 65 and 80 percent. Three studies show retrieval quality dropping well before a large window fills:

• Chroma's Context Rot report: 18 models, degradation from 50k tokens on a 200k window.
• NoLiMa: 11 of 13 models at half their baseline by 32k tokens.
• Lost in the Middle: content in the middle of a long context gets less attention than the start and end.

The thresholds are the three numbers near the top of statusline/context-meter.js.

Before and after

Prompt, run on Opus 5.5 with each setup: "We have a Flask API with a Postgres database. Requests time out under load once a day around 09:00. Where would you look first and why?"

Vanilla, 636 words:

Where I'd look first for the 09:00 timeouts

The 09:00 timing is the most useful clue. Before looking at any code, find out which of these two things is happening:

1. Traffic goes up at 09:00. The start of the workday brings logins, dashboards and syncs. That's a capacity problem.
2. Traffic stays flat but something else runs at 09:00. That's contention from a scheduled job.

Compare your request-rate graph at 09:00 with other hours. That one check tells you which half of the problem you're in.

1. Check what runs at 09:00

Look at crontabs, pg_cron, Celery beat, Kubernetes CronJobs, backups (pg_dump), ETL and report jobs, and REFRESH MATERIALIZED VIEW. Also check for cache entries that all expire at the same moment, because that sends every request to the database at once.

Be careful with timezones. 09:00 local might be 07:00 UTC in the scheduler config, so grep for both.

Common problems:

• A REFRESH MATERIALIZED VIEW without CONCURRENTLY, a bulk UPDATE, or a migration. Each of these takes locks that API queries then wait behind.
• A backup or batch job using up disk I/O.

2. Capture what Postgres is doing during the window

This gives you the fastest real answer. Snapshot pg_stat_activity every 10–15 seconds from 08:55 to 09:15:

SELECT now(), state, wait_event_type, wait_event,
       now() - xact_start AS xact_age, left(query, 120) AS query, application_name
FROM pg_stat_activity
WHERE datname = current_database()
ORDER BY xact_start NULLS LAST;

Read the results like this:

• Lots of wait_event_type = 'Lock': something is holding locks. Join with pg_locks (or use pg_blocking_pids()) to find the blocking session. It's usually the scheduled job from step 1.
• Lots of idle in transaction: the app opens transactions and doesn't close them quickly. That holds connections and locks.
• Many active sessions running the same query: one query is slow at scale, often a missing index or a stale plan. Check pg_stat_statements for that window.
• Session count close to max_connections: you're running out of connections (see step 3).

Also set log_min_duration_statement (e.g. 500ms) and log_lock_waits = on so the next occurrence leaves a record.

3. Check for app-side connection pool exhaustion

This is the most common cause of timeouts in Flask + SQLAlchemy apps. Search the app logs around 09:00 for:

QueuePool limit of size 5 overflow 10 reached, connection timed out

Then do the arithmetic: gunicorn workers × threads × (pool_size + max_overflow) × number of instances, compared with Postgres max_connections. When traffic jumps, requests queue for a pooled connection until they time out. Postgres can look almost idle while this happens.

Also check for ses