At some point, I noticed that I had stopped closing terminal tabs.
One had an agent halfway through a feature. Another contained a useful investigation I didn’t want to lose. A third was waiting for me to answer a question. I kept them all open because each tab held a piece of project state that existed nowhere else.
The terminal had quietly become my filing system.
I like coding agents, and I’m generally comfortable letting them do real work. The problem wasn’t that they were doing too much. The problem was that, once I had several projects and sessions going, I had no good way to see the whole picture.
Which ideas were still rough? What was ready to build? Which session was running? What was waiting for me? What had already been tried?
Checking terminal tabs one by one wasn’t a workflow. So I started building ArchCode.
A place for the work around the code
ArchCode is an open-source cloud workbench for AI coding.
By “cloud,” I don’t mean that it has to run on somebody else’s infrastructure. It can run on the same laptop where the code lives, on a workstation under your desk, or on a remote server. You choose the machine. The browser is simply how you manage it.
I wanted the workbench to cover more than the moment when an agent is writing code. Most project work starts much earlier than that.
Sometimes I have a clear bug to fix. Other times it’s just a vague thought:
This part of the codebase is getting difficult to change. I should look into it later.
That isn’t ready to become a prompt, but it’s still worth keeping.
ArchCode gives every project its own Todos, where I can save features, bugs, refactors, experiments, or half-formed ideas. A Todo can sit there until I’m ready to think about it. I can discuss it with an Agent, work out what I actually want, and only then mark it Ready.
When the time comes, the Todo can become a real Session or an Automation. The original idea stays attached to the work instead of disappearing into a new chat window.
That flow now looks like this:
Idea → Discussion → Ready → Session or Automation
It sounds simple, but this was one of the main things I was missing from existing coding-agent tools.
Multi-agent, but with someone in charge
I also wanted multi-agent work to have a clear owner.
“Multi-agent” can easily turn into several agents talking to each other without anyone being obviously responsible for the result. ArchCode takes a more straightforward approach.
A Lead owns the task. It can do the work directly, but it can also bring in specialist Agents when there is a clear reason:
- Analyst for deeper analysis and review
- Build for implementation and verification
- Explore for quickly investigating the codebase
- Librarian for documentation and external research
A small change may only need the Lead. A larger task might need an investigation first, a Build Agent to implement it, and an Analyst to review the result.
I don’t want more Agents for the sake of having more Agents. I want each one to have a recognizable job, its own tools, and a clear boundary around what it is responsible for.
ArchCode runs its own Agent runtime. It isn’t a Web UI placed on top of Claude Code, Codex, or another coding CLI. The server owns the Agent execution, Sessions, tools, approvals, memory, and durable state.
That distinction matters because the Session remains part of the project even after a particular run has finished. Its conversation, model choice, tool activity, decisions, and execution history are still there when I come back.
The browser is a control room
The actual Agent work runs on the ArchCode host, not inside the browser.
That means I can start something on a machine that stays online, close the page, and check it later from another browser. As long as ArchCode and the host machine are still running, closing the tab doesn’t cancel the work.
From the Web UI, I can move between projects, follow active Sessions, add instructions, answer questions, approve sensitive actions, inspect changes and test results, or stop something that is going in the wrong direction.
I don’t want an Agent to interrupt me for every harmless command. That would defeat much of the reason for letting it work in the background. I’d rather give it room to operate and bring me back in when there is a real decision to make.
For work that needs stronger isolation, ArchCode can be run inside a controlled machine or virtual environment. Self-hosting doesn’t remove security concerns, but it does let me decide where the boundary should be.
The Agent role and the model are separate choices
Using the strongest model for every piece of work gets expensive quickly. It also isn’t necessary.
ArchCode has three configurable model Profiles: principal, deep, and fast. I can use a stronger model where judgment or review matters, then use something faster, cheaper, or local for routine implementation and codebase exploration.
The Agent’s responsibility stays the same even when the model changes.
This is important to me because I don’t want the workflow tied to one model vendor. ArchCode supports different providers and custom OpenAI-compatible endpoints, and a Session can use a different model when the job calls for it.
The models are replaceable. The project history and workflow are not.
What I’m actually trying to build
I’m not claiming that ArchCode makes a model write better code than Claude Code, Codex, or other established coding agents.
That isn’t the problem I set out to solve.
I’m trying to build the layer around the coding: the place where ideas wait, work gets shaped, Agents take responsibility, Sessions keep running, and I can see what is happening without opening six terminals.
ArchCode is still early. It is currently built for one private operator rather than a multi-user engineering team. Active work can survive a closed browser, but not a restart of the ArchCode server yet. Remote deployment also needs proper authentication and network security.
There are rough edges, and I’m sure parts of the workflow will change once more people use it.
If you already have several projects or coding agents running at once, I’d like to know what you lose track of first. That’s the problem I care about most.
The source code and installation instructions are here:
I used AI assistance to help organize this draft and polish my English. The experience and product decisions are mine, and I reviewed every technical claim before publishing.
Top comments (0)