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. One example is 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.

Those invariants keep one controller and one canonical project store. Each attempt gets a disposable workspace and bounded process output. Provider-specific parsing remains separate, and no completed multi-model result exists until all required turns finish.

Failure remains evidence, not consensus

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

Failure evidence remains available while the surrounding task needs it. Once the durable outcome is recorded, completed project data is purged. A failed attempt never counts toward a completed review, and retained provider prose never becomes a permanent conversation archive.

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, and usage data remain out of the notes vault. Credentials and source packets stay out as well, 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, and adapters. Recovery gates, CLI behavior, event handling, and chat qualification are tested in the same suite. 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