๐‘’= 2.7182818284โ€ฆ โ€” the other constant

Everything pi ships. Nothing it promised to keep out.

e is the minimalist fork of the pi coding agent. One hundred percent pi extension & package compatibility โ€” but the heavy addons ship off by default. The features on the box are the ones you get. All of them.

$ npm i -g @subimpact/e
off by default

No MCP

Server config, oauth, /mcp โ€” none of it loads until you ask for it.

off by default

No codemode

The JS-sandbox tool layer stays dark unless you opt in.

off by default

No tool-search

Nothing to search for when nothing is deferred.

never

No sub-agents

One model, one loop, read / write / edit / bash. As designed.

always

pi compatible

Your existing pi packages, extensions and skills work unmodified.

always

opt back in anytime

Need MCP for one project? One config line. Your call, per project.

Why e exists

pi built its reputation on a promise: a minimal harness โ€” no MCP, no sub-agents, no plan mode. Then version 0.99.0 shipped all of it as built-in extensions anyway. The community pushed back; upstream softened the UX but kept the direction.

e keeps the original promise โ€” without throwing away pi's excellent engineering. The code is all still there, because your third-party pi extensions depend on those APIs. What changed is the default: e ships quiet. You're working with four tools โ€” read, write, edit, bash โ€” from the first prompt, the way the pitch always said.

e tracks upstream weekly. Fixes are cherry-picked; new addon features stay off the default path. Respectful of upstream, MIT licensed, lineage credited.

Pi compatibility

GET THE ADDONS BACK WHEN YOU WANT THEM
# in settings.json (or per-project) โ€” exact pi syntax:
"extensions": ["+builtin:mcp", "+builtin:codemode", "+builtin:tool-search"]

# or flip for one session:
e -e builtin:mcp

Existing pi packages install with e install <package> the same way they always did. Env vars: E_* first, legacy PI_* still honored. Config lives in ~/.e/.