camelAI: a Cloudflare Workers coding agent that writes JavaScript instead of bash

What camelAI solves, and who it is actually for

A chat thread that forgets the workspace is the usual failure of hosted coding assistants. camelAI's answer is to make the thread itself a durable object: each chat thread runs its own coding agent in a Cloudflare Durable Object, and project files persist alongside it. That is the problem statement the README gives, and it is a different problem from autocomplete. The target reader is a team that wants a web application where an agent can read project files, call connected services, run a build, and publish the result, without anyone provisioning a VM per session. The README lists the surrounding platform as persistent chat threads and project files, workspace-aware tools, integrations for APIs, databases, email, Slack and Discord, isolated builds, notebook analysis, SQL execution, previews and production publishing through Workers for Platforms, plus organization, auth, billing and admin controls. That is a product surface, not a library. If you only want a terminal assistant that edits files in your checkout, the platform's own shape works against you: state lives in Durable Object SQLite and R2, and the execution model is JavaScript in isolates.

The agent loop lives in ChatThreadDO, not in a VM

The architecture diagram in the README is unusually explicit. React Router SSR and browser HTTP/SSE sit above a main Worker. Below it, ChatThreadDO owns the agent loop and persistent chat state. From there the tree splits three ways: Code Mode, a dynamic Worker or V8 isolate where the agent's JavaScript tools and data connections run; WorkspaceFilesystemDO, which holds project files with small files in Durable Object SQLite and larger files in R2, plus artifacts history; and short-lived Cloudflare sandbox containers for builds, notebook analysis and SQL. Publishing is a fourth path: `deploy_project` takes project files into a build sandbox, then to Workers for Platforms, and a Dispatcher Worker routes requests to the live application.

The design decision worth pausing on is the tool interface. The README states the agent "writes JavaScript instead of bash" and that Code Mode runs that JavaScript in fresh V8 isolates with explicit platform and connection methods. Credentials remain outside the execution sandbox. That is a real security boundary and it is also a constraint: an agent that needs a shell utility has to reach it through a declared method, not by piping. The README is direct that the agent is camelAI's own harness, built from pi's lower-level agent loop and state-management libraries, and "is not Claude Code or Codex." Anthropic, OpenAI, OpenRouter, Bedrock and custom endpoints supply the model, not the harness. Anyone evaluating this should treat the harness as the thing under review, because swapping the model will not change how tools are dispatched.

Installing camelAI locally and running a first thread

The README lists three prerequisites: Node.js 22 or newer, Bun, and a Cloudflare account with access to the development resources. Docker is required for sandbox-backed features and agent evals, which means builds and notebooks will not work without it. Clone, install with a frozen lockfile, and copy the example secrets file:

git clone https://github.com/qaml-ai/camelAI.git
cd camelAI
bun install --frozen-lockfile
cp .dev.vars.example .dev.vars

The README then says to replace the placeholder signing and encryption secrets in `.dev.vars`. For hosted model access you also add a development Cloudflare AI Gateway token, or you can configure Anthropic, OpenAI, OpenRouter, Bedrock or a custom provider from the organization settings after the app starts. Do that before starting, or the agent has no model behind it.

Start with local authentication:

bun run dev:local-auth

Open http://localhost:3001. The README notes this command is restricted to the Vite development server and seeds a `Local Dev` user, organization and workspace, so you land inside a working org without configuring OAuth. The port defaults to 3001 and changes with `VITE_DEV_PORT`. To exercise the normal OAuth flow instead, run `bun run dev`. Once inside, create a thread and give the agent a task that touches files; that is the first real use, because it exercises ChatThreadDO and WorkspaceFilesystemDO together. For self-hosting rather than local development, the README gives a Docker Compose target run as `bun run selfhost:init`, `bun run selfhost:doctor`, then `bun run selfhost:up`, with `SELF_HOSTING.md` as the deeper reference.

Where camelAI is the wrong tool

The self-hosted target is described as a single-machine Docker Compose setup for private networks and on-premises evaluation. That phrasing matters: it is a supported target, but the README frames it around private networks and evaluation, not around running a public multi-tenant service on your own hardware. If your requirement is a hardened, horizontally scaled deployment you operate yourself, the documentation does not promise that shape.

The second limit is the execution model. Because the agent writes JavaScript into fresh V8 isolates rather than running bash, work that depends on native tooling, system packages or long-running processes inside the same context as the agent does not fit. Linux is reserved for short-lived jobs: application builds, notebook analysis and database queries. Anything that assumes a persistent Linux session with an interactive shell is outside the design.

The third is operational surface. The repository ships multiple Wrangler configurations (`wrangler.jsonc`, `wrangler.prod.jsonc`, `wrangler.staging.jsonc`, `wrangler.test.jsonc`, plus per-developer dev files), several Compose variants for self-hosting, and separate Workers for the dispatcher, app usage guard, Bedrock provider and Discord bridge. Each is a moving part you inherit. The README also does not document rollback for published applications, and the app-usage-guard Worker is described only as "usage monitoring and reversible app quarantine," which tells you quarantine is reversible but says nothing about reverting a bad deploy.

How camelAI differs from a terminal coding agent

The closest comparison is a terminal agent such as Claude Code, and the difference is structural rather than cosmetic. A terminal agent runs on your machine, reads your checkout, and inherits your shell. camelAI runs the loop in a Durable Object on Cloudflare, stores files in `WorkspaceFilesystemDO` with SQLite for small files and R2 for large ones, and executes tools as JavaScript in V8 isolates with credentials held outside the sandbox. The README states plainly that the agent "is not Claude Code or Codex," even though both Anthropic and OpenAI models can drive it. So the model choice is orthogonal; the harness, the storage layer and the sandbox are the product.

A second comparison is to running the agent in a VM. A VM gives you a real Linux userland and a shell, at the cost of provisioning and lifecycle. camelAI trades that away deliberately: Linux appears only for short-lived builds, notebooks and SQL queries, and the persistent state is a Durable Object plus object storage. That trade buys cheap per-thread isolation and a publish path through Workers for Platforms. It costs you the ability to install a system package and expect the agent to use it in its main loop.

Maintenance, licence and upgrade cost

The repository is not archived and its last push was on 2026-09-15, two days before this writing, so the project is being worked on right now. Recent releases are tagged in a `selfhost-v0.1.x` series, with `selfhost-v0.1.18` on 2026-08-27 and `selfhost-v0.1.16` on 2026-08-19, which suggests the self-hosting path is the one receiving release tags. Note that the root `package.json` still carries the internal name `chiridion-app` at version `0.1.0` and is marked `private`, so the version you track for upgrades is the release tag, not the package version.

The licence is MIT, declared both in the repository and in `package.json`. That is permissive and places few obligations on how you redistribute or modify the code. It says nothing about the services the project depends on: Cloudflare Workers, Durable Objects, R2, Workers for Platforms and sandbox containers are billed and governed by Cloudflare's terms, and the model providers you configure have their own. The README does not discuss cost, quotas or data residency for those dependencies, so treat licence clarity as covering the source only.

Upgrade cost is dominated by migrations and configuration drift. The repository contains a `migrations/` directory and a `selfhost:d1:migrate` script, so self-hosted installs have a database migration step to run. There are also smoke scripts for artifacts, images and containers (`selfhost:artifacts:smoke`, `selfhost:images:smoke`, `selfhost:container:smoke`), which is a reasonable signal that upgrades are expected to be verified rather than assumed. The README does not describe a supported downgrade path.

Editorial conclusion

Adopt camelAI if your team already runs on Cloudflare and wants one persistent agent per chat thread with connected data and a publish path, and you can accept the Docker and model-provider prerequisites. Do not adopt it if you want a CLI on a laptop, if you cannot run Docker for builds and notebooks, or if you need documented rollback for published applications, because the README does not document one. Verify first that `bun run selfhost:doctor` passes on a clean machine and that your chosen model provider is reachable from the sandbox, since the agent harness is camelAI's own code and not a wrapper around Claude Code or Codex.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. qaml-ai/camelAI on GitHub
4. README
5. Releases