Claude Code

Anthropic's coding-agent product — the corpus's reference harness, studied for its features, leaked internals, usage limits and workflow habits.

Also known as: Claude Code, claude code, auto mode, Plan Mode, Caveman plugin, Buddy / Companion system, KAIROS / Dream Mode

Part of: Coding Agents

How authors use it

Oldest first (extraction date when no publication date is known).

AuthorTheir termTheir meaning
Head of Claude Code: What happens after coding is solved | Boris Cherny
Lenny's Podcast · 2026-02-19		plan mode(Boris) Deliberately described as mechanically trivial: a single injected sentence telling the model not to write code yet, used for roughly 80% of Boris's own tasks as a lightweight checkpoint where the model proposes a plan before the human approves execution.
Claude Code Source Leak Megathread
sixbillionthsheep (Reddit) · 2026-04-01		KAIROS / Dream ModeAn unannounced autonomous agent system that activates after periods of user inactivity, reviews its own memories, consolidates learnings, prunes outdated info, and rewrites memory files -- effectively 'dreaming'
Claude Code Source Leak Megathread
sixbillionthsheep (Reddit) · 2026-04-01		Buddy / Companion systemA gacha-style virtual pet system (18 species, 5 rarities) permanently bound to user UUID, with tamper protection -- essentially gamification embedded in a developer tool
Alex Wang's Post
Alex Wang · 2026-04-16		Plan ModeA Claude Code mode where the model inspects and proposes changes before executing them, reducing risk for multi-file edits
Inside Claude Code Auto Mode: Anthropic's Autonomous Coding System with Human Approval Gates
Leela Kumili · 2026-04-20		auto modeA Claude Code operating mode where safe tool calls proceed without human approval, with only uncertain or high-risk operations escalated to the user
I benchmarked CC's caveman plugin against 'be brief'. The token math is wild.
TroyHay6677 · 2026-04-30		Caveman pluginAn open-source Claude Code plugin by JuliusBrussee that forces the model to output primitive, broken-English responses to minimize output tokens
Why Google Isn't Chasing Claude Code
AI Daily Brief · 2026-05-21		Claude CodeAnthropic's coding-agent product, used as shorthand for the entire category of frontier coding/agentic-software harnesses that define one axis of the AI race
How we Claude Code
Claude · 2026-05-22		Auto modeA Claude Code operating mode (cycled into with shift-tab) that lets the agent proceed through actions without per-step confirmation; presented as something everyone in the room should already be using.
How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar
Ryan Peterman · 2026-09-07		Auto ModeA classifier that runs after every Claude Code task to auto-approve actions that would otherwise require a manual permission prompt, introduced specifically because Claude's autonomous runs grew from a few minutes to multiple hours.

Documents (26)

Propositions touching this concept (145)

By publication month, oldest first (extraction month when no publication date is known).

2025

2025-04

2025-06

2025-09

2025-10

2025-12

2026-01

2026-02

2026-03

2026-04

2026-05

2026-06

2026-07

2026-08

2026-09

2026-10

Tensions

Is the model a swappable, commoditized component (so selection is a cost decision), or is model choice load-bearing (so selection is a capability decision)?
from: When working with AI coding agents, how should you select the model, its reasoning/effort level, and its context size for a given task?
Assessment: Both camps are right about different task strata, and the tie is broken by the routing camp's own artifact. Commoditization holds on the bulk/background tier (musistudio and the Pragmatic Engineer are correct that a cheap or open model suffices for a large share of tokens), but model choice is load-bearing exactly on the hard tier — the 'hardest 40%' the routing camp routes AWAY (the Pragmatic Engineer's own gap notes 60%-of-token-spend is not 60%-of-value). nrehiew's 6.5x over-editing spread and stellaraccident's collapse are measured on precisely that hard tier. The clincher the swap camp does not concede: musistudio's OWN per-model transformers (tooluse, enhancetool, reasoning, deepseek, gemini) prove the harness is NOT model-agnostic — every model needs bespoke request/response rewriting just to work behind Claude Code, so the 'any model' artifact self-refutes. Delangue even concedes the frontier gap himself. Verdict: select cheap-and-swappable for bulk, and treat the model as a load-bearing capability decision for the hardest slice — the two positions are not competitors but a partition of the task distribution.
Context size: should you shrink the problem to fit a small usable window (decompose / reset), or grow and trust a large window?
from: When working with AI coding agents, how should you select the model, its reasoning/effort level, and its context size for a given task?
Assessment: The apparent 'grow / trust the big window' position for CODING largely dissolves once retrieval is separated from coding — which is exactly Pocock's move ('good for retrieval, less good for coding') and musistudio's (longContext is a routed escalation, not the coding default). No text argues you should code inside a full 1M window. The only genuine pressure toward trusting a bigger window is the vendor-forward Fable 5 / Opus 4.6 claim that coherence loss is being engineered away — but that is a moving target (convergence 5), not a stable dial, and even the harness paper only relaxed context resets AFTER measuring that the new model no longer needed them. A secondary, live sub-dispute survives: reset vs compact. Pocock, the harness paper and best-practices favor clearing/resetting to a fresh agent; Hills and Osmani lean on compaction. The reset camp has the better argument on today's models — compaction preserves the same anxious agent — but the disagreement is real and unresolved. Verdict: shrink-and-decompose is the default for coding; grow only as an explicit retrieval escalation; prefer reset over compact unless the model version has demonstrably killed context anxiety.
Effort/reasoning: does more thinking make output better, or does more reasoning make it worse (over-engineering / over-editing)?
from: When working with AI coding agents, how should you select the model, its reasoning/effort level, and its context size for a given task?
Assessment: This looks like a head-on collision but is really the corpus resolving a category error, so I keep it as a divergence-under-adjudication rather than a live two-camp fight. The two things bundled into one 'effort' dial are separable: reasoning DEPTH (deliberation and research before acting — what stellaraccident measures as the Read:Edit ratio) versus action SCOPE (how much the model rewrites — what nrehiew measures as over-editing). They are separable but DEFAULT-COUPLED: more reasoning, unconstrained, tends to produce more scope. nrehiew is the empirical bridge — constrained reasoning models are the MOST faithful, proving depth and tight scope combine positively when you address them separately. Fable 5 already acts on this, pairing 'reduce effort' with a distinct anti-over-engineering instruction. The actionable verdict: do NOT cut reasoning depth to fix over-editing (that is stellaraccident's exact grievance and it backfires into shallow, edit-first behavior); keep the depth and add an explicit scope constraint. The failure is treating one knob as if it controls both correctness-depth and edit-scope.
Who selects the model/effort/context — a human deciding per task, or an automatic router — and who is trusted to hold the dial?
from: When working with AI coding agents, how should you select the model, its reasoning/effort level, and its context size for a given task?
Assessment: The human-vs-auto axis is less about capability than about (a) whether task difficulty can be detected a priori and (b) who bears the principal-agent risk. No router in the corpus actually measures difficulty — musistudio routes by token-count and static scenario, and the Pragmatic Engineer's routers infer 'good enough' without a demonstrated oracle — so 'auto' today means 'static-heuristic', not 'optimal'. Automation is safe when the user owns the policy (musistudio) and dangerous when the router profits from the choice (Cursor Auto) or when the provider adjusts the dial invisibly (stellaraccident). Verdict: keep the human holding the difficulty judgment and the effort dial until routers can both measure adequacy and prove neutral incentives; automate only the mechanical dispatch, over rules you own and can audit.

Open gaps (95)