Introducing Adits: Never Edit Again

Today we're launching Adits — a workspace for editing files with an AI coding agent — in public beta at adits.ai. The whole thing is open source: github.com/ReByteAI/adits.

This post is about three things: what Adits actually does, why we built it, and how it uses Rebyte's Agent Computer API as the engine underneath.

What Adits is

Drop a file in. Describe what you want changed. A coding agent does the work. A new file lands back on disk. You iterate.

The product fits between two patterns that both exist today:

• Manual editing — open the right tool (Photoshop, Figma, Word, Premiere) and make the change yourself.
• AI products — hand the work to a captive assistant inside someone else's UI.

Adits is a third path: the agent does the work, but the agent isn't ours.

Two panes, two nouns. The chat holds the conversation; the bench holds the files. Every file type ships its own viewer — HTML pages, images, PDFs, Office docs, audio/video, sketches — and adding a new one is a single component that the rest of the app picks up automatically.

One rule: a file never appears in the chat, a chat turn never appears in the bench. Every gesture you make on the bench side — adjusting a knob, clicking an element, drawing a stroke, leaving a sticky-note comment — enqueues a chip into the composer. You stack chips, add typed context, and send the whole batch as a single reviewable turn.

Why we built it

When Claude Design shipped, it was the first AI product that felt right for editing files. Drop in the file, talk to it on a canvas, get the change back. The pattern was clear and obvious in retrospect.

The implementation, though, glued the agent and the surface into a single product. You get the model they pick, the billing they set, the format constraints they decide. If you already pay for Claude through your own subscription, you pay again to use it inside the design tool. If next year a different model is better at a particular kind of edit, you can't switch — you wait for the surface vendor to swap it in for you.

That's the captive-AI tax. You're not buying a tool. You're renting access to one, on terms you don't set.

The same pattern shows up across the AI-product space. Cursor for code, Figma AI for design, ChatGPT's canvas mode. They all bundle the agent with the surface. The seam is glued shut.

We wanted the same workflow without the lock-in. Pull the agent and the surface apart and you get a much better product.

Adits is the surface — the workspace, the file viewers, the prompt composer, the bench. The agent is whatever coding CLI is already on your machine: Claude Code, Codex, or Gemini CLI. The CLI runs locally (in self-host mode) or on a per-project cloud VM (in hosted mode). Either way, the agent is something you choose, log into separately, and can swap.

Three things flow from that:

• The model is your choice. Pick the executor in the composer. Adits sends your prompt to that CLI and gets out of the way. Tomorrow's better model arrives via your CLI's update — not via our redeploy.
• The files are your files. In self-host mode every project is a folder on your disk. Hosted mode runs your project in a per-user VM you can leave whenever you want; the source code is open, the export path is plain files.
• The surface keeps growing. Each file type is a registered component; the agent doesn't care about the file type — that's the surface's job.

Open source isn't a marketing move — it's the only way the seam stays open. If we shipped Adits as a closed product, we'd eventually have an incentive to lock the agent slot — favor our model, charge for switching, route traffic through our proxy. The whole point of the architecture would erode. The OSS code at github.com/ReByteAI/adits is the real product. Hosted mode adds infrastructure on top, but the surface is the same.

How Adits uses the Rebyte API

The hosted side of Adits is wired entirely to Rebyte's Agent Computer API. The mapping is small enough to fit in one diagram:

Adits project   ←→   Rebyte agent computer (1 persistent VM)
       │
       ├── User submits a prompt  →  POST /v1/tasks
       ├── User submits again      →  POST /v1/tasks
       └── ...

Three rules govern everything:

• 1 project = 1 agent computer. Every project provisions its own Rebyte VM via POST /v1/agent-computers {name}. The VM is named, persistent, and lives until the user deletes the project.
• 1 "Adit" = 1 task. Every prompt the user submits creates one Rebyte task on that VM. Independent. No batching. No follow-up chains.
• The VM's filesystem is the project's state. The directory /code inside the VM is where all the project's files live. Adits has no separate file storage — no S3 bucket, no document store. The VM is the storage.

To get those files into the browser, we added a small Go binary called adits-file-server that runs inside every project's VM, bound to :8080, serving /code as static HTTP. Every Adits project gets a per-project URL of the form https://8080-<sandboxId>.<env>.rebyte.app — that's what the browser uses for iframe page rendering, image previews, file downloads. The file server also splices a bridge <script> into every HTML response so each rendered page can talk back to the host via postMessage.

Two patterns of the Rebyte API turned out to be load-bearing:

Sandboxes are Lambdas

Rebyte VMs auto-pause when idle and auto-resume on first request. The whole architecture treats them like Lambdas — we never pre-warm. No keepalive loop, no /ensure-sandbox round-trip before rendering, no separate "wake the VM" step in the UI. The iframe URL is safe to embed before any task runs; the very first request hits the sandbox gateway, which auto-resumes the VM transparently. The Adits server never has to babysit the VM lifecycle.

Webhooks instead of polling

Tasks run asynchronously on the VM — the agent might take 5 seconds or 5 minutes. Rather than poll, Adits registers a per-user webhook the first time a user signs in. Rebyte POSTs JSON to our endpoint every time the agent emits a frame (a chunk of streamed output) or hits a terminal state (succeeded / failed / cancelled). The Adits server forwards those events into Postgres + Redis pub/sub, and the browser receives them via a single SSE per active prompt.

That single-SSE-per-prompt model is what lets the chat panel update incrementally — every line the agent prints, every status change — without the client having to know which VM is running it or whether the VM is awake.

Local mode collapses everything

The same surface exists in self-host mode (ADITS_BACKEND=local), but every Rebyte primitive collapses to a local equivalent. The FileStore becomes mkdir ~/.adits/projects/<id>. The FileServer becomes a child Go binary on the Node server. The TaskRunner becomes a spawned local CLI. Same surface, no infrastructure. That's the whole point — hosted is a deployment choice, not a fork.

Try it

Hosted: adits.ai, currently in public beta.

Self-host: github.com/ReByteAI/adits — clone, install, run.

If you have a coding CLI already logged in on your machine, you can run Adits in self-host mode in under two minutes. If you'd rather not install anything, the hosted version at adits.ai is the same product.

We're keeping the surface boring and the agent slot wide open. If that resonates, give it a try. If it doesn't, the source is there — fork it and build the version you actually want.