09 — Output discipline and structured generation

Summary

Diffs, omission of code restatement, and concise wrappers reduce output safely; brevity must not remove reasoning, decisions, evidence, or errors. TL;DR

• Output tokens are the 5x-priced class ($50/MTok out vs $10 in on Fable 5) and ~37% of a heavy day's dollars (thinking 20% + visible output 17%, local measurement). Locally, thinking is 54.8% of output tokens at max effort (n=1) — and on Fable 5 only the effort parameter can touch that share; thinking cannot be disabled.
• Biggest sanctioned number in this space: Opus 4.5 at medium effort matched Sonnet 4.5's best SWE-bench Verified score with 76% fewer output tokens (Anthropic announcement). No equivalent curve exists for Fable 5 / Opus 4.8 — reproduce before standardizing.
• Biggest measured-here number: Edit-style diffs beat whole-file rewrites by 89.3% on a realistic 5-line change to a 200-line repo file (347 vs 3,197 tok, count_tokens, claude-fable-5) — and aider's benchmark says diff formats simultaneously improve quality (20%→61%). Rare NEGATIVE-COST.
• Suppressing post-edit code restatement saves a measured 352 tok/edit (91.4%); a "Here is the JSON…" wrapper costs a measured 29 tok/call.
• Terseness has a floor: "be concise" captures only ~1.4x of a 4.8–11.2x theoretically-safe compression, degradation past per-problem token thresholds is a cliff not a slope, and >10x compression measurably increases hallucination. Route brevity at restatement and ceremony, never at reasoning. Techniques that trade quality are marked QUALITY-TRADE.

Question and scope

Which output controls remove restatement and formatting waste while preserving reasoning, correctness, and warnings?

Method

The analysis compares provider output controls, published quality studies, and local counts of equivalent edit, rewrite, summary, and structured-output payloads using the checked-in token counter.

Findings

Why this layer matters

On the modeled heavy day (~$22, 6 sessions, ~27k output tok/session — see 01 — Token Economics and Measurement), output is ~$8.14/day: ~$4.40 thinking + ~$3.74 visible (prose + tool arguments). Three structural facts shape everything below:

1. Thinking is the majority of output (54.8% locally) and is prompt-immune on Fable 5. "Thinking cannot be turned off on Fable 5. The session toggle, alwaysThinkingEnabled, and MAX_THINKING_TOKENS=0 have no effect there" (code.claude.com/docs/en/model-config). Effort is the only knob.
2. Tool arguments are output. A Write call's content field is model-generated text billed at $50/MTok. Edit-vs-Write is therefore an output-discipline question, not a tooling preference.
3. Visible prose is the smallest slice (~17% of dollars) but the only slice prompts can address directly — which is why prompt-level brevity folklore systematically overpromises (it can't reach the other 83%).

Local measurements

Method: free count_tokens API, model claude-fable-5, each payload sent as a single user message; 1-char baseline message = 7 tok envelope, subtracted in % columns. Measurement script reproduced in 16 — Validation Harness: the No-Quality-Loss Proof Protocol style: simulate the exact JSON a tool call would carry. File under test: crates/jackin-config/src/app_config/workspaces.rs (200 lines); change under test: a realistic 5-line method addition with a 5-line unique anchor.

These independently reproduce the baseline numbers (89.5% / 302 tok / 15–25 tok est.) within noise of payload phrasing. At $50/MTok: an avoided whole-file rewrite of this file saves ~$0.143; an avoided verbose summary ~$0.018; an avoided JSON wrapper ~$0.0015.

---

1. Effort parameter (/effort, output_config.effort)

One-line pitch: Anthropic's only sanctioned whole-response throttle — one knob that shrinks thinking, prose, and tool-call count together, with the strongest published number in this entire dossier.

• Layer: output (all sub-classes: thinking, text, tool arguments).
• Mechanism: "Effort is a behavioral signal, not a strict token budget" (platform effort doc). Levels low|medium|high|xhigh|max; high "produces exactly the same behavior as omitting the parameter". On adaptive-thinking models (Fable 5, Opus 4.7+) effort is the recommended/only thinking-depth control; budget_tokens is deprecated (4.6) or rejected (4.7+). Lower effort documented to "combine multiple operations into fewer tool calls… proceed directly to action without preamble… use terse confirmation messages". Claude Code surfaces: /effort slider, --effort, effortLevel setting, CLAUDE_CODE_EFFORT_LEVEL env var, and per-skill/per-subagent effort: frontmatter. Defaults in Claude Code: high on Fable 5/Opus 4.8/Opus 4.6/Sonnet 4.6, xhigh on Opus 4.7 (raw API default is high everywhere — different surfaces, both). max is session-only (except when set through the CLAUDE_CODE_EFFORT_LEVEL env var, in which case it persists; low/medium/high/xhigh persist across sessions) and "prone to overthinking. Test before adopting broadly". ultracode = xhigh + workflow orchestration, not an API level; ultrathink = one-turn in-context instruction, API effort unchanged.
• Expected savings: T1 anchor: "Set to a medium effort level, Opus 4.5 matches Sonnet 4.5's best score on SWE-bench Verified, but uses 76% fewer output tokens"; at highest effort "+4.3 percentage points… 48% fewer tokens"; long-horizon "up to 65% fewer"; GitHub Copilot "cutting token usage in half" (Opus 4.5 announcement). ESTIMATE on the modeled profile if 76% transferred to Fable 5 high→medium: 0.76 × $8.14 ≈ $6.19/day, plus unmodeled second-order savings from fewer tool calls (smaller cache-write growth). That transfer is unproven — the figures are Opus 4.5 + SWE-bench only; the effort scale "is calibrated per model, so the same level name does not represent the same underlying value across models".
• Evidence tier: T1 (anthropic.com/news/claude-opus-4-5; platform.claude.com/docs/en/build-with-claude/effort; code.claude.com/docs/en/model-config — all).
• Quality risk: stepping down from max: NEGATIVE-COST (docs: max "may show diminishing returns and is prone to overthinking"). high→medium/low: QUALITY-TRADE — Opus 4.7+ "respects effort levels more strictly… scopes its work to what was asked rather than going above and beyond"; degradation manifests as shallower investigation, skipped verification, fewer edge cases handled. Notably Anthropic itself recommends medium as the default for Sonnet 4.6. Falsification: your eval suite passes at medium with ≥ high's pass rate.
• Availability: CLAUDE-CODE-TODAY.
• Effort to adopt: minutes (/effort medium; effort: low in subagent frontmatter).
• Composability: composes with everything below; it is the only lever on the 54.8% thinking share. Per-subagent effort: low under a high-effort main loop is a shipped, documented pattern almost no cost guide mentions. Anti-synergy: partially redundant with terse-by-instruction (#3) — low effort already produces terse confirmations.
• Validation protocol: fix a 10-task repo-representative suite (bugfix, refactor, test-add). Run 3x at high and at medium with identical prompts. Record usage.output_tokens, wall time, pass rate (tests green), and thinking share (output_tokens minus count_tokens of visible blocks — same method as Baseline). Adopt medium where pass-rate delta ≤ 0; this experiment also closes the open thinking-fraction-by-effort gap (#2 in Gaps).

2. Diff-style edits (Edit) instead of whole-file rewrites (Write)

One-line pitch: a 5-line change costs 10x less via Edit than Write — measured here at 89.3% — and diff-style editing independently improves code quality, making this the cleanest NEGATIVE-COST item in the dossier.

• Layer: output (tool arguments).
• Mechanism: Edit emits only old_string+new_string (change + minimal unique anchor); Write re-emits the entire file as generated output billed at $50/MTok. Aider's complementary quality finding: diff-style formats make the model treat edits "as data" rather than chat, suppressing lazy placeholder comments; their flexible patch-application layer is load-bearing ("Experiments where flexible patching is disabled show a 9X increase in editing errors").
• Expected savings: (table above): 347 vs 3,197 tok JSON payloads = 89.3% (10.4x) on a 200-line file; $0.160 vs $0.017 per edit. Savings scale with file-size:change-size ratio. ESTIMATE on modeled profile: if 10 would-be whole-file rewrites/day become Edits, ~28.5k output tok ≈ $1.43/day. Crossover ESTIMATE: Write becomes cheaper only past ~9.4 scattered hunks of this size on this file (3,190 ÷ 340); below that, multiple Edit calls still win.
• Evidence tier: T1 — local reproduction (method above) + aider benchmark: GPT-4 Turbo (gpt-4-1106-preview) 20% → 61% on an 89-task refactoring benchmark, lazy comments on 12 → 4 of 89 tasks ("reduced laziness by 3X") (aider.chat/docs/unified-diffs.html). Caveat: aider numbers are Dec-2023/GPT-4-Turbo era — stale for Claude 4.6+/5, though Anthropic keeping string-replace as Claude Code's default editing primitive is implicit confirmation.
• Quality risk: NEGATIVE-COST. Residual: failed old_string matches force retry round-trips; degradation manifests as repeated "String to replace not found" tool errors. Falsification: count failed-match retries per 100 edits before/after; if retry waste exceeds rewrite savings on your codebase, the anchor-discipline (not the technique) is broken.
• Availability: CLAUDE-CODE-TODAY (default behavior).
• Effort to adopt: zero for defaults; minutes for a one-line CLAUDE.md guard: "prefer Edit over Write for existing files; never rewrite a file to change a few lines."
• Composability: disjoint from #3 (tool args vs prose) — they stack. Orthogonal to effort. Anti-synergy: none known.
• Validation protocol: replay 20 historical edits from transcripts both ways (reconstruct the Write payload from the post-state); count both payloads via count_tokens; cargo check the results for equivalence; track failed-match retry rate. Accept if retries × full-payload cost < 10% of measured savings.

3. Suppress restated code and post-action narration (terse-by-instruction)

One-line pitch: every "Here's what the updated section now looks like:" + re-quoted block costs a measured 352 tokens the user can already see in the tool-call diff.

• Layer: output (visible prose).
• Mechanism: CLAUDE.md/system-prompt instruction: reference file:line instead of re-quoting; no preamble/postamble; no offer-to-do-more closers. The transcript already renders the diff, so restatement is pure duplication. Strongest precedent: Claude Code's own shipped system prompt — community-documented versions instruct answering in "fewer than 4 lines… unless user asks for detail" and to "minimize output tokens" (NOT locally verifiable: the v2.1.175 binary is a compiled Bun bundle, strings not greppable; T3 for that sub-claim).
• Expected savings:: verbose post-edit summary 392 tok vs terse 40 tok = 352 tok/edit (91.4%). ESTIMATE: 50 edits/heavy-day × 352 tok = 17.6k tok ≈ $0.88/day at $50/MTok; per modeled session, 10 verbose summaries ≈ 3.5k tok ≈ 29% of the 12.2k visible-output budget. Measure your actual restatement frequency before claiming the multiple.
• Evidence tier: T1 for the per-instance delta (local measurement); T3 for the shipped-prompt precedent; the documented low-effort behaviors ("proceed directly to action without preamble… terse confirmation messages", effort doc) confirm the same behaviors are sanctioned.
• Quality risk: NEUTRAL→NEGATIVE-COST for code restatement (information is duplicated); RISKY if extended to caveats/warnings — see #10. Degradation manifests as the operator re-asking "what changed?" or missing a warning that was squeezed out. Falsification: A/B the rule and count re-ask turns.
• Availability: CLAUDE-CODE-TODAY.
• Effort to adopt: minutes (1–2 CLAUDE.md lines). The rule itself is always-on input (root AGENTS.md is already 2,738 tok, local measurement) but cached at 0.1x — a ~20-tok rule pays for itself after a single avoided restatement.
• Composability: stacks cleanly with #2 (disjoint token populations). Partially redundant with effort=low (#1) which already produces terse confirmations — adopting both, attribute savings carefully. Unknown: instruction persistence over 100+ turn sessions (Gaps #3).
• Validation protocol: two matched days of real sessions with/without the rule; per session count visible-output tokens per edit action (transcript parse) and operator re-ask rate. Accept if tokens/edit drops ≥30% with zero re-ask increase.

4. Chain of Draft / Concise CoT (visible-reasoning compression) — QUALITY-TRADE

One-line pitch: "keep each thinking step to 5 words" cuts response tokens ~79–92% on benchmark tasks — but the famous "7.6% of tokens" is the single best-case cell, and on GSM8K it costs 4.3–4.4 accuracy points.

• Layer: output (visible prose on non-thinking calls).
• Mechanism: prompt-level cap on per-step (CoD) or whole-response (CCoT "Be concise") length, applied to visible chain-of-thought. Critical Claude Code caveat: on Fable 5/Opus 4.7+ reasoning happens in billed thinking blocks that prompts do not cap (effort does); CoD-style instructions only bite on non-thinking calls — Haiku 4.5 sidecars, thinking-disabled Sonnet subagents — or on visible answer structure.
• Expected savings: CoD (arXiv 2502.18600, Tables 1/3): GSM8K GPT-4o CoT 95.4% @ 205.1 tok vs CoD 91.1% @ 43.9 tok (−78.6% tokens, −4.3 pts); Claude 3.5 Sonnet 95.8% @ 190.0 vs 91.4% @ 39.8 (−79.1%, −4.4 pts); sports understanding Claude CoT 93.2% @ 189.4 vs CoD 97.3% @ 14.3 — the "7.6% of tokens" headline AND +4.1 pts. CCoT (arXiv 2401.05618): −48.70% response length both GPT-3.5/4, −22.67% average per-token cost, but −27.69% accuracy on math for GPT-3.5. On the modeled profile: main-loop impact ≈ 0 (thinking-immune); for a Haiku subagent fleet, ~79% off those calls' output.
• Evidence tier: T2 (peer-reviewed-track arXiv, exact tables). No published CoD results on Claude 4.x/5 thinking models — the technique predates adaptive thinking.
• Quality risk: QUALITY-TRADE on hard math/multi-step reasoning (cliff per #10); NEGATIVE-COST on classification/retrieval-shaped tasks (sports accuracy went UP). Known failure modes: zero-shot CoD on Claude 3.5 Sonnet "improved performance over direct answering by only 3.6%" (few-shot examples are load-bearing) and breaks down on <3B models. Falsification: run your subagent task class with/without; reject if pass rate drops at all on reasoning-shaped tasks.
• Availability: CLAUDE-CODE-TODAY (for subagent prompts / sidecar API calls); pointless against the main Fable 5 loop.
• Effort to adopt: minutes-to-hours (one instruction + 2–3 few-shot examples in the subagent definition).
• Composability: does NOT stack with effort on thinking models — the model thinks privately AND drafts publicly = double-spend. Pair with effort: low Haiku subagents (#1) instead. Stacks with #5 for extraction sidecars.
• Validation protocol: 50-call eval on the actual subagent workload (e.g. investigator summaries) on Haiku 4.5, CoD vs plain, few-shot included; score with the main model as judge + spot-check; require ≤1 pt quality drop for ≥70% token cut.

5. Structured outputs (output_config.format json_schema + strict tool use)

One-line pitch: grammar-constrained decoding kills both the prose wrapper around JSON and the 100%-loss class of parse-failure retries — GA on all current models including Fable 5, but with a documented cache-invalidation trap.

• Layer: output (format waste) + cache (pitfall).
• Mechanism: output_config.format with a JSON schema constrains decoding so the response IS the object — no fences, no "Here is the JSON you requested" (a measured 29 tok/call, table above), no trailing commentary. tools[].strict: true guarantees tool arguments match input_schema. "Reliable: No retries needed for schema violations." Grammar compiles on first use (latency), "cached for 24 hours from last use". Injects a hidden system prompt: "Your input token count is slightly higher" (size unquantified — Gaps #6).
• Expected savings: no published percentage. ESTIMATE: (wrapper ≈ 29 tok/call measured) + (parse-failure rate × full response cost); for a 500-tok extraction failing 5% of the time, retry elimination ≈ 25 tok/call expected value — the dominant term, not the prose trim. Main-loop impact ≈ 0 (not exposed there).
• Evidence tier: T1 (platform.claude.com/docs/en/build-with-claude/structured-outputs, all; wrapper figure local measurement).
• Quality risk: NEUTRAL on format. Two documented schema-violating edge cases: stop_reason: "refusal" (200 status, billed, schema overridden) and stop_reason: "max_tokens" (truncated JSON — "Retry with a higher max_tokens"). Schema limits: no recursive schemas, no numeric minimum/maximum/multipleOf, max 20 strict tools, 24 optional params across strict schemas. Falsification: log schema-parse failures; should be exactly zero outside those two stop reasons.
• Availability: SDK (and subagent/SDK tool-schema paths). The Claude Code REPL does NOT expose schema-constrained final answers (open feature request, github.com/anthropics/claude-code/issues/9058) — though this very research task returns via a StructuredOutput tool schema, the subagent path.
• Effort to adopt: hours (schema design + pipeline wiring).
• Composability: CACHE PITFALL — "Changing the output_config.format parameter will invalidate any prompt cache for that conversation thread." Against the local profile (92.83% of prompt-side tokens are 0.1x cache reads), rotating schemas mid-thread converts reads back to 1x + 1.25x writes and can swamp the output saving. One stable schema per thread; see 07 — Caching exploitation. Supersedes prefill (#6); redundant with stop sequences (#8) for JSON.
• Validation protocol: 200-call extraction batch, constrained vs unconstrained: measure parse-failure rate, total output tokens, input-token delta (quantifies the hidden prompt), and cache-hit rate across the thread. Accept if failures → 0 with input-token overhead < wrapper savings and zero unintended cache invalidations.

6. Assistant prefill to skip preamble — a dying technique

One-line pitch: the classic "prefill {" trick still works on non-thinking models but is documented incompatible with extended thinking — and Fable 5's thinking can't be disabled, so prefill is unavailable exactly where output is most expensive.

• Layer: output (request shape).
• Mechanism: send a partial assistant turn; the model continues from it, skipping preamble (docs: prefilling { "forces Claude to skip the preamble and directly output the JSON object"). Constraint: "Extended thinking is incompatible with prefilling… the API will return an error"; community migration guides document 400s on Opus 4.6+ adaptive-thinking requests with prefills (T3 sub-claim).
• Expected savings: the measured wrapper, 29 tok/call (local), at $50/MTok ≈ $0.0015/call — material only at pipeline volume.
• Evidence tier: T1 for mechanics/incompatibility (platform prefill doc — note: retrieved via search snippets; direct fetch redirected to the prompt-engineering overview, page may be mid-reorganization); T3 for the Opus 4.6 400-error reports (blog.laozhang.ai).
• Quality risk: NEUTRAL where it works; trailing-whitespace rules apply. Falsification: trivial — the API errors loudly when incompatible.
• Availability: SDK only, and only on Haiku 4.5 / thinking-disabled Sonnet. Impossible in Claude Code interactive and on Fable 5.
• Effort to adopt: minutes in raw API pipelines.
• Composability: mutually exclusive with thinking and with #1's thinking control; superseded by #5 (docs explicitly recommend structured outputs for guaranteed schemas). Treat as legacy for cheap-model sidecars only.
• Validation protocol: for a Haiku extraction sidecar, A/B prefill-{ vs structured outputs on 100 calls: compare output tokens, input overhead (structured outputs' hidden prompt), latency (grammar compile), and failure rate; keep whichever wins — and re-test after any model bump, since this is the technique most likely to silently die.

7. max_tokens as a hard output budget — safety rail, not optimizer

One-line pitch: a tight cap in agent loops backfires: a truncated tool_use must be retried at a HIGHER limit, paying for the dead attempt in full.

• Layer: output / infra (circuit breaker).
• Mechanism: generation halts at the limit with stop_reason: "max_tokens"; the model does not plan toward the budget, it gets amputated mid-structure. Docs' own remediation: "If Claude's response is cut off due to hitting the max_tokens limit, and the truncated response contains an incomplete tool use block, you'll need to retry the request with a higher max_tokens value". Anthropic's guidance for high-effort agents is the opposite of tight caps: "set a large max_tokens… Starting at 64k tokens and tuning from there." On Fable 5, max_tokens "is a hard limit on total output, thinking plus response text" — one pool.
• Expected savings: zero as an optimizer; positive only as a runaway-cost breaker (a 64k cap bounds worst-case single response at 64k × $50/MTok = $3.20).
• Evidence tier: T1 (platform.claude.com/docs/en/api/handling-stop-reasons + effort doc, both).
• Quality risk: RISKY when set tight: mid-structure truncation (schema-invalid JSON under #5 — documented edge case), lost work, retry double-billing. Degradation manifests as max_tokens stop reasons in logs. Falsification: any nonzero rate of max_tokens stops on tool-bearing turns means the cap is destroying value.
• Availability: SDK (Claude Code manages it internally; not user-tunable per request in the REPL).
• Effort to adopt: minutes.
• Composability: use WITH effort (#1), never instead: effort shapes spend before generation, max_tokens amputates after. Python SDK requires streaming above ~21k.
• Validation protocol: in pipelines, log stop_reason distribution for a week; set max_tokens at p99.9 of observed output + margin; alert on any max_tokens stop. Total cost must be ≤ uncapped baseline (it will be, since the cap should never fire).

8. Stop sequences for single-shot generation

One-line pitch: sampler-enforced cutoff — "output the answer then END" + stop_sequences:["END"] means you never pay for trailing rationale or "let me know if…" closers in pipeline calls.

• Layer: output.
• Mechanism: custom strings halt decoding instantly (stop_reason: "stop_sequence", matched value reported in stop_sequence). Unlike instructions, compliance is enforced by the sampler, not the model.
• Expected savings: no published numbers. ESTIMATE: bounded by typical trailing content, ~20–150 tok/call on extraction tasks; ~0 in Claude Code agent loops (turns already end on tool_use/end_turn, and thinking happens before text).
• Evidence tier: T1 for the mechanism (handling-stop-reasons doc); T4 for the savings magnitude on current models — Claude 4.6+/5 already end turns crisply; the advice was minted on 3.x-era chattiness.
• Quality risk: NEUTRAL with well-designed sentinels; RISKY if the sentinel can occur in legitimate output (premature cutoff). Falsification: scan outputs for the sentinel-as-content collision rate before deploying.
• Availability: SDK only (not exposed in Claude Code interactive).
• Effort to adopt: minutes.
• Composability: redundant with #5 (schema end = natural stop); useful where a schema is overkill (single values, free-text snippets). Stacks with #4/#6 on cheap-model sidecars.
• Validation protocol: 100-call A/B on the sidecar task; measure mean output tokens and answer-truncation rate (must be 0); adopt only if trailing-content baseline actually exists on the current model.

9. Terse-by-persona (output styles / caveman register) vs terse-by-instruction — QUALITY-TRADE at aggressive registers

One-line pitch: persona-level brevity delivers a measured ~58% cut of visible prose and is structurally cache-stable — but its claimed durability edge over a plain instruction has never been measured, and research says style choice doesn't move the accuracy-length frontier anyway.

• Layer: output (visible prose), via system prompt (input-side rider, cached at 0.1x).
• Mechanism: Claude Code output styles replace part of the default system prompt (re-sent and cache-stable every turn); CLAUDE.md content rides as a user message after the default system prompt. The caveman plugin implements register-based persona compression as a skill. The current outputStyle setting remains available through /config; the /output-style command is absent (github.com/anthropics/claude-code/issues/10671).
• Expected savings: local baseline ground truth: caveman ultra = 58.5% token cut on visible prose (the plugin's "~75%" claim is character-level folklore); wenyan-full = 80.9% char cut but only 56.6% token cut (CJK ≈ 1.47 chars/tok vs 3.35 English); wenyan-ultra = 74.5% token cut. Applies ONLY to visible prose ≈ 17% of session dollars: upper bound 0.585 × $3.74 ≈ $2.19/day on the modeled profile if every visible token were prose (it isn't — tool args share that class, so real ceiling is lower).
• Evidence tier: T1 for the local cut measurements; T3 for plugin claims; T2 for the frontier argument — format/language variants "lie on a universal trade-off curve between response length and accuracy" incl. "in Chinese" and no-spaces variants (arXiv 2503.01141). The persona is a delivery vehicle for a length target, not a free lunch.
• Quality risk: QUALITY-TRADE at aggressive registers (#10 governs), plus a human-comprehension cost. Degradation manifests as dropped qualifiers and operator misreadings. Falsification: same task suite styled/unstyled, diff for lost caveats (grep negations/"not"/"however"), and have a second reader rate ambiguity.
• Availability: CLAUDE-CODE-TODAY (plugin install or outputStyle setting).
• Effort to adopt: minutes.
• Composability: persona text lives in the cached prefix (cheap at 0.1x); composes with #2/#3. Overlaps #1's low-effort terseness — stacking all three risks triple-pressuring length on hard tasks (see #10). Subagent variant (cavecrew, ~60% smaller results fed back into context) saves input downstream — quality side unmeasured (T4).
• Validation protocol: 10 mixed tasks × {default, caveman-full, caveman-ultra}: measure visible-output tokens, task pass rate, caveat-retention (count negations/disclaimers in both outputs), operator comprehension quiz. Adopt the strongest register with zero caveat loss; the durability question (does persona hold over 100+ turns better than a turn-1 instruction?) is currently T4 — log tokens/turn over a long session to convert it.

10. The terseness floor: token-complexity thresholds, hallucination onset, negation loss

One-line pitch: the anti-claim that bounds every entry above — each problem has a sharp minimum-token threshold; "be concise" reaches only ~30% of safe compression; past ~10x, hallucination rises and the load-bearing small words (negations, disclaimers) drop first.

• Layer: output (design constraint over all of the above).
• Mechanism: token complexity (arXiv 2503.01141): per problem there exists a threshold τ "such that for any prompt, the LLM gets the answer correct iff the token length is above τ" — cliff, not slope; success is predictable from token count alone with accuracy "above 90% for most models and benchmarks". Safe compression therefore requires ADAPTIVE allocation (more tokens to harder problems) — which is exactly what adaptive thinking + effort implements at platform level and what blanket "always be brief" cannot do. Information-loss side: moderate (2–6x) prompt compression "typically preserves or even enhances LLM performance… while extremely aggressive ratios (>10x) incur pronounced information loss and sometimes increase hallucination rates" (arXiv 2505.00019); compression modules "may discard key information such as negation cues (e.g., 'not'), factual disclaimers, time and location markers" (CompressionAttack, arXiv 2510.22963). CCoT's −27.69% GPT-3.5 math penalty and CoD's zero-shot collapse are output-side instances of the same threshold effect.
• Expected savings: none — this bounds the others. Quantified headroom: BeConcise achieves 1.41x where 4.83x is theoretically safe (MMLU-Pro Math), 1.47x vs 11.16x (GSM8K), 1.26x vs 3.69x (MATH-500) — naive instructions capture under a third of safe compression, and the remainder requires per-problem adaptivity, not harder squeezing.
• Evidence tier: T2 (arXiv 2503.01141 verified directly; 2505.00019 / 2510.22963 / EMNLP-2025 aclanthology.org/2025.emnlp-main.389). The output-side analog of negation loss (do terse output registers drop caveats?) is unmeasured — T4 extrapolation.
• Quality risk: this entry IS the risk model: assume NEGATIVE-COST terseness up to ~2x on prose, QUALITY-TRADE beyond, cliff behavior past per-problem thresholds; audit compressed outputs for dropped negations/caveats specifically.
• Availability: NOT-USER-ACCESSIBLE (design principle, not a switch).
• Effort to adopt: n/a — practical rule: aim brevity pressure at easy/format-shaped content (summaries, confirmations, restatements — #2, #3, #5) and never at reasoning on hard problems (#1 medium-vs-high is the safe adaptive form; #4/#9 aggressive registers are the dangerous fixed form).
• Composability: explains why effort (adaptive) dominates fixed budgets (#7) and blanket personas (#9) at equal average savings.
• Validation protocol: for any adopted brevity stack, maintain a canary set of 5 hard-reasoning tasks; run weekly; any pass-rate drop triggers register rollback. Separately, diff terse-vs-default outputs for negation/disclaimer counts (closes the T4 gap).

---

Implications for jackin❯

Techniques

For jackin❯, the output discipline and structured generation evidence identifies which mechanisms are safe to adopt directly and which still require workload-specific validation.

Limitations and unknowns

Claims to kill

Gaps (highest-value follow-ups)

1. No quality-vs-effort curve for Fable 5 / Opus 4.8 — the 76%/48% figures are Opus 4.5 + SWE-bench only; the usage object doesn't report what effort "did", so the knob can't be audited post-hoc.
2. Thinking-fraction-by-effort is unmeasured anywhere. Local n=1: 54.8% of output at max effort. The #1 validation protocol closes this for free.
3. Persona durability vs instruction decay over 100+ turns/compaction: zero published measurements; currently mechanism-reasoning only (system prompt is re-sent and cache-stable; turn-1 instructions scroll into compacted history).
4. Caveat-drop rates in terse OUTPUT registers: negation loss is measured only for input compression; the output-side analog is plausible (T4) and matters for review/safety-adjacent summaries.
5. Edit-vs-Write crossover under real scattered-change distributions incl. failed-match retries (local single-hunk estimate: ~9.4 hunks); aider's quality numbers are GPT-4-Turbo-era.
6. Structured outputs' hidden system-prompt size ("slightly higher") — measurable by diffing count_tokens against a live request with output_config; not run here because count_tokens in the local harness does not accept output_config.
7. Claude Code REPL still lacks schema-constrained final answers (issue #9058 open); only SDK/subagent tool-schema paths get the guarantee.

Sources

Related work

• Token-optimization techniques dossier
• Validation harness
• Context engine