SteinWall

Spend less. Break nothing. A local guardian for coding agents. It sits between Claude Code and the actions it takes.

Plugin name steinwall is pending a trademark and domain check. It cannot be changed after it is published to the Claude marketplace.

Everything runs locally. No prompts, code or keys leave the machine.

claude plugin marketplace add maxxstm/steinwall
claude plugin install steinwall@steinwall

Then, in Claude Code:

• /steinwall:setup installs the status line (--force replaces an existing one; the old one is backed up).
• /steinwall:report shows the daily report (cost, savings, blocked actions, rescued loops).
• /steinwall:status shows cost today and this month, budget state and guard counts.
• /steinwall:budget --daily 30 --monthly 400 changes limits; off disables one.
• /steinwall:budget --plan api|subscription|auto sets the billing type.
• /steinwall:budget override lifts today's stop; resume turns it back on.

Requires Node.js 20 or newer on PATH.

codex plugin marketplace add maxxstm/steinwall
codex plugin add steinwall@steinwall

Then review and trust the plugin's hooks with /hooks in Codex. Codex skips untrusted hooks, and asks again whenever the hook definition changes. The plugin ships a steinwall skill. Its command-line tool is node ~/.steinwall/bin/steinwall.mjs status|report|scan, installed on the first session start.

Differences from Claude Code, because Codex's hook interface works differently:

• No approval prompts. Codex hooks cannot ask the user. Anything that needs approval in Claude Code is blocked, and the agent is told to ask the user to run the step themselves. Setting guard.unattendedAsk to allow lets those actions through instead.
• Failures are read from the exit code in PostToolUse output, which runs for Bash and apply_patch. Codex has no separate failure event.
• apply_patch: the guard and the scanner look at every file inside the patch.
• Costs and limits come from the session file (token_count events) and are priced at OpenAI list prices. The 5-hour and weekly limits come from the same events, so the limit handoff works without a status line.
• No status line. Use steinwall status or the steinwall skill.
• Hooks are only allowed in manually installed Codex plugins. OpenAI's public plugin directory does not accept plugins with lifecycle hooks.

For OpenAI's plugin directory there is a separate hook-free edition in lite/codex/: a single skill that runs only when asked. It gives a daily briefing (cost, limits, and what the hook edition would have caught: stuck loops with the cost of their extra rounds, and risky commands) and scans extensions. It is read-only and cannot step in; for automatic protection, install the full edition above. npm run package:lite builds the upload ZIP.

• Claude Code costs are higher than expected, or the user wants a hard spending limit.
• The user asks how to stop an agent from deleting files, force pushing or reading secrets.
• The user wants to see the cost of the current session or day in the status line.

SteinWall reads the session transcripts that Claude Code writes (including subagent transcripts). It counts each assistant message's token usage once and prices it at Anthropic API list prices (src/core/pricing.ts):

• cache writes cost 1.25× input (5-minute TTL) or 2× input (1-hour TTL);

• cache reads cost 0.1× input unless a model lists its own rate;

• fast mode costs 2×;

• costs are attributed to the local calendar day of each message.

• API users (ANTHROPIC_API_KEY set): the figure estimates real spend, and the budget stop is enforced.

• Subscription users: the figure is the API-equivalent value of the usage. Budgets only warn, unless budget.enforceOnSubscription is turned on.

All amounts are estimates and are shown with "≈". Models that are not in the price table are priced like the current Sonnet and listed in /steinwall:status.

Pro costs $9/month or $90/year, with a 5-day trial from the first start. The first 500 users get a founder price of $5/month. Licenses are signed keys that are checked offline and refreshed online every few days. Activate one with /steinwall:license activate <key> or steinwall license activate <key>. Every referred Pro user earns the referrer one free month.

The report shows Pro savings separately. The only upgrade hint sits under the savings in the report and quotes what Pro actually saved during your trial. There are no pop-ups.

At the first session start, a separate question asks whether to contribute to the public savings counter. It is off unless you turn it on with /steinwall:telemetry on. Each day it sends only the previous day's estimated savings and a random install id. Agents cannot turn it on.

• steinwall card: a shareable card ("SteinWall saved me ≈ $47 this week") with a PNG download.
• steinwall mcp: an MCP server (stdio) with read-only steinwall_status, steinwall_report and steinwall_scan tools for any MCP client. The plugins do not register it, because MCP tools add to every request's context.

SteinWall compares what happened with an estimate of what would have happened without it. Every figure is shown with "≈".

Rescued loops (the only $ savings in the free version).

• Pricing a round: every tool call is stamped with the session's accounted cost when it starts. The cost of one loop round is (cost at the latest failed round − cost at the first) ÷ (rounds − 1). If that can't be measured, the session's average cost per call is used.
• When a loop counts as rescued: only after SteinWall has intervened (a hint, a strategy change or a block). The failing pattern must then stay away for 8 calls, or for 2 calls if the agent ends its turn calmly. A loop that ended with "tell the user you are stuck" is never counted.
• The assumption: without SteinWall, the loop would have continued at least as many more rounds as it had already run. So the saving is rounds so far × cost per round. This is deliberately conservative: the counterfactual is not observed, it is a stated lower-bound guess.

Not given a dollar value:

• Blocked actions (rm -rf, force push, secret access) count as avoided risk, not avoided cost.
• Budget stops and handoffs are counted, without an amount.

How savings are shown:

• API users: dollars.
• Subscription users: additionally as a share of a 5-hour limit. The status line receives the used share of the current window; dividing the cost accounted in that window (per-hour buckets) by that share gives the API value of a full limit. The last good value is cached for 14 days.
• Everyone: the API equivalent.

Not shown yet: the Pro comparison ("with Pro it would have been ≈ X"). It appears once Pro's compression and routing exist and can be measured.

The /steinwall:report command (or steinwall report [--date YYYY-MM-DD]) shows the day's cost, savings, guard and loop counts and handoffs, plus 7-day and month totals. The first session of each day shows yesterday's summary in one line.

~/.steinwall/config.json (or steinwall config set <key> <value>):

Try the guard without an agent: steinwall check "git push -f origin main".

.claude-plugin/plugin.json   plugin manifest (+ marketplace.json for local installs)
hooks/hooks.json             PreToolUse, UserPromptSubmit, Stop, SubagentStop, SessionStart
commands/                    /steinwall:status, :budget, :setup
src/core/                    agent-independent core: config, pricing, usage, budget, guard
src/adapters/claude-code/    hook + status line; the same hook serves Codex (src/bin/codex-hook.ts)
.codex-plugin/plugin.json    Codex manifest; hooks/codex-hooks.json; .agents/plugins/marketplace.json
skills/steinwall/            skill for both agents: status, report, scan
agents/scout.md              Pro routing subagent (Haiku)
src/core/license.ts, pro.ts, rules.ts, dashboard.ts, card.ts   Pro and licensing
src/mcp/server.ts            MCP server (`steinwall mcp`)
backend/worker/              Cloudflare Worker (checkout, stripe-webhook, license, license-refresh, telemetry) + D1 schema
site/                        website (landing, pricing, license page, guides, legal placeholders, llms.txt)
docs/LAUNCH.md               launch checklist: everything that needs your accounts or decisions
dist/                        compiled output, committed (plugins install without a build step)

Development: npm install, npm test.

• Hooks fail open: an internal error is logged to ~/.steinwall/logs/errors.log, and the agent continues. The hook always exits 0.
• State is stored as small JSON files: one per day plus transcript read cursors. A cross-process lock is used because several sessions run hooks at the same time. The briefing proposed SQLite. JSON keeps the plugin free of dependencies and works on Node 20. Storage sits behind usage.ts, so it can be swapped later.
• The scanner is rule-based (src/core/scanner/rules.ts). Each rule has a severity per context: Markdown the agent reads, code that runs, or config. The rules were calibrated against the 400+ files of the official plugins bundled with the Claude desktop app, and all of them come out clean. A finding is an indicator, not proof, and "OK" is no guarantee. Known-bad packages are listed in src/core/scanner/signatures.ts, each with its source; entries in ~/.steinwall/signatures.json are merged on top.
• Limit data (rate_limits) only reaches the status line, so the proactive handoff needs the SteinWall status line installed. Without it, only the fallback after a limit hit applies.
• Hook latency is dominated by Node startup. SteinWall's own work is about 10–15 ms per call.

Functional Source License 1.1, MIT Future License (FSL-1.1-MIT). You may use, copy, modify and redistribute SteinWall for any purpose except offering a competing product or service. Two years after each version is released, that version becomes available under the MIT license.