Compound Engineering in Claude Code: Install Every’s Plugin and Run the Loop Without the Token Burn (2026)

Short answer: Compound engineering in Claude Code means running every change through a loop of brainstorm, plan, work, review, and then a final “compound” step that writes down what you learned so the next plan can read it. Every (the company behind Cora and Spiral) packages that loop as an open-source, MIT-licensed plugin. In Claude Code you install it with two commands, run /ce-setup, and then use /ce-brainstorm, /ce-plan, /ce-work, /ce-code-review and /ce-compound. It is excellent for risky or unfamiliar work and overkill for a one-line fix, so the real skill is knowing when to skip it.

Last updated: November 10, 2026. Commands and skill names come from the plugin’s GitHub README and docs (plugin version 3.37.1 on November 10, 2026) and Every’s compound engineering guide. Forum notes are paraphrased from r/ClaudeCode, r/opencodeCLI and the plugin’s GitHub issues. I used Claude Code a lot in the past, but I have not run this plugin myself, so there are no “my results” numbers below.

What compound engineering actually is

The idea is simple and a little contrarian. Most codebases get harder to change over time: every feature adds a special case, every bug fix leaves knowledge in somebody’s head or a chat transcript. Compound engineering tries to flip that so each unit of work makes the next one easier.

Every’s guide describes the original four steps as Plan → Work → Review → Compound → Repeat. The first three are just good engineering. The fourth one is the whole point: after a verified fix, the agent writes the non-obvious lesson somewhere the next planning run will find it. Skip that step and, in Every’s words, you are just doing traditional engineering with AI help.

The plugin’s README puts the bet as “80% is in planning and review, 20% is in execution.” That ratio is why people love it and also why people complain about it, which we will get to.

Two things that confuse searchers:

• It is a workflow, not a model. Nothing about it makes Claude smarter. It feeds Claude a structured process and a growing pile of project notes.
• The command names changed. Early-2026 posts use /workflows:plan, later ones use /ce:plan, and the current README uses /ce-plan. If a tutorial’s commands don’t exist, it is probably just old.

How to install the compound engineering plugin in Claude Code

Inside a Claude Code session:

/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineering

Then start a new session in your project and run:

/ce-setup

According to the README, /ce-setup checks optional tool capabilities, creates .compound-engineering/config.yaml in the repo if it is missing, and gitignores a local override file. If you ever forget which skill comes next, /ce-help tells you.

Non-interactive install (scripts, dev containers, CI images)

If you are building a dev container or setting up a fresh machine, the plain CLI form avoids the interactive prompts:

claude plugin marketplace add EveryInc/compound-engineering-plugin
claude plugin install compound-engineering@compound-engineering-plugin -y

Share it with a co-founder or contractor through the repo

You can check the marketplace and plugin into .claude/settings.json so anyone who trusts the folder gets the same setup:

{
  "extraKnownMarketplaces": {
    "compound-engineering-plugin": {
      "source": { "source": "github", "repo": "EveryInc/compound-engineering-plugin" }
    }
  },
  "enabledPlugins": {
    "compound-engineering@compound-engineering-plugin": true
  }
}

Each person may still need to run the install once with --scope project. If you have never touched Claude Code settings or skills, read Claude Code skills explained first, because the plugin is really a big bundle of skills.

Upgrading an older install

This one bites people. The plugin moved to a new layout, and an old install keeps a cached marketplace snapshot. Running /plugin update alone can leave you on the previous version. Refresh the marketplace first:

/plugin marketplace update compound-engineering-plugin
/plugin update compound-engineering

Not on Claude Code?

The same plugin runs on 14 agent hosts. In Cursor’s agent chat it is /add-plugin compound-engineering; Codex CLI uses codex plugin marketplace add EveryInc/compound-engineering-plugin followed by codex plugin add compound-engineering@compound-engineering-plugin, and Codex invokes skills as $ce-plan instead of /ce-plan. OpenCode, Copilot CLI, Cline and others have their own install paths in the README.

The compound engineering loop, step by step

The current README lists six steps. Here is what each one does and what it leaves behind on disk.

Step	Command	What you get
Brainstorm	/ce-brainstorm <idea>	An interactive Q&A that ends in a requirements-only plan
Plan	/ce-plan	That plan enriched into an implementation-ready plan (default folder docs/plans/)
Work	/ce-work	The plan executed, with verification and commits
Simplify	/ce-simplify-code	Fresh code tightened, useless tests and comments pruned
Review	/ce-code-review	A report-only multi-agent review against the plan; fixes are applied only when you say so
Compound	/ce-compound	The lesson captured, usually in docs/solutions/

A full run on a real feature looks like this:

/ce-brainstorm add a "pause subscription" option to the billing page
/ce-plan
/ce-work
/ce-simplify-code
/ce-code-review
/ce-compound

There is also /lfg, which takes a brainstormed feature and runs the rest hands-off: work, simplify, review and apply fixes, capture learnings, browser tests, commit, and, if a git remote exists, push, open a PR and watch CI. The README says it does not merge unless you grant that. Treat /lfg like YOLO mode in Claude Code: great in a sandbox or a throwaway branch, not something to point at a production repo on your first day.

Starting from a bug instead of a feature? Use /ce-debug. Not sure what to build yet? /ce-ideate.

The compound step is the part worth copying

/ce-compound is surprisingly strict about what it saves. Its docs say a lesson is worth compounding only when it is non-obvious (you can’t recover it from the final code or tests), durable (it explains a constraint, root cause or rejected approach), and material (forgetting it would likely cause a repeat or real risk).

It then picks the cheapest form that stops the repeat, in this order: make there be only one way to do the thing, add a test or lint rule, add a rule to CODING_STANDARDS.md, and only then write a learning doc in docs/solutions/<category>/<file>.md. One learning per run.

That ordering is the best idea in the whole plugin, and you can steal it even if you never install anything. Here is a plain prompt that does the same job in any agent:

We just fixed <bug/feature>. Before we close this task:
1. Is the lesson non-obvious, durable and material? If not, say "nothing to compound" and stop.
2. If yes, pick the cheapest form that would stop it happening again:
   a test or lint rule > a one-line rule in CLAUDE.md > a short note in docs/solutions/.
3. Write only that one thing. Include what we tried that did NOT work.
4. Show me the diff. Do not touch product code.

And a small template for the note itself, so learnings stay readable for humans, not just agents:

# <short problem name>

**Symptom:** what we saw (error text, behavior)
**Root cause:** one or two sentences
**Fix:** what changed and where
**Didn't work:** approaches we tried and why they failed
**Guardrail:** test / lint rule / CLAUDE.md line that now prevents it
**Related:** links to other docs/solutions files

Then add one line to your CLAUDE.md template so the agent actually looks there:

## Past lessons
Before planning any change, search docs/solutions/ for related problems and follow their guardrails.

Where it shines, and where it’s pure ceremony

Forum threads about the plugin keep landing on the same split.

What people like:

• Planning surfaces questions you didn’t think to ask. One r/ClaudeCode poster said the main value was confidence in the output, because the agent interviews you before writing a detailed plan.
• The review skills are strong. A user on r/opencodeCLI who mostly uses it for brainstorming and planning called the doc reviewer and code reviewer “really, really good” and said its planning beat plain plan mode for complex tasks.
• It pairs well with parallel agents. Several people running 4 to 8 agents in git worktrees said a proper planning phase is what makes parallel work manageable, because it produces well-scoped tasks that don’t touch the same files. (If you work this way, see Claude Code fork for running sessions side by side.)

What people complain about:

• Overhead on small changes. A May 2026 r/ClaudeCode thread was titled, roughly, “plugins are slowing me down.” The author saw the value but felt they’d already be done without the full ceremony on every cycle.
• Token burn. The r/opencodeCLI poster said they hit their limits within four or five full loops. An older GitHub issue measured about 12k tokens of idle context from the plugin’s agent definitions alone, back when every agent loaded into context up front. The plugin has since been restructured around on-demand skills, so check /context on your own install rather than trusting that number.
• Plans that read like machine notes. One user switched to OpenSpec because the plans filled up with shorthand references that suit the model but not the human reading them.
• Runaway reviews. Another user saw a doc review stretch to nearly 30 rounds while growing in scope, and fixed it by adding a “ask me questions first” rule to their AGENTS.md.

The most useful reply I found suggested gating the ceremony by stakes. I agree with it, and here is my version:

Use the full loop	Use plan mode + a CLAUDE.md rule	Skip the ceremony
New feature in an unfamiliar domain	Normal feature in code you know	One-file bug fix with a clear repro
Auth, payments, migrations, anything irreversible	Refactor that touches a few files	Copy, styling, cosmetic changes
Changes across several services	Adding tests to existing code	Anything you can fix in five minutes if it’s wrong

How to keep the token bill under control

For a solo founder on a Pro plan, this matters more than the workflow itself. A few practical moves:

1. **Don’t run /lfg or the full six steps for small work.** Use the table above.
2. Run the cheap steps alone. /ce-plan and /ce-compound are where most of the long-term value lives. You can plan with the plugin, work with plain Claude Code, and compound at the end.
3. Move reviews to a cheaper model. One user does code reviews by running /ce-code-review in OpenCode on a cheap model, then hands the report back to Claude to fix. Since the plugin installs in OpenCode and other open agents, you can do the same. DeepSeek is the cheapest serious option for that lane: it isn’t the smartest reviewer, but on DeepSeek’s pricing page (checked November 10, 2026) deepseek-flash costs $0.30 per million cache-miss input tokens and $1.20 per million output tokens at peak, and half that off-peak. For a long review prompt that’s pennies.
4. Prune what you don’t use. Check /context after installing. If the plugin plus your MCP servers eat a big chunk of the window, disable what you don’t need. More tactics are in how to reduce Claude Code token usage.
5. Watch overflow billing. If you have usage credits switched on, a long autonomous run can spill into paid usage. Claude extra usage cost explains how to cap it.

Compound engineering without the plugin

If the plugin feels heavy, you can get most of the benefit with tools Claude Code already has:

• Plan mode for anything non-trivial, with the plan saved to docs/plans/<date>-<feature>.md.
• A “past lessons” section in CLAUDE.md pointing at docs/solutions/ (above).
• **A custom /compound skill** using the prompt in the compound section. See Claude Code skills explained for the file format.
• A Stop hook that reminds the agent to consider a learning when a task ends. The Claude Code hooks examples post has the hook syntax.
• A review subagent that checks the diff against the plan before you commit.

Lighter alternatives people mention in the same threads include OpenSpec (spec-first planning) and Superpowers (a skills pack). One r/opencodeCLI user said they merged Superpowers with only the compound part of Every’s plugin. I haven’t benchmarked any of these against each other, so treat that as a lead to explore, not a ranking.

Pitfalls to watch for

• Old tutorials. If /workflows:plan or /ce:plan “doesn’t exist,” you are reading an older guide. Use the hyphenated names.
• Stale upgrades. Refresh the marketplace before /plugin update, or you’ll stay on the old version.
• Learnings that rot. Notes in docs/solutions/ can go out of date. The plugin has /ce-compound refresh and ce-compound-refresh for maintenance passes; without the plugin, review that folder once a month.
• Compounding everything. A folder full of trivial notes is noise the agent has to read on every plan. The non-obvious/durable/material test exists for a reason.
• **Letting /lfg push.** It can push and open PRs on its own. Keep branch protection on main and read the PR before merging, just as you would with Codex hooks or any other automation.
• Newer models don’t make it obsolete. Someone asked on r/ClaudeCode whether newer Claude models that plan and review on their own make the plugin pointless. The best answer was that the plugin is mostly good engineering practice delivered as context, and the compound step still needs explicit prompting.

My take

The part of compound engineering that matters for a one-person product isn’t the six steps. It’s the habit of turning every painful bug into a guardrail: a test, a lint rule, or one line in CLAUDE.md. The most expensive bugs in a solo project are the ones you solve twice because the first fix only lived in an old chat, and even a small docs/solutions/ folder stops that.

So my suggestion is to install the plugin, use /ce-brainstorm and /ce-plan on your next risky feature, always finish with /ce-compound, and skip the full loop for everything small. If your plan’s limits can’t take it, keep the compound prompt and drop the plugin. For how this fits a full solo workflow, see my AI workflow for indie products.

FAQ

What is compound engineering in Claude Code?

It’s a workflow where each change goes through brainstorm, plan, work, review and a final compound step that records the lesson so later plans can use it. Every publishes it as a free, MIT-licensed plugin for Claude Code and other agents.

How do I install the compound engineering plugin?

In Claude Code run /plugin marketplace add EveryInc/compound-engineering-plugin, then /plugin install compound-engineering, start a new session, and run /ce-setup.

Is the compound engineering plugin free?

Yes. The plugin is open source under the MIT license. You still pay for the agent and model usage it runs on, and full loops use a lot of tokens.

What does /ce-compound write?

It writes at most one thing: a test or lint rule, a rule in CODING_STANDARDS.md, or a learning doc in docs/solutions/, choosing the cheapest form that stops the problem from repeating. It doesn’t change product code.

Does compound engineering work in Cursor or Codex?

Yes. The README lists 14 supported hosts. Cursor installs it with /add-plugin compound-engineering, and Codex installs it from a custom marketplace and invokes skills with $ instead of /.

Is it worth it for a solo founder?

For risky or unfamiliar work, yes. For small fixes, the ceremony costs more time and tokens than it saves. Many users keep the plan and compound steps and skip the rest.