Up.computer

The problem

Coding agents can now work on their own for an hour or more. The bottleneck moved to the person running them. Every task gets its own thread. You switch between threads, check which ones finished, carry context from one to the next, archive the old ones and start new ones.

Run five agents like that and you stop building. You become their project manager.

Threads are a bad unit of work for agents. A thread fills its context, hits a limit and dies. A task doesn’t: it has a status, an output and a history.

The idea

Stop treating a thread as a task. Treat it as a conversation with your chief of staff.

You describe what you want. The chat turns it into tasks and hands them to agents. The agents pick them up in the background, pass them to each other and send them to review. Your job is the direction: what to build and whether the result is good.

The mechanism is simple. Each task has a status and tags. Each agent has a rule like “start on tasks in To Do with the tag dev”. Changing a status or a tag is what starts the next agent, with its own model and instructions.

Four design decisions

1. The orchestrator is a chat, not a dashboard

Any chat can create tasks and agents, check status and change the setup, because those are tools the chat agent can call. There are Tasks, Agents and Automations views, but you rarely need to open them.

Up.computer used to have a separate Orchestrator mode with its own proposal flow. It is gone now: any chat can be the orchestrator.

2. Statuses and tags are the triggers

A task has a title, a description, a status, tags and an output. Statuses and tags are plain text, not a fixed pipeline. An agent starts when a task matches its status and tags, so moving a task is how work gets handed off.

Two rules keep this from turning into chaos. An agent runs again on the same task only after something real changed, so agents don’t loop. And by default each agent takes one task at a time and hands off to the next, so a queue forms on its own.

3. Every agent has its own CLI, model and instructions

An agent is a saved definition: instructions, a CLI and model, a runtime mode, an optional project and a trigger. In my setup Opus develops and GPT reviews, so every change gets a second opinion from a different model.

Up.computer works with Codex, Claude Code, Cursor, Grok Build and OpenCode. Each one runs on your own subscription. You don’t fill in agent forms by hand: you describe the role in the chat and it creates the agent.

There is no usage meter. When I have quota to spare, I say so in the chat, and it switches the developer to fast mode and adds a rule to the shared instructions for new tasks: keep each one small enough to finish in one run.

4. One chat, many projects

A chat doesn’t have to belong to a project. You can start one with no project and link projects later; it then shows up under each of them. Tasks carry their own project, so one conversation can send work to the website and the app at the same time.

In the sidebar, a letter badge marks each chat’s project, and counters show the task runs a chat started: working and done. You see progress without opening anything.

How it was built

Up.computer is a fork of T3 Code, an open-source desktop app for coding agents. T3 Code gave me the runtime: provider sessions, the desktop shell and release plumbing.

What I added on top:

• the task, agent and automation system, and the trigger rules behind it;
• orchestration from any chat, plus shared instructions that agents can edit;
• a browser and computer use, so agents can check their work on screen;
• the product design: the interface, the brand and the website.

Most of the code was written by agents running inside Up.computer itself. I set the direction, wrote and reviewed the tasks, and checked every result by hand. That loop is the product: I was its first and heaviest user for five months.

Where it is now

Up.computer was released on October 6, 2026. It’s free, MIT-licensed and runs on macOS, Windows and Linux. Chats stay on your computer, and it doesn’t resell models: you keep paying your providers what you pay them today.

What I learned

Design for agents as users

The task system is run by agents, not people. Its real interface is the tool descriptions and trigger rules the agents read. Writing those clearly mattered more than any screen.

Build capabilities as tools, not modes

Removing the Orchestrator mode deleted two packages and its proposal pipeline, while the task, agent and automation tools stayed exactly as they were. Every chat can call those tools, so every chat can orchestrate, and there is one kind of chat instead of two.

With agents, the designer moves upstream

When agents write the code, the slow part is a clear task, a clear way to check the result and taste about what to keep. That is design work, and it is where I spent most of my time.