Show HN: Cosplay as a tech lead, using gVisor to sandbox agents (github.com)
This started as an exploration into harnesses and locally hostable LLMs (the kind that uses less power than a small electric heater), and I used it as an opportunity to retool. I've tried popular ones like Cline, Claude Code, and Pi, but wanted a different UX and integrated sandboxes.
The solution that I've landed on is a responsive web interface where I can quickly drive progress. It feels like a microcosm of my day job: define and delegate tasks, organize using kanban, then review deliverables. And it also feels like the time I used to spend coding is now spent in code review with the agent, so I tried to optimize the UX to make review feel nicer.
One of my (maybe a bit niche) benchmark use-cases is how pleasant it is to make progress on hobby software projects while also out on a hike. This meant specifying low bandwidth usage and offline mode.
Now I can jot down an idea, start the task, and at some point down the trail: get a notification* that either clarification is needed, a decision needs to be made, or the code is ready for review. I've been having a good time with this.
To build MIKE, I exclusively used locally hostable LLMs (from Google, Meta, Qwen, Poolside, and DeepSeek) hosted with llama.cpp on my machines at home (Strix Halo and a 5090) to "compile" the code. The experience has gotten substantially better ever since DeepSeek’s release in July. Side note: I have a soft spot for llama.cpp since it was one of the first that made it possible to run this new tech at home, and its maintainers accepted a tiny improvement I made to error reporting. Oh the joys of having a PR get approved.
I plan on maintaining this, at least until similar features are supported by better tools. Until then, hope you find this useful!
5 minute demo: https://youtu.be/jexzLkZ50FU
p.s.
I didn't mention details about the sandbox earlier since most people seem to find this a bit boring. It was one of my critical requirements, and I opted to use an existing battle-tested sandbox. I'm not an expert on how the Linux kernel works, but seeing all the VM escape exploits recently is a bit scary, and I liked gVisor’s approach to the problem.
I'm also using Git worktrees to provision the agent’s workspace, as well as a read-only repository mount to provide relevant context when the agent looks for it.
*off by default
11 comments
[ 140 ms ] story [ 940 ms ] threadI'd resigned myself to using openclaw's work board, but for throwaway environments, it was a bit too heavy.
I've not looked at this project in depth yet but does the harness support task push from the board (to start an LLM)?
Does it also support lifecycle events for LLM outages (mark things expired, failed, support idempotent tasks and put back a step in the queue if they reach those states etc)?
If this could support Cron based starting of tasks too, that would cover all my use cases...
Thanks for creating this :)
In working with local models, the main issues I've seen are failed tool calls, getting stuck in loops, or some other upstream issue with the inference server. Auto-retry logic helps keep things going, and tasks will sit in review for your action if they get stuck. In those situations, you can either adjust the instructions or change to a more... obedient model and put it back in the work queue.
I've experimented with a few inference services too, which tend to have other issues like how they handle rate limits. I added configurable client side limits (concurrency and reqs per minute) to make this run more smoothly.
For programmatic access: this features a RESTful Web API using a Bearer token for authorization. After generating a token (via Settings -> About), you could them have a cronjob run basic curl with a payload to start tasks. I haven't spent much time on the documentation for this yet; the current docs were generated by agents so they're a bit painful to read. I only reviewed them for accuracy.
Thanks for checking it out!
I'll have to explore reference clones, I'm not familiar with it. Looks like it fundamentally provides better isolation, but not sure how of an advantage it is compared to a worktrees with a secured .git. Thanks for highlighting it.
Fun easter egg on your homepage btw!
I read MAGI right around the time I was looking for existing solutions earlier this year, also enjoyed the Eva vibes.
The "Act" operating mode has strict guardrails, and a card only moves into review if the agent explicitly asks for your review (via tool call) or has a question. It's less prone to unnecessary interruptions. For example agents often decide to pause during a multi-phase plan even though no human input is needed. If an agent decides to pause in this mode, the harness automatically nudges it forward.
The "Explore" operating mode works more like most other harnesses: if the agent decides it's done then it lands in review.
Most recent models (pretty much anything released within the past year) will automatically run tests before it thinks it's done, but you can define this for example by specifying a TDD approach in AGENTS.md. In practice when a task is sitting in review, the agent typically provides a summary about test status; and this is without any special guidance.
I also implemented a "Plan" operating mode, but nowadays models are good enough at following instructions that it might be a bit overkill. This mode mounts the workspace as read-only. I originally made this out of frustration when I used to use Cline (the agent would make changes even when their plan mode was enabled). Another reason why it's overkill is because each task in MIKE already has an isolated workspace. This mode still has some advantages though, especially if you have independent subtasks that can run in parallel.
If you wanted to be more thorough, you could scroll up in the chat and see the output of the test runs. Or to help ensure that the agent doesn't cheat, the test suite could be mounted as read-only. A custom extension could also be set up to run tests independently, and set up as a pre-review gate. However in practice (with recent models), a simple "run e2e tests" instruction in AGENTS.md would make the agent do this reliably, and I don't think I've ever seen a situation where the agent requests review without having run tests (again, with recent models). Specifying that you want to use a Test-Driven Development approach seriously goes a long way too.