You're right to push back on this

If you’ve used Claude recently for any sort of work you’ll have likely received one of the following:

“you’re right and the honest answer is…”, “and this is load bearing”, “I’m going to stop guessing, let me verify rather than assume”

Here’s an example from one of my recent conversations (trimmed for brevity). I asked “Does it make sense to batch on projects?”

“Full task-level batching (option 3 taken to per-task fan-out) gives marginal extra distribution over binning at large architectural cost because the output is project-grouped — I’d not start there.”

I’ve never felt so angry at a computer before. I’ve created a whole blog just so my first article can be about this topic.

Anyway I set out to fix it and here’s what worked for me and what didn’t.

Firstly I tried the ‘normal’ thing to do. Editing my CLAUDE.md file. I’d seen a post on X about using ASD-STE100. ASD-STE100 is an international standard for writing technical documents. Users on X said they’d seen some success using this so why not ey?

Completely ignored it. Turns out there’s no enforcement of the guidelines added in CLAUDE.md, it’s entirely upto the Claude if it respects those or not.

So I pushed back… I turned to the hooks system.

We’ve used the hook system in our codebases to invoke a ‘best practices’ skill. This skill leaves inside the repos and guides Claude on how we like our code written. Claude is blocked from making writes or edits until it invokes the skill.

An event exists called “UserPromptSubmit” and it fires when you submit your prompt. It fires before Claude processes it. So I added the following:

"UserPromptSubmit": [
  {
    "hooks": [
      {
        "type": "command",
        "command": "cat ~/.claude/tone-reminder.txt 2>/dev/null || true"
      }
    ]
  }
],

The text file contains the following:

TONE REMINDER:
- Use ASD-STE100 Simplified Technical English when replying to me or when drafting documents.
- Short sentences. Everyday words. One idea per sentence.
- Lead with the answer. Cut preamble, hedging, and reassurance.
- No jargon walls, no big tables or caveat-stacks unless asked.
- Give a recommendation, not an exhaustive survey.
- If unsure, say so briefly.

Boom. Kick rocks Anthropic.

Before:

So the setting is effectively a fan-out/parallelism knob: a smaller value means more, smaller BatchExportJobs (more parallelism across queue workers, smaller per-job memory footprint); a larger value means fewer, heavier jobs. Journal exports (is_journal_export) bypass batching entirely — they get a single tracker and dedicated journal/voice entry jobs regardless of the setting.

After:

So the setting is a per-tenant tuning knob: a smaller value means more, smaller queue jobs; a larger value means fewer, heavier ones. There is no UI validation tied to it here — it is read raw from the settings table, uncached, each time an export starts.

My overall experience is a lot better now. I’ve now moved back to the frontier models (I was on 4.8 hoping it was less verbose).

However.. I plan, Anthropic laughs.

A day later Anthropic dropped the ‘concise’ output style in the claude code config. You can turn this on by typing /config, searching for output style and then selecting ‘concise’. I’ve yet to try it out since what I have is working but I may try adding my own. Creating a .md file at ~/.claude/output-styles creates a selectable output style in the config menu.

That’s all for now. Hope this can be useful to someone. If not it’s been theraputic venting to the void.