Run roj standalone in a Worker, on @cloudflare/computer

[matej21]

Runs the roj agent runtime standalone inside a Cloudflare Worker — a Durable Object with a @cloudflare/computer workspace as its filesystem — and measures where it stops.

Two new packages, plus the SDK changes needed to make a host without a process table a first-class citizen. Nothing published; computer-worker is a private harness.

Verdict: it fits

	roj uses	limit
script size	1.57 MB gzip	10 MB (3 MB free)
startup CPU	~103 ms	400 ms
per turn	~10 ms CPU, 2 subrequests, 9 events	30 s / 1000
live sessions per DO	448 with no degradation	—
parallel agents	20 for the cost of 1.46×	20 children per parent

Turn cost does not grow with session age (+0.03 ms/turn over 60 turns) or with tool-result size. Subrequests bind ~5× before CPU — an await-until-idle request tops out near 500 turns.

Startup CPU inverts what the byte counts suggest: @cloudflare/computer is 5.9 MB and costs ~23 ms, the SDK is 1.1 MB and costs ~55 ms. Startup is paid for module-scope work — zod schema construction — not code size.

What's here

packages/computer-platform — a roj Platform over a computer Workspace: filesystem, execFile routed to the workspace shell, a git client, a SQLite event store over ctx.storage, and a Durable Object alarm scheduler.

packages/computer-worker — the harness. /run, /bench, /shell, /git, and /limits/<name> for seven probes, each on its own DO so one that OOMs cannot poison the next.

SDK changes: a runtime plugin profile (isolate drops services, resources, uploads), an optional git capability on Platform, a required scheduler capability, BaseEventStore exported for out-of-tree stores, and a Workers WebSocket platform in @roj-ai/transport over DO hibernation sockets.

The scheduler port

The agent loop re-entered through a bare setTimeout. In a DO that runs, but it cannot pay for itself: the actor's CPU budget is refilled by topUpActor(), which runs only when an event is delivered (io-context.c++:271). A timer callback never tops up, and an interval silently stops rescheduling once the budget is spent (io-context.c++:793). A DO alarm is a delivered event.

So Platform gains scheduler: wake(key, delayMs) / cancel(key). A wake carries no closure — the isolate that armed it may be gone when it comes due — so the key is the whole routing table and dispatch is a pure function of the key plus a session loadable from its event log.

Measured, with a negative control: a request sends a message, throws the booted SDK away, and returns at 3 events. 22 more land across three alarms and the session settles 1068 ms later. With the wakes cancelled, the same run stays at 3 events, zero alarms, never settling.

Bun is unchanged — createBunPlatform takes a timer-backed implementation, which is what the SDK did all along.

Letting the DO sleep

In workerd every armed actor timer registers a wait-until task that drain() waits on (io-context.c++:828), and a repeating timer arms a fresh one each tick. One live session's git-status poll was therefore enough to keep a DO permanently awake.

Who can write a workspace is a host question, so the host decides. Where the scheduler is a LiveScheduler the poll runs unchanged — that host has writers roj never sees, a user's editor or a dev server. Where it is not, every byte arrives through a tool call or a request, so the plugin arms nothing and a new git-status.refresh method answers a client's pull. Additive to the RPC contract; no existing shape moved.

/limits/idle shows roj arming no timer at all across settle, eviction, resume and pull. The control is what makes it evidence: the same census against a LiveScheduler session catches the 2 s interval immediately, with a stack trace.

Three defects the probes turned up

• SessionManager.shutdown() never ran onSessionClose, so no plugin released anything — a timer and a memory leak per session ever loaded. One test asserted this as intended behaviour, using shutdown() to stand in for a crash.
• Every logger dropped an error's cause, so EventAppendError reported no reason at all.
• SessionFileStore.read collapsed every failure into File not found.

Worth knowing before this is relied on

• An oversized event hangs the agent. Past the 2.2 MB SQLite value ceiling the log stops at tool_started with no terminal event; the agent never goes idle and replay carries a tool_use with no tool_result. Stock config never gets there — read_file's guard fires 25× earlier and fails cleanly — but raising maxTokens walks into it.
• A DO degrades by lifetime, not load. Closed sessions leave workspace directories and event rows behind; createSession goes from ~15 ms to ~110 ms after a few thousand. A multi-session DO needs a reaper.
• A burst of writes starves every timer in the isolate. Both the event store and the workspace filesystem go through synchronous sql.exec, so 400 ms of appends delivered one timer tick, 422 ms late.

Deliberately not done

spawn stays ENOSYS, so services cannot run in an isolate; under per-agent-type routing such an agent goes to E2B instead. The debounceCallback poll stays on a raw timer — its guards are in-memory cancellation state a resumed wake cannot reconstruct. roj-platform integration is not started.

Only a deploy can settle

Real inference CPU (no API key here, so the provider is mocked); which budget timer-driven work is charged to in production (the OSS enforcer is a no-op, the real one is closed-source); the 128 MB isolate ceiling (locally only V8's ~1.41 GB is reachable, and it aborts the whole workerd process); and hibernation itself — wrangler dev never evicts a DO, so this shows the precondition, not the behaviour.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JrTY8BadgtRHgo8DNEP7fR

[matej21]

Two more, both taking the "use SQLite natively where possible" route.

A revision gate on git-status (330fb365). dofs keeps a counter row in vfs_meta that every mutation bumps before it lands, so a single primary-key lookup answers whether the previous snapshot still stands. A gated pull costs ~0.07 ms against ~9 ms ungated — ~130x — and that is the whole RPC pull, not just the read.

Not MAX(vfs_nodes.rev), which was the obvious choice and is wrong: a delete removes the node row and lowers that maximum instead of raising it, so the gate would have missed deletions silently.

FsRevision is its own optional port. A host without it returns undefined, which callers read as "recompute" — the same path as a host that cannot tell — so Bun keeps polling exactly as it did.

A session reaper (c9c20275), as a host call rather than an onSessionClose hook: close() and shutdown() run the same hooks, so a hook that deleted data would wipe every loaded session when the isolate merely goes away, and reopen() would become a lie. Files are reclaimable by default, the event log is not — it is the only record a session existed.

Workspace files go through the filesystem adapter rather than raw SQL. vfs_blobs is content-addressed with no refcount, so two files with identical bytes share a blob; deleting nodes by hand would either leak every blob or corrupt unrelated files sharing the hash.

The open question about createSession degradation is settled, by ruling out both candidate answers separately. Growth across one arm, 400 sessions each, measured in a single run:

arm	scheduler	live sessions	debris	growth
hold	timer	grows	grows	5.81x
hold-do	alarm	grows	grows	0.98x
off	timer	1	grows	1.33x
off-do	alarm	1	grows	1.05x
all	—	reaping on	—	0.95x

Neither live count nor debris is the cause. Both earlier probes were seeing git-status's polling branch, whose per-session work grows with the accumulated filesystem — they just each saw one face of it. This DO already avoids it; the reaper's case here is storage, and on a Bun host it is the latency fix too.

One upstream gap worth recording: this counter is already public through provider.watch(), but only wrapped in a 100 ms setInterval — precisely the armed timer an evictable host must not hold. The pull form (revision(), changesSince(rev, { path })) is what is missing, and coalesceChanges already implements the second one internally.

[matej21]

Four more, continuing the "use SQLite natively where possible" route.

Both file-shaped logs are now rows on a host that has a table. Measured on the same wrangler process, toggling only the capability:

	filesystem calls per turn	writes	bytes
session log, before → after	32 → 7	24 → 1	4 453 → 76
LLM call log, before → after	20 → 7	9 → 1	110 950 → 76

The remaining write is note.md — what the agent actually produced. ~44 ms → ~1.4 ms and ~7.9 ms → ~0.8 ms of CPU per turn respectively.

The LLM log's columns are split rather than one entry blob, because completeCall is a read-modify-write: a single blob would have kept it and merely moved it off the VFS. With the outcome in its own columns, completing a call is a keyed UPDATE of a few hundred bytes — 0.065 ms against 0.93 ms for the whole-file rewrite. Ordering is call_id DESC: UUIDv7 is time-ordered and fixed-width, so lexicographic is chronological, and unlike a timestamp it is total.

Both are reclaimed on the reaper's files branch, so events: false still frees them.

listSessions() scaled with events rather than sessions — it read every row of the log, and c5149b71 had just put it on /status. A recursive term now seeks from one distinct id to the next down the existing (session_id, seq) primary key, so no index is added and the append path pays nothing: 755 ms → 4.1 ms at 3.3 M events on the same on-disk database. The union with the metadata table stays — a session can have events and no metadata, because doAppendBatch inserts synchronously and then awaits the metadata write, so only the second can fail alone.

The file logger could write its lines out of order. writeLine started an append per line and awaited none, with nothing serialising them; it had always done this, and only became visible once a second sink wrote the same entries to rows. Worse on the DO than it sounds: the computer adapter emulates appendFile as an lstat followed by a write at the observed size, so two interleaving would have overwritten one another, not merely reordered. Lines now queue per path. Flake rate under load 5/20 → 0/20.

Two corrections to this PR's own README. The cascade probe built its own SessionManager without withOwnScheduler(), so it rode the DO's alarm scheduler while alarm() dispatched elsewhere — it had been timing out at 30 s, and the numbers it documents could not be reproduced. Repaired and re-measured:

• Survived exactly: the chain breaks at 10 485 760 B, maxReadSize to the byte, and truncation pins the event at ~85 KB for any file size.
• Moved: with truncation off the break is 2 132 961 B, and the persist link binds twice — the result is written as tool_completed and again inside the following inference_started — so there is a band where the result is on record and the turn still hangs.
• Wrong as written: "roj's own guard fires 25× earlier and fails cleanly" named one guard for two. The 25× margin is maxTokens truncation; the clean failure is maxReadSize, which sits 4.8× above the store's ceiling and never protects it. Stock config is safe because of truncation alone.

1174 tests pass.