AgentWrangler is out. GitHub shows 78 commits; the real number is 3,686

If you open AgentWrangler on GitHub, you'll see 78 commits. My local copy of the same project has 3,686, spread over 57 days of work between August 21 and October 21. Both numbers are accurate. The gap is on purpose.

AgentWrangler is the tool I said I was building at the end of the two token posts from August: why you hit your Claude Code limit and where your API bill comes from. Back then the code was local and only a planning doc was public. That's changed. The latest release is on the public repo under the Apache-2.0 license, and the npm package agentwrangler has been updated to match.

What it does

You run one command:

npx agentwrangler@latest

That starts a small background service (a daemon) and a dashboard at http://127.0.0.1:2929. The daemon reads the session logs Claude Code already writes to ~/.claude/projects (JSONL files, one JSON record per line) and stores what it learns in a local SQLite database, a single-file database that lives at ~/.agentwrangler/db.sqlite. From there it shows where your tokens went, which sessions were expensive, and whether a change you made actually helped.

On top of the raw numbers sit 31 detectors, small rules that each look for one costly pattern in your sessions. Per the changelog, each detector is tested with a fixture that should trigger it and a near-miss that shouldn't. Detectors feed recommendations, and recommendations get a 14-day observation window to see whether anything moved. If the effect can't be measured, the dashboard says "Effect not measured" rather than guessing.

The README is blunt about limits, and I'd rather quote it than paraphrase it: "Dollar figures are list-price equivalents, not your subscription bill. Modeled savings are not achieved savings, and observed improvement does not prove the change caused it." I haven't validated the savings estimates against anything external, so you won't see a dollar-savings claim from me here either. It's a single-user tool, it's been validated locally on Windows with smoke tests on Linux and macOS in CI, and the macOS-specific prompts haven't been tested on a real Mac yet.

Why the public repo is an export, not a mirror

The private repo is where the build actually happened, and it's full of things that should never be public. The plans the agents worked from. The handoff notes between sessions. Research and design scratch. The agent configuration. And a review of my own real token usage and real dollar spend, dated the day the repo was created.

So the history doesn't ship. The public repo existed from August 20 as a placeholder with a planning doc, and at the first public release on September 4 it got a fresh tree; the private history has never been pushed to it. Every public change since then comes from one export script, and its job is to stop anything that shouldn't leave:

A manifest decides what's public. A text file lists INCLUDE, EXCLUDE and OVERLAY rules, and the most specific rule wins. Plans, handoffs, research, design notes, spikes, the agent configuration directory, the spend review and some calibration data are all excluded. The private CLAUDE.md and README.md are swapped for public versions. The export tooling excludes itself, too.
The tree is built from committed HEAD only, so nothing uncommitted in my working directory can sneak along.
Then the gates run. An anonymization grep. A raw-content scan of the tree. And trufflehog, an open-source scanner that hunts for credentials like API keys and tokens. If any gate fails while the script is trying to push, it stops. Fail-closed (a failure blocks the action instead of letting it through) is the only setting I'd accept for this.
It never pushes to public main. It pushes a branch named after the private commit and opens a pull request, so every public change lands through a reviewable PR. That's why the public history reads as a run of PRs from export/... branches instead of normal commits.

One rule keeps the two repos in sync: changes land on my local main first and then get exported. A fix made only on the public side gets overwritten by the next export, so the public repo is always a filtered copy of my local main.

The private material was the main reason, but not the only one. I wanted each release to work when someone installed it. So every release goes through the export scans for secrets and personal data, then the whole test suite: local tests, cross-platform compatibility checks in Docker, and the CI pipeline. The project went public fast, two weeks after the first commit, but it ships as big releases instead of a live public history. I'd do it the same way again. Plenty of large open-source tools publish like this.

Here's the part I'd argue for: when agents write your code, your commit history is full of things you never meant to publish. Agent-driven work leaves plans, prompts, session notes and file paths all over the commit trail, and a lot of those 3,686 commits came from agents working on worktree branches (separate checkouts so parallel sessions don't trip over each other); the main line alone is 2,065. Pushing that history to a public repo would mean reviewing every one of them for something that shouldn't be there. Exporting a filtered copy means reviewing one release at a time, and the scans check every file on every export.

There's a cost. You have to take the 3,686 on my word. The private history isn't publicly verifiable, and I'd rather say that plainly than let the two numbers look like a mistake.

What changed since the teasers

The August posts said AgentWrangler would store "only the counts" and throw the message content away. That promise didn't survive the build. The shipped docs say so. The database stores aggregates and structural data, plus shell-command text that has passed through a secrets filter and short, bounded excerpts of error messages. The privacy doc calls that filter "best-effort pattern matching, not a guarantee," which is the accurate description. What still holds: nothing it stores leaves your machine, gets committed or gets published. There's also an optional hook that saves raw transcript copies before Claude Code compacts a session, capped at 20 files and 500 MiB and readable only by your user where the OS supports it. You install it on purpose or you don't have it.

The rest of the controls fit in a paragraph. The daemon binds to 127.0.0.1, the loopback address only your own machine can reach. A web page you visit could still try to send requests to a service on your laptop (cross-site request forgery, or CSRF), so the daemon checks the browser's Sec-Fetch-Site header, then an exact-match allowlist of origins (127.0.0.1, localhost, [::1]), and answers everything else with a 403. Write requests also need a token minted fresh each run. Your login stays yours: AgentWrangler doesn't send your Claude login token anywhere, reads plan usage by running your own claude -p /usage, and strips ANTHROPIC_API_KEY from the environment of any claude it launches. An earlier version handled usage differently. This one was redesigned so it never touches the login.

Nothing acts for you by default, either. One-click "apply this recommendation" is switched off and the server refuses it outright; you can copy a prompt instead, or turn on "Open in Claude Code" under experimental settings. The optional guardrail hooks (scripts Claude Code runs around tool calls, here watching context budget, loops and dangerous commands) no longer skip Claude Code's own permission prompt.

None of that is exotic. Bind locally, check origins, keep secrets out of child processes, don't take actions without a person in the loop. It's the boring list I'd ask a vendor about, applied to my own tool.

What it taught me about my own usage

Building a tool that watches token spend made me look hard at my own. These were the expensive habits:

Subagents (helper sessions the main agent spins up) inherit expensive defaults unless they're told otherwise. A rule in my global CLAUDE.md, plus a hook that requires every dispatch to name a model, fixed that.
My agents were forking subagents, which hands the child a copy of the whole conversation, instead of starting fresh ones with a short brief. That ate a big chunk of my weekly usage before I caught it.
Every session pays for whatever loads at startup. I cut mine by pulling the skills and components I actually used out of plugins like superpowers and compound-engineering, instead of loading whole plugins when I wasn't using 90% of them.
Agents re-read big files more than they need to. If a handoff note points at a long master plan, it should name the section and line numbers, so the next agent reads the part it needs instead of pulling the whole file into context.

When I really was up against the limit, I moved the heavy lifting to Codex models and kept Claude as the orchestrator, handing work to Codex workers through Claude Code's dynamic workflows (scripts that fan a plan out across many agents). The planning and orchestration skills I built for that, dynamic-workflows-plan and dynamic-workflows-codex, are public in my claude-skills repo.

What's still open

There's no adoption story yet. As of this week the repo has no stars and no forks, and I'm not going to pretend otherwise. The test suite is large, around 5,500 test declarations across 616 files in the private repo by a static count (the public surface is a subset), but the number that matters is whether the detectors are right about your sessions, and I haven't had them independently audited. The savings figures are models, and the README says so on the front page.

What I'm sure of is the design. The tool runs on your machine, reads what Claude Code already writes, and tells you which habit is using up your allowance, not just that it's gone. Your data stays on your machine, and my private build stays on mine; the public repo only gets what passed the export scans. Whether 31 detectors written by one person and a lot of agents are tuned well enough for anyone else's workflow is something only other people's sessions can answer.