Benjamin Anderson
github logo linkedin logo rss feed

Building Auto Mode for Open Models

I can be your angle... or yuor devil.

Posted Aug 29, 2026 by Benjamin Anderson

Open-source models are getting too good to ignore. The latest Kimi, Deepseek, and GLM models are near-frontier, and freely available for anyone to run. While I remain a skeptic about the economics of self-hosting your own Deepseek on a DGX Spark or 17 connected Mac Minis, open models hosted by providers who can benefit from sufficient scale now offer a compelling cost-capabilities tradeoff. And, while I don't expect OpenAI to give all of us the Cursor treatment anytime soon, it's smart to not depend too heavily on on a single provider who may decide to compete with you tomorrow, or decide that your use case is "too dangerous" to support. (Not to mention—how will I burn all these Cloudflare credits?)

But when evaluating open source models for coding (my primary use case), there's a lot more to be paranoid about than a lab pulling the plug on you. Hugging Face hack aside, Anthropic's and OpenAI's models are among some of the most aligned and trustworthy models around, which lets you unclench a bit when using them to code. GLM-5.3 doesn't even have a public model card documenting its safety properties, but we know it's damn good at cyber. Models from outside the U.S., especially ones from "adversaries" like China, present elevated risk; regardless of the good intentions of the companies and founders behind them, it's too easy for the Chinese government to lean on them. A U.S. host like Baseten, Cloudflare, or Modal helps (at least I can sue them if they misuse my data!), but even then who knows, the models could be "sleeper agents" and send all my data to evil dot com.

In my opinion, the correct attitude when using open models (and honestly, any model) for anything but a to-do list app is paranoia: run them sandboxed, lock down secrets, review every tool call, and so on. But how? What harness to use? Are the people who make the harnesses as paranoid as I am? In the rest of this post, I'll share my first steps towards getting comfortable using open-source models to code, including my new Pi extension, Pi Guardian.

Choosing a Harness

There's no shortage of coding agent companies offering access to open source models via their product. My first serious-ish dabble with open-source models was using the Devin CLI, when I randomly was picked to get 6 months of free Devin Max. (It's good now, folks!). I actually did find Devin much-improved, and enjoyed dispatching parallel Kimi/GLM code review agents to comb through my commits alongside Codex, but didn't use it enough to justify paying actual dollars for it. You can get similar offerings from Factory, Cursor, OpenCode, Amp, and I'm sure dozens of other companies who want to be the "model-neutral coding platform thing." This is is probably the way to go for an enterprise who wants to use open-source models to code in a non-stupid way, as the harness bakes in safeguards like sandboxed execution. Unfortunately, Cognition's CLI only works for Devin. (Factory supports BYOK, but I haven't tried it.)

Another option is to try to make Claude Code or Codex work directly with a third party model. This is ostensibly possible, but I'd classify it as "moderately to extremely annoying." The Codex CLI has deprecated support for Chat Completions (supporting it was hampering their product roadmap), and that's the most common language that model APIs speak. Similarly, Claude Code only works with Anthropic's Messages API, which is actually a better-designed API, in my opinion, but is likewise not widely supported. In both cases, hooking them up to a third-party model involves a brittle, arcane assembly of environment variables and settings files, which is easy to get wrong and hard to port across machines. These harnesses also aren't really designed to work with other models—they're increasingly co-designed and co-trained, and when you drop another model in (like I tried to do with Inkling-Small last week), it gets freaked out by all the system-reminders, which it isn't used to.

There were 2 remaining harness options I was excited about, in large part because they're open source and therefore hackable: OpenCode and Pi. OpenCode has a big complicated codebase, with a fancy TUI and lots of other out-of-the-box stuff, whereas Pi is intentionally minimal, hackable, and extensible, and includes a long list of things they refuse to build. Neither one has built-in sandboxing, or an equivalent to Claude/Codex "auto-mode" (where a sidecar LLM approves or denies tool calls), so I decided to play around with Pi, as it's designed for users to extend. If nothing else, I was excited to see what all the fuss was about.

Designing Pi Guardian

My test case was (safely!) running GLM-5.3 with Cloudflare as the API provider. GLM-5.3 is the smartest open-source coding model available, and Cloudflare is a company where I have thousands of dollars of credits I need to burn before they expire. A match made in heaven. It's easy to get any model to run in Pi, on account of the fact that they built their own LLM-gateway-thing (similar to my project, lm-deluge) that provides a shared interface to basically every imaginable model and provider. As long as you've got the right environment variables, you're good to go.

So the tricky part was to make it safe to run it on my laptop without it having the ability to insta-delete my home directory. Sandboxing is great (and there's already Pi extensions for it!) but ultimately, it's insufficient for human-in-the-loop coding on your machine, where it's inevitable you're going to want to do something outside the sandbox (wait, go fix thing in other repo, also prune my Docker cache and rebuild the image, then please open a browser to find that documentation). Sandboxing can reduce the number of approvals required, but for the truly buttery-smooth coding agent experience that I'm used to in Codes, "auto mode" is non-negotiable. (And it makes the sandbox less necessary, though using both is ideal.)

Rather than reinventing the wheel, I dug into how Codex implements its auto-approval mode, which I'm somewhat familiar with due to previous side quests. The TL;DR is that Codex runs a dedicated, second Codex session with a "guardian" model (previously gpt-5.4, now I think it's Luna). The guardian steps in when the main Codex thread wants to escalate a command outside its sandbox. The guardian can see the conversation history and the escalated request. Importantly, each subsequent escalation in the same session goes to the same guardian thread rather than a fresh one, which allows cache hits and provides context about previous denied/approved requests. That makes it obvious to the guardian when Codex is trying to evade a previous denial. When a denial is handed down, the main Codex receives the reason, and a nudge to not try to evade it.

I instructed Codex to implement the same basic system as a Pi extension. Important features included parallel approvals for parallel commands to keep it speedy, a persistent guardian sidecar thread, clear visibility into whether it's enabled, and a simple command to toggle it on and off. Oh, and of course, a cute whimsical "guardian"-themed TUI widget.

guardian enabled

guardian enabled

The default setup uses gpt-5.6-luna, which can be configured to use your Codex subscription! You can configure it to use any model that Pi supports. Typically you'd want to use a lighter/cheaper model than the "main" model. You'll a spinner while waiting for approval; when the guardian approves or denies a command you'll see the result with its reasoning. (This is also provided to the main model, so it can keep going in spite of the denied tool call.) This allows you to run Pi with an extra safety layer, without constantly getting pinged for manual approvals.

guardian enabled

I took this for a test run today, and it seems to work well—it blocked GLM-5.3 from trying to read my NPM token. (GLM found it funny.)

guardian enabled

This package is now available on npm (pi-guardian), and its source code is published on GitHub. You can install it in your Pi with pi install npm:pi-guardian, but it defeats the purpose of improving your security posture if you don't at least read it first, so maybe go do that.

Conclusion

I'm very excited to figure out where cheaper, open-source models can fit into my coding work. Though the risks of widely-diffused cyber capabilities are a bit nauseating to think about, I'm generally a big fan of open source AI efforts, and I feel like a hypocrite cheering them on while using primarily closed models. But figuring out where these new models can shine requires trying them out, and that means finding the right harness and building trust that the model won't delete all your stuff. I hope Pi can be that harness (we'll see!), and I hope Pi Guardian can help build the trust. Please reach out if you found this interesting!

P.S. — I would be remiss if I didn't mention prior art. There are lots of other Pi extensions that also approve commands with an AI classifier. But this one is mine. :)


« Previous post: Async Coding Agents — The Rest