useAgent: An Open-Source AI Coworker That Gives Each Thread Its Own Cloud Computer
The open-source AI coworker for your team: agents with their own cloud computer, your tools and context, handing back finished work websites, decks, spreadsheets, reports, PRs. Runs Claude Code, Codex, OpenCode on your subscription.
At a glance
- What is it?
- useAgent is an AGPL-3.0 TypeScript project that runs Claude Code, Codex, OpenCode or Pi against a shared workspace with a sandbox, Postgres-backed event timeline and Slack delivery. It is alpha software, self-hosted, and aimed at teams rather than individuals.
- Who is it for?
- Adopt useAgent if your team already pays for Claude Code, Codex or OpenCode and wants those engines to work inside a shared, self-hosted workspace with a Postgres timeline and Slack delivery. Do not adopt it if you need a stable API surface, because the README states that schemas may change between releases and the project is alpha.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap useAgent fills: agents that hand back files, not transcripts
Most coding agents stop at a diff. useAgent's premise is that the unit of delivery should be a finished artifact: a website, a deck, a spreadsheet, a report, or a pull request. The README frames the product as "The open-source AI coworker for your team," and the feature list backs that framing with revisioned edits and native exports for supported workpieces, plus a Slack channel where artifacts arrive in the thread.
The target user is a team, not a solo developer. Every channel (web app, Slack, REST API, schedules) enters through what the README calls "the same run door," and the workspace carries shared knowledge, team memory, skills and playbooks. That is a different shape from a CLI wrapper around one model. It assumes several people will inspect the same run, correct recalled facts, and reuse the procedures that worked. If you are one person running an agent locally, most of this machinery is overhead you will not exercise.
How useAgent works: one event contract, four engines, isolated workstations
The architecture visible in the repository splits into a frontend, a backend, a gateway, and a set of packages. The typecheck script in package.json enumerates them: packages/sandbox-contract, packages/sandbox-daytona, packages/sandbox-cube, packages/sandbox-box, packages/artifact-workspace, packages/artifact-formats, packages/agent-harness, packages/agent-client, packages/conformance, and packages/cli. That layout tells you the design intent: the sandbox providers sit behind a contract package, and the engines sit behind a harness and client pair with a conformance suite to keep them honest.
The README describes the runtime behaviour in one line: "One session UI and event contract across engines." Claude Code, Codex, OpenCode and Pi are adapters, and the README is explicit that "available models, login methods, and tools depend on the adapter and your self-hosted configuration." So the cross-engine promise is about the session and event layer, not about feature parity between engines.
Sandboxing is delegated. Daytona and CubeSandbox "provide isolated Linux workstations with screen recording," which is what makes browser research and terminal work observable from the thread. Durable sessions lean on Postgres: "Postgres stores the event timeline; recovery re-probes live sessions after a restart." Approval controls are argument-bound: gated tools "pause for a decision and resume with a one-shot, argument-bound capability." That is a tighter grant than a blanket allow-list, and it is the kind of detail worth reading the docs for before you wire it into anything with write access.
Installing useAgent and running a first session
The README's Quick Start begins by cloning the public repository, which is the only install path it documents.
git clone https://github.com/useagenthq/useagent.git
cd useagentThe stated requirements are bun and Postgres 16 or later with the pgvector extension. The README warns that stock Postgres images do not include pgvector, and offers a single container for people without a database handy.
docker run -d --name useagent-pg -p 127.0.0.1:5432:5432 \
-e POSTGRES_HOST_AUTH_METHOD=trust pgvector/pgvector:pg16
export DATABASE_URL=postgres://postgres@lThe README excerpt cuts off mid-connection-string, so the exact DATABASE_URL value is not fully visible here; check the repository's Quick Start for the complete string before running it. Note also that POSTGRES_HOST_AUTH_METHOD=trust disables password authentication, which is acceptable for a container bound to 127.0.0.1 and not for anything reachable from a network.
The repository ships compose.local.yaml and compose.prod.yaml alongside Dockerfile.backend, Dockerfile.frontend and Dockerfile.gateway, so container-based startup is the documented route for a full deployment. For local development, package.json exposes separate dev scripts:
bun run dev:frontend
bun run dev:backendOnce the stack is up, connect a supported provider account or API key. The README does not document which models each adapter exposes, so treat that as the first thing to confirm in your own deployment.
Where useAgent is the wrong tool
The README labels the project alpha and states plainly that "APIs/schemas may change between releases," with the advice to pin a tag if you need stability. That single sentence rules out a class of adopters: anyone building an integration against useAgent's REST API and expecting it to survive an upgrade. Pin a tag or accept rework.
The dependency surface is also heavier than it first appears. You need Bun, Postgres 16 with pgvector, and a sandbox provider. If your environment is a managed Postgres without extension support, the README's own workaround (a pgvector container) means running a second database just for this. If you cannot reach Daytona or CubeSandbox from your network, the computer-use half of the product is unavailable, though the repository also lists packages/sandbox-box, whose role the README does not describe.
The team framing cuts both ways. A single developer who wants an agent to edit a local repository will find the knowledge base, memory hub, approval gateway and Postgres event timeline to be more moving parts than the task requires. And because the engines are adapters, switching from Claude Code to Codex does not guarantee the same tools are available; the README says as much.
useAgent compared with running Claude Code or Codex directly
The honest alternative is not another product. It is the engine on its own. Claude Code, Codex and OpenCode each run in a terminal on your machine, and if that is all you need, useAgent adds a Postgres instance, a sandbox provider, a gateway, and three Dockerfiles to the picture.
The difference in approach is where execution happens and who can see it. Running an engine directly means the agent works on your machine, under your user account, with whatever access your shell has. useAgent moves execution into an isolated Linux workstation and routes tool calls through a gateway where gated tools pause for an argument-bound approval. The event timeline lives in Postgres rather than in a terminal scrollback, which is what makes the Slack delivery and the shared thread possible.
That trade is worth naming precisely. You give up the simplicity of a single process and gain an audit trail, a shared workspace, and a boundary between the agent and your credentials. Teams that need the second set should look here. Individuals who want the first should not.
Licence, upgrade cost and what alpha means in practice
The repository's package.json declares "license": "AGPL-3.0-only", matching the AGPL-3.0 badge in the README. The presence of CLA.md and COMMERCIAL-LICENSE.md at the repository root indicates a contributor licence agreement and a separate commercial track, which is a common arrangement for projects that want to offer non-AGPL terms to some users. Whether that matters to you depends on how you deploy and modify the code; this is a question for your own counsel, not something the README resolves.
Upgrade cost is the more immediate concern. The README's alpha notice, the two releases listed (v0.0.3 on 2026-08-31 and a native runtime build on 2026-09-12), and the instruction to pin a tag together describe a project where the schema is still moving. The last push to the repository was on 2026-09-12. Budget for reading release notes before each upgrade and for testing your deployment against compose.prod.yaml rather than assuming a drop-in replacement.
The mitigation is straightforward and comes from the project's own advice: pin a tag, and run your own instance against a staging database before moving production.
Editorial conclusion
Adopt useAgent if your team already pays for Claude Code, Codex or OpenCode and wants those engines to work inside a shared, self-hosted workspace with a Postgres timeline and Slack delivery. Do not adopt it if you need a stable API surface, because the README states that schemas may change between releases and the project is alpha. Before committing, verify three things: that your Postgres 16 instance has pgvector installed, that a sandbox provider (Daytona or CubeSandbox) is reachable from your deployment, and which engine adapter exposes the models and login method you actually use.
Frequently asked questions
Which coding agents does useAgent support?
The README lists Claude Code, Codex, OpenCode and Pi, presented as one session UI and event contract across engines. It also notes that available models, login methods and tools depend on the adapter and your self-hosted configuration.
Does useAgent need Postgres, and which version?
Yes. The Quick Start requires Postgres 16 or later with the pgvector extension, and warns that stock Postgres images do not include pgvector. The README offers a pgvector/pgvector:pg16 container as a single-container option.
Is useAgent stable enough for production?
The README labels it alpha and states that APIs and schemas may change between releases, advising you to pin a tag if you need stability. It also says the project already runs real daily workloads.
Community notes