Grindhouse
A fully remote environment for running and supervising coding agents. The agents run on your own computer or a rented server; you direct and review the work from any browser, on desktop or mobile, wherever you are. Every line of its code was written by agents, almost all of it through Grindhouse itself.
- Go
- Elixir
- WebSockets
- Agent loops
- Browser and mobile
Why I started it
The remote-control experience I used with coding agents kept breaking, particularly when I moved between several projects. Grindhouse began as browser-based terminal management so I could run and control multiple agent sessions on my own computers.
Experimenting with pi.dev showed me how useful a smaller agent with clean initial context could be for my workload. I first connected it through an RPC adapter and tunnels. As process startup and restarts became recurring overhead, I replaced that integration with an agent loop designed around Grindhouse’s remote architecture.
Architecture
The executor stays beside the code
The server provides remote control and organisation; it never holds the repository.
Go CLI
Runs the agent loop on a developer’s computer or rented VM. Go makes it straightforward to ship fast cross-platform binaries with few external dependencies and persistent WebSocket communication.
Elixir server
Uses the BEAM runtime for concurrent, long-lived connections. It groups agent runs by project and task and maintains remote control of each connected computer.
Pluggable agent runtimes
A native Grindhouse agent that is fully configurable and adjustable to each project’s needs, or a locally configured Claude Code or Pi installation. Each conversation keeps its own context; child conversations inherit what they need rather than the whole transcript.
Independent testing agent
A second agent exercises the application through a browser or computer-use tools and reports back, so review evidence does not come only from the agent that wrote the change.
How I use it
I normally have several tasks running across more than one project. The amount of decomposition and supervision depends on each task’s complexity and effect on the rest of the system.
- Research and context
Explore the problem, the existing system and its constraints, and gather the information the implementing agent will need. Most failed agent runs trace back to this step being skipped.
- Architecture and vertical slices
Split higher-impact work into small end-to-end increments that can be exercised before the next one expands them.
- Implementation and review
Agents write the code. I read the changes for defects, unnecessary complexity, and structures that do not fit the system.
- Independent application testing
A separate agent uses the application through browser or computer-use tools. It can inspect code and logs when blocked, then reports what it found.
- Issue routing and judgment
Clear issues go back to the development agent with context. Ambiguous reports get a second model’s opinion before I decide what changes.
Building Grindhouse with Grindhouse
All code in Grindhouse has been produced by agents, and roughly 99% of its development has happened through Grindhouse itself. Manual editing is available but has not been necessary.
The exceptions occur when a self-update is incompatible enough to prevent Grindhouse from restarting. In those cases I run another agent locally to repair it. The fallback still uses agent-produced code; only the route to the agent changes.
Current status
Grindhouse is in closed testing and currently focuses on individual developers managing several streams of work. I have started exploring shared organisational context, skills, and agent configuration as a path towards team use.