Four agent lanes, one 4,096-token model and a disk that ran out twice

Anupam asked for one night of work on the foundations of a private trading research app: its on-device language model sessions, its tools, its websockets and its strings. This is my report on what I did, what reached the main branch, and what went wrong.

What I read first

Two agents read in parallel before anyone wrote code. One read Apple's documentation and WWDC sessions; the other audited the app. The findings that shaped the night:

• Apple's on-device model holds 4,096 tokens per session, and everything counts: instructions, tool definitions, tool output, schemas, the question and the answer (managing the context window).
• iOS 27 renames the overflow error to LanguageModelError.contextSizeExceeded and adds LanguageModelSession.DynamicProfile, ToolCallingMode and an Evaluations framework.
• Permissive guardrails relax only String output; @Generable output behaves like the default (docs).
• Apple now recommends the Network framework for new WebSocket code (TN3151).

The audit found the app estimating tokens as characters divided by three, telling the user to start a new chat when the window filled, rebuilding the session and every tool on each role change, three hand-copied websocket reconnect loops (one provider had none), and about 700 interface strings in a Swift package that looked them up in the wrong bundle, so they could never be translated.

How the work was split

I ran four Claude Code sessions in separate terminal panes, each in its own git worktree with its own goal and a written file-ownership list so they would not edit the same files: session runtime, typed tools, websockets, and string catalogs. A fifth agent first repaired the test baseline, because two test files on the main branch called code that had never been written, so no change could be verified. I reviewed each lane's diff and merged it myself; no lane merged its own work.

What reached main

• The baseline. The missing code was written rather than the tests deleted. The model-test timeouts reported in an old bug did not reproduce: 526 tests passed on an iOS 27.2 simulator under heavy load.
• Websockets. One reconnect policy (a backoff schedule, a failure budget and a stall watchdog) now serves all three market streams, and the one with no reconnect gained it. We kept URLSessionWebSocketTask despite TN3151, for three written reasons: the server shares the code and builds on Linux, authentication rides on the HTTP upgrade, and refusals arrive as upgrade status codes.
• A missing server route that a client test had expected for days, and a test that only failed when run after another suite. The fix was a task-local override for two shared singletons, not a weaker test.

What did not reach main yet

The session runtime is reviewed but not merged. It counts tokens with the model's own tokenizer, condenses the chat and retries once on overflow, keeps one session across roles and prewarms the role the draft is heading to. It waits on one quiet-machine test run. The typed-tools and string-catalog lanes are pushed but never got a clean final build.

What went wrong

The disk. Each worktree builds its own Xcode cache of five to seven gigabytes, and lanes that also ran swift test added a second cache of about two. With four lanes plus other projects building, free space fell from 29 GB to 4 GB twice. I paused every lane, deleted only caches, and moved lanes to xcodebuild alone. The second time Anupam cleared every build cache on the machine. The lesson I saved for next time: budget about seven gigabytes per lane, run at most two, and delete a lane's cache the moment it merges.

Load was the other cost. Some nights the machine ran nine heavy builds at once from different sessions, and timing tests failed for reasons that had nothing to do with the code under test. A test that fails only under load is still evidence, but it has to be re-run on a quiet machine before it can block a merge.