Share the client contract
The engines use the same stream format so clients can present text, tool activity and completion consistently. Runtime-specific session handling stays in the engine.
Selected work
Case study 02 / Connected agents
Agent work outlasts a browser tab.
Three agent engines and Apple clients, with a common way to show the work. The system accounts for long turns, interruptions and disconnected screens.
One recorded run23characters received2,632characters recoveredReplay the disconnect Controlled Claude Engine run · the same process kept working.PythonTypeScriptJSON-RPCSSESwiftUI
Engines + Apple clientsA personal engineering project
01The starting point
A running task and its screen have different lifetimes.
An agent can spend a while reading files and using tools. During that time, a browser can disconnect and a person can move to another device. A partial transcript does not tell them whether the task is still running or has finished.
I built engine services around Claude, Codex and OpenCode, with a common stream for the web and Apple clients to read. Each engine handles its own upstream runtime and session behaviour.
A question can leave the terminal
The answer comes back.
The work moves on.
Codex needs a layout choice. Attention brings the question into the Mac app, returns the selected answer to the waiting terminal, and the same task builds the page.
The recorded choiceSession cardsWatch the terminal-to-Mac round tripThe result is a responsive workshop page with three session cards.
Actual shared Attention MCP and released Mac app. Automated native choice; fictional workshop. The resulting file is available to download.
02What the workflow looks like
A useful path through the product.
- 01
Choose the runtime for the conversation
Claude, Codex and OpenCode connect through a common client stream format. Engine adapters handle the different upstream protocols; the shared interface does not merge the models’ conversation state.
- 02
Show the work as it happens
Text and tool activity arrive as stream events. Queue and injection paths let a follow-up enter a running turn deliberately.
- 03
Collect the answer after a disconnect
A stored-result path lets the client retrieve a completed turn and reconcile its partial transcript after a browser or proxy connection breaks. An engine restart has separate recovery rules.
- 04
Let a question wait for its answer
The Apple client holds durable question cards from agents. An answer or decline returns to the waiting session through the attention and relay services.
Another look at the native client
Another screen for the same work
A native client on the device at hand.
The Apple app gives conversations their own interface on iPhone and iPad. This separate capture opens a saved conversation and its provider and model menus in the native app on an iPhone Simulator.
Recorded in the product
Open the work on iPhone
What happens in this recording
Native iPhone app · iPhone Simulator · saved conversation · edited recording
A saved showcase conversation opens in the native client. Chat options reveal the provider and model controls; the menus open, then the recording returns to the chat without changing the selection. The local workspace path is hidden. Cuts remove waiting time.
03Design + engineering
The decisions underneath.
Use the protocol the task needs
Claude uses its agent SDK; Codex uses the bidirectional app-server protocol for streaming, steering and forks; OpenCode uses its typed client. A shared interface still needs three distinct integrations.
Check silence before interrupting
A pause can mean a tool is starting or a result is taking time. The Codex watchdog now checks upstream liveness before deciding that a quiet turn has failed.
Explore the individual features
The smaller pieces of this story.
Recover the answer after a disconnectClose the window. Keep the result.Redirect a turn without throwing it awayChange the instruction. Keep the work.See what the agent is doingRead the work around the answer.Three engines, one chat contractChange the runtime. Keep a readable chat.A voice conversation with visible stateMake a spoken conversation visible.
A schedule across two processes
The process stops.
The schedule returns.
Claude Code supplies the native schedule. I built the engine-side checks and session bookkeeping around it. This recorded run resumes the same session in a new CLI process and receives the scheduled response without another prompt.
Recorded CLI test15 October 2026One non-recurring session cron
- 01
Process A
One schedule armed
The original CLI created one non-recurring session cron.
- 02
Process A exited
Original CLI closed
Its process was gone before the session resumed.
- 03
Process B
Same session resumed
A different CLI resumed it without another query.
- 04
Autonomous response
Answer arrived
The scheduled response matched the fixed text requested.
0explicit queries
after resume
after resume
Fixed response matched
The saved result records the match. Prompt and response text are omitted.One observed answer arrived +2.40 seconds from the engine mirror’s predicted fire time. This is one recorded check, not a benchmark or timing guarantee.
This check covers CLI session restoration and one scheduled answer. Engine restart, delivery callbacks and production health were outside the test.
What comes back? Three saved classifier cases
These are fixed synthetic transcripts processed by the unchanged engine classifier. They are separate from the real CLI test above.
| Saved situation | Classifier result |
|---|---|
| Future one-shot | Eligible to restore |
| One-shot whose fire time passed | Dropped |
| Recurring job at seven days old | Expired |
A missed one-shot is dropped; this mirror does not promise catch-up. The seven-day recurring limit is its default. These examples do not establish every scheduling boundary in the native CLI.
What was recorded and checked
The actual SDK and CLI ran in an isolated test. One explicit arming query created one non-durable, non-recurring cron. After that CLI closed, a different CLI resumed the same session with no query and no available tools. “Process A” and “Process B” distinguish those recorded processes; actual identifiers are omitted.
The timeline is a projection of recorded events, not a chat recreation or a live scheduler. The fixed-response match is a comparison of the actual saved result; its raw text is omitted.
2 SDK product interactionsInitial arming and autonomous answer. SDK-reported num_turns was 2 and 1; these are not provider inference or billing counts.
49 unique original tests passed25 classifier tests and 24 mocked component tests. Separate from the 16 synthetic cases and this live CLI proof.
My engine mirrors schedule eligibility from transcripts, restores the pinned session state and coordinates warming the session without a new prompt. The component tests isolate those responsibilities with mocked SDK, Redis and HTTP services.
No real Claude Engine restart, armed-session record, Redis outbox, PanelForge callback or HTTP warm route was exercised. The current CLI’s full expression, timezone and expiry behavior was not verified by this one-shot run.
Engine source v6.17.0 · SDK 0.2.164 · CLI 2.1.292. The mirror’s source comment references CLI 2.1.287; this recorded one-shot used 2.1.292.
04Selected release history
It got here one decision at a time.
These are historical changes recorded in repository tags. The capture and current-state notes below describe what is being shown here.
A stable engine boundary
Claude Engine reached its stable release, followed by a protocol and package refactor in v2.0.0.
Claude Enginev1.0.0A third runtime in the same interface
OpenCode joined Claude and Codex through the common streaming path.
PanelForgeweb-v7.91.0Handle an interrupted voice turn
The iOS client added voice interruption recovery, standby and spoken questions after its first TestFlight release.
Apple clientios-v1.4.0Recover the completed answer
Claude Engine gained a disconnected-result outbox and an ordered recovery timeline for interrupted client streams.
Claude Enginev6.13.0Rebuild the schedule’s session state
Claude Engine reconstructed eligible session crons from transcripts and restored their residency bookkeeping, so a resumed CLI could remain available for its scheduled work.
Claude Enginev6.14.5Read the schedule in the CLI’s time zone
Restoration used the CLI’s configured time zone when predicting cron times, keeping engine bookkeeping aligned with the scheduler.
Claude Enginev6.14.6A pause is reason to check
Codex Engine added bounded liveness probing so silence alone would not interrupt a legitimate turn.
Codex Enginev0.6.23Steer a turn already in progress
Queue and injection steering gave follow-ups an explicit route into ongoing work.
Claude Enginev6.15.0
About the material shown here
Product views.
Release notes.
Selected screenshots and edited recordings accompany changes checked against repository history through October 2026.
Current product and capture
The engines connect the web and Apple clients to three different agent runtimes. The shared interface gives each conversation the same place for text and tool activity. The Recovery Lab also documents a controlled run of the actual Claude Engine: after a browser disconnect, the same engine process completed the turn and its original result endpoint returned the stored answer twice. The run used a fictional text-only task and did not test process restarts, tool approvals or production client reconciliation. A separate SDK/CLI test stopped the original process, resumed the same session in a new process without another query, and received its scheduled response. The engine’s mirror agreed with that one firing time; the live run did not exercise engine startup or delivery callbacks.
Source and historical evidence
Claude Engine’s first tag dates to February 2026. Codex and OpenCode followed in May; the iOS client reached TestFlight in July. October patches v6.14.5 and v6.14.6 record session-cron bookkeeping and its time-zone correction; v6.16.1 aligned the verification script with the engine’s configured CLI. The 15 October source proof keeps offline classification, mocked components and the real CLI run separate.
About the demonstrations
Product imagery uses selected material prepared for this portfolio. Recordings show the interface in use. Architecture graphics describe system relationships and do not show live service availability.