The Death of a Product: Notes from Wrapping Up mpg

Anthropic's pricing change is the trigger, but mpg was always going to be obsoleted. What I learned from building a tool the platform absorbed — and what's left to build that it won't.

2026-05-18

There's a particular kind of obsolescence that's specific to the AI tooling era: the platform catches up, and your product becomes a feature.

Anthropic recently announced that Claude Code usage through the Agent SDK and claude -p — the headless, non-interactive mode — would no longer be covered by the Claude subscription. Both are now billed at API rates. For mpg, the multi-project gateway I built two months ago and that drives most of my development workflow, this is a structural change. Even modest use of mpg against my own projects pushes monthly cost well past $800 at API rates.

It's the same pattern that ended OpenClaw for me. The tooling layer I'd built was depending on a pricing structure that wasn't a stable commitment. When the structure shifted, the economics shifted with it.

But the pricing change is the catalyst, not the cause. mpg was always going to be obsoleted, and that was always part of the bet.

The Bet I Was Making

When I first wrote about mpg, I said something I want to repeat here: the tool was solving a problem the official Claude platform was going to solve eventually. I built it because I needed it now, not because I expected to own the category long-term.

Look at what mpg's last few versions actually added:

• A router for multiple projects through a single Discord bot — because the official plugin only supported one project per bot token.
• Agent personas with explicit handoff grammar — because Claude Code didn't yet have first-class multi-agent coordination.
• Per-thread git worktrees — because shared workspaces caused conflicts when agents worked in parallel.
• A dashboard for token usage, cost, and session metrics — because there was no observability layer for AI workflows.

Each of those was a workaround. Each was a small thesis: here's something AI-first development needs that the platform doesn't ship yet. And each shipped as part of mpg with the unspoken understanding that if Anthropic agreed with the thesis, they'd build it natively, and the workaround would dissolve.

That's largely what happened. Claude Remote now handles most of my remote-access cases. Skill-based personas cover most of what mpg's persona system did. The official Discord integration has matured. A few things mpg still does better — initiating a new session for a workspace directly from Remote, persona-based handover with explicit grammar, some session-introspection niceties — but "almost as good as mpg" is the honest description in most of my workflows. And "almost as good as mpg, plus first-party and stable" wins easily.

The pricing change just made the decision concrete sooner than I expected.

What I Actually Learned

A few things I want to keep, because they apply beyond mpg.

The bottleneck is interface, not capability. The model could already do most of what I needed long before I built mpg. The work was in how I reached it, organized it, and saw what it was doing. This is the thesis behind The Familiar Interface, and it became more obvious with each iteration. The version of mpg that mattered most wasn't the one that added a new capability. It was the one that added a dashboard.

Coordination is the actual problem. Most of mpg's complexity by lines of code was in coordination — routing, handoffs, worktree management, session state. The "AI" part was a single CLI invocation. If you take this seriously, it means most of the value in AI-first tooling is not in the model layer. The model is becoming a commodity input. The value is in the social and operational scaffolding around it.

Worktrees are the right unit for agent parallelism. This is a small technical claim, but I think the official tools haven't fully internalized it yet. Containers are too heavy. File locks are too fragile. Worktrees give you isolation at exactly the right level — shared repository, independent working state — and git's existing semantics handle cleanup for free.

Observability has to exist before you think you need it. I added the dashboard because I felt blind about cost. What I didn't expect was that having visibility would change how I worked. Once I could see which personas burned the most tokens, which projects had pathological cache-miss patterns, which sessions ran longer than they should — I started organizing my work around that signal. You can't manage what you can't see, and AI workflows are invisible by default.

The Bigger Thing

Zooming out, mpg was a small case study in something larger: most of our software-development tooling still assumes a human at the center, and we haven't started seriously asking what changes when the human moves out of the loop.

Think about how much of the stack was designed around human cognition.

Version control gives us line-by-line diffs because humans review code line by line. Commit messages are written to be read by future humans. Branches are social structures — naming conventions, ownership, who-can-merge — designed around teams.

IDEs are full of human affordances. Syntax highlighting exists because human eyes get tired. Autocomplete exists because humans can't remember APIs. File-tree sidebars exist because humans navigate spatially. None of these are wrong; they're just optimized for a particular user.

CI/CD assumes humans push code and humans read results. Test output is formatted for human reading. Failures fan out into dashboards that humans triage. Deploy gates require human approval, on human pacing.

Issue trackers, code review, documentation systems, deploy pipelines — all of it is workflow built around human-in-the-loop cycles, human-readable artifacts, and human cadence.

Now imagine the agent is the primary worker and the human is the architect, reviewer, and director — which is increasingly where my own workflow has landed. A lot of these affordances stop being load-bearing, and a lot of them become friction.

• Diffs as line-by-line changesets matter less than diffs as summaries of intent. The agent knows what it changed and why. The artifact the human wants is "tell me what changed in plain English, and why."
• Commit messages become audit trails for spot-checking, not communication between teammates. They should be machine-generated and dense.
• Test output formatted for humans is wasted bandwidth. The agent doesn't need a pretty stack trace; it needs structured failure data — and humans only need to see what survived triage.
• CI runs triggered by PR creation are tied to human pacing. If the agent is iterating continuously, CI wants to be continuous too — verifying on every save, not on every push.
• Documentation written for human aesthetics is a different artifact than documentation written for agent ingestion. We're going to need both, and they're going to want different formats.
• File systems organized for human navigation are a pre-emptive optimization the agent doesn't need. The agent searches. The agent indexes. The agent doesn't get lost in a deep folder tree.

I don't want to overclaim here. Humans are still in the loop, and they will be for a long time. The point isn't that human-centric tooling is wrong. The point is that almost every assumption underlying our current tooling was made for a workflow that's quietly changing underneath it, and we haven't really sat with what that implies.

The interesting work — the work that doesn't get absorbed by the platform in twelve months — is upstream of the tooling. What does version control look like when agents are the primary committers? What does code review look like when its job is to surface taste-level decisions, not line-level mistakes? What does CI look like when "the build is always running and the agent self-corrects"? What does an issue tracker look like when issues are the primary memory the agent uses across sessions?

These are not questions mpg was going to answer. mpg was a chat app pointed at Claude Code. But the experience of building it surfaced the questions, and that's the part I want to keep.

What mpg Becomes

I'm not deleting it. I'm narrowing it.

A few cases where it still earns its keep, at least for now:

• Persona-based handover with explicit grammar doesn't have a first-party equivalent that fits my workflow. When I want a PM agent to dispatch concrete tasks to an Engineer agent under structured constraints, mpg's HANDOFF @agent: syntax is still the cleanest way I have to do that.
• Some session-introspection commands — especially the !session → resume-in-CLI bridge — are how I move work between phone and desk.
• The dashboard data is worth keeping just to keep tracking my own token economics.

Maintenance mode, not feature work. Most of what I'd previously have built into mpg will get built into Claude or against the official SDK now — and the cost of the SDK path, where it makes sense, is something I'll pay deliberately rather than by accident.

The Pattern

Most of what we're building in AI tooling right now is provisional. If your tool can be absorbed by the platform in a year, that's not failure — it's signal that you were directionally right and that the platform agreed.

The thing worth building is the layer the platform won't absorb because it isn't a feature. It's a way of thinking about software engineering that assumes the human is no longer at the center of the loop. That's slower work, and I don't fully know what it looks like yet. But I think that's where I want to point next.

mpg goes into maintenance. The questions it surfaced stay live.

The source for mpg is at github.com/yama-kei/multi-project-gateway. The full mpg arc is in From tmux to Discord, From Message Router to Agent Team, and The Familiar Interface.