Relay Multi-Model Review Runtime

Relay is a personal local developer tool that runs bounded review exchanges between Claude and Codex. I use it when a decision benefits from independent challenge—for example, having both systems audit a frozen portfolio source packet and converge on the changes that materially affect a recruiter’s judgment.

The controller decides what each peer can see, invokes one provider at a time, validates terminal output, and stores the evidence needed to distinguish a complete exchange from persuasive but partial prose.

A bounded operating flow

A real run begins with an exact command and explicit approval for paid provider calls. Relay freezes the allowed source packet into a temporary workspace, sends the first result to the second peer for challenge, and continues only after each provider returns parseable, non-empty terminal output. It never grants live-project access by default or silently decides to spend, retry, or resume.

That makes the core invariants visible: one controller, one canonical project store, one disposable workspace per attempt, bounded process output, provider-specific parsing, and no completed multi-model result until all required turns finish.

Failure remains evidence, not consensus

Authentication errors, process failures, parser errors, timeouts, stream-limit violations, and empty responses stop the affected turn. Relay preserves the reason and bounded output, but a later retry or resume requires another human decision.

This portfolio review exercised that boundary directly. An initial source packet failed the temporary-root policy before either provider ran; Relay recorded zero turns and stopped. A corrected, separately approved invocation then completed four alternating Claude and Codex turns. The failed attempt remains traceable without being counted as part of the completed review.

Runtime state has explicit owners

The engine and tests live in a code checkout. Canonical conversations, runs, and event ledgers live in a private store with restrictive permissions. Each attempt receives a separate temporary workspace containing only its frozen inputs and bounded runtime material.

Obsidian receives only a compact activity projection. Prompts, provider prose, raw errors, usage data, credentials, and source packets remain out of the notes vault, preventing a convenient status surface from becoming a second transcript database.

Verification without accidental provider use

A usage-free regression suite covers storage invariants, process control, sandbox policy, adapters, recovery gates, CLI behavior, event handling, and chat qualification. Provider readiness is checked separately and cannot be inferred from mocked success. This keeps code verification, authentication readiness, and completed paid exchanges as distinct claims.

Current limitations

Relay runs only on my home server and depends on locally installed, authenticated provider clients on that host. Other machines attach to its persistent terminal session rather than running separate copies. It is not a hosted collaboration product and does not provide autonomous scheduling, automatic retries, broad agent tool access, or a generalized marketplace. Those limits keep authority and failure behavior understandable, but they also make Relay an operating tool rather than a turnkey service.

What this demonstrates

• Local orchestration of heterogeneous provider clients through a durable conversation and run model
• Fail-closed sequencing that keeps partial provider work from being labeled as consensus
• Explicit paid-call authority, bounded execution, per-attempt isolation, and evidence-preserving recovery
• Provider-specific parsing and usage-free regression testing with honest production qualification