Series

Rebuilding My Harness: From Claude Code to Pi

nanoclawclaude-codepi-agentharnessinfrastructurebuild-log

I’m moving my primary coding harness from Claude Code to Pi. This post is the start of a build-log series documenting the rebuild. What I configure, what breaks, what I have to write as extensions, what I miss and what I don’t.

A couple of things lined up this month to make me actually do it instead of keep thinking about it.

The New Stack ran a piece this week framing the personal agent market as a split between OpenClaw and Gemini Spark. Self-hosted on a Mac mini vs managed in Google’s cloud. The argument is that managed wins the mainstream and self-hosted keeps a smaller, developer-heavy floor. That read is doing real work on one question (where does your agent run) and skipping a different question entirely (what runs on top of the substrate you picked).

The two questions aren’t the same. Where it runs is the substrate. What runs is the harness. You can hold either one constant and vary the other, and the decisions interact differently than the article suggests.

On substrate, there are three positions in play now, not two. Your hardware, somebody else’s hardware running your harness (the MaxClaw / MaxHermes pattern, where a model vendor like MiniMax hosts an OSS agent on their cloud), and somebody else’s hardware running their harness (Spark, ChatGPT agent mode, Anthropic managed agents). Most teams will land in the middle one. Few enterprises want to own hardware. Almost none want to hand Google standing access to their inbox.

On harness, the divide is sealed-product vs primitives-you-extend. Claude Code is a sealed product with opinionated defaults. Pi is the opposite. No built-in subagents, no plan mode, no permission popups, no MCP. Everything is an extension you write or install. It’s the same harness OpenClaw uses as its SDK.

The harness-axis decision is the one I’m making this week.

Anthropic shipped managed agents with self-hosted sandbox partners (Cloudflare, Daytona, Modal, Vercel) the same week TheNewStack ran the Spark piece. That’s Anthropic moving up-stack into orchestration and ceding the substrate underneath to four other vendors. Good for managed customers. Less compelling if what I wanted from Anthropic was the loop itself.

I’ve spent enough months inside Claude Code now to know which of its defaults I keep fighting. The sealed surface is a feature when you’re getting started. It becomes friction once your workflow is specific enough that you need the harness to behave a certain way and the configuration knobs don’t go that deep.

Pi inverts the bet. If I want it to behave a certain way, I write the extension. If I want subagents that work the way I think about them, I build that. Upfront cost is real. The payoff is that the harness fits the workflow instead of the other way around.

What I’m going to document in this series

Each post will cover one beat of the migration, with configs included.

  1. The base setup. What I install, what providers I wire up, how I structure AGENTS.md and SYSTEM.md across projects.
  2. The extensions I write. Which Claude Code defaults turn out to be ones I actually want and have to rebuild. Which ones I was fighting all along.
  3. The substrate decision. Once the harness is portable, where do I actually run it. My pi-harness box, a rented VPS, or as an SDK inside something hosted.
  4. The honest accounting. After 30 days on Pi, does the cost of writing extensions exceed the cost of fighting Claude Code’s defaults. If the answer is no, I switch back and write that up.

If a build-log only reports wins, it’s a sales pitch with a different filename. I want this series to be useful, which means it has to be willing to say “this didn’t work” if it didn’t.

Next post: the base setup, with configs.