01 · THE GATE / identity
Know who is acting
Give each worker a distinct scoped identity. Record its model, harness version, host and role. Keep provider authentication in that worker; a RelayHall credential governs access to the hall.
Research dossier · Desktop, web & mobile
One hall.
Many harnesses.
The desktop, web and mobile agent landscape, mapped for a mixed workforce. Keep each model at its own bench. Share context, skills, tools and evidence through one coordination point.
Start with the model providers
Official native environments first: keep each provider at its own bench, then add independent tools for their specific strengths. This is a practical starting order, not a market-share or benchmark ranking.
The shortlist by job
Editorial recommendations for your intended fleet. These are use-case assessments, not measured market-share rankings.
A fast-moving market
Several familiar names have changed product, plan or access model. This report flags transitions, previews and archived tools. Prices are public USD list prices where verified; regional taxes, promotions and annual billing can change the checkout total.
Full harness index
Search all profiles, select tools for comparison, and open the detailed evidence.
Detailed profiles
Separate the company, harness, model entitlement and actual operating-system surface.
Capability & commercial matrix
Scan the symbols, then click any cell to expand its details and evidence. Feature pages adapt to your screen; exports include every column in the selected group.
✓ Supported / documented◐ Conditional / mixed? Unverified— Not offeredⓘ Descriptive detail
“Unverified” means the research did not establish the feature; it is not evidence of absence. Model-service rows inherit PC capabilities from their host harness.
Models, without a fabricated league table
Raw percentage results and descriptive averages for provider-owned models. Third-party-only harnesses do not get a made-up model score.
How to read a 0–100 score
A benchmark percentage is performance on that benchmark, not “percent as intelligent as the best model.” The available-metric mean below is an arithmetic average of the captured results, with equal weight. It is not comparable across different panels. Even matching benchmark names can differ in harness, effort, tool access and runtime budget. No independent, uniform current panel was verified for every leading model.
the hall · one coordination point, many independent benches
Let the harnesses keep their craft.
Give them a shared workplace.
Your idea is a fleet of specialists with one point of contact: each agent keeps its own model, native tools and execution loop, while the shared project context, skills, service registry and evidence travel through RelayHall.
Public beta · self-hosted · MIT
What RelayHall contributes
RelayHall describes itself as a coordination server for people and AI workers. Its REST and MCP interfaces expose a governed record of identities, tasks, skills and reports. Work executes in the agents’ own environments.
Its documented workflow compiles a credential-scoped brief from the project, charter, task, permitted skills and linked handovers. That lets a successor continue a task with its rationale and evidence.
Visit RelayHall ↗ Read the workflow ↗Conceptual integration map. It illustrates the proposed fleet; it is not a claim that every product in this report has a working RelayHall adapter.
Codex in CodexClaude in Claude CodeGemini in AntigravityMistral in VibeQwen in Qwen CodeGeneral agents at their own benches
Preserve the provider’s intended environment
Start with the provider-supported harness and model combination, including its native tool schema, context handling and permission flow. This preserves product-specific strengths that a generic wrapper may lose. “Trained in this exact harness” is not established for every model here; treat native-harness superiority as a hypothesis to test on your tasks, not a universal benchmark fact.
Six shared stations unlock the fleet
02 · THE BOARD / tasks
One outcome, explicit jobs
Translate your request into a project charter, dependent tasks and acceptance criteria. Workers claim eligible jobs and pull the compiled brief rather than reconstructing the whole project in every chat.
03 · THE CRIB / skills + services
Reuse what works
Maintain reviewed, versioned skill instructions and service descriptions. Adapters translate them into each harness’s own conventions; an MCP server or tool must still be configured and authorized on its worker.
04 · THE LOGBOOK / handover
Carry decisions forward
Publish findings, citations, artifacts, attempted fixes and open questions in task reports. Share the relevant evidence and reasoning summary, rather than requiring access to another model’s private internal state.
05 · INSPECTION / verification
Use independent judgment
Ask another authorized worker to verify code, sources or deliverables against the task rubric. Different models can expose different failure modes; agreement alone is not proof of correctness.
06 · THE WINDOW / observability
Make routing measurable
Have external adapters report lifecycle, task success, token/cost estimates and observed quota buckets. Route the next job using measured capability and available capacity, with unknown fields left explicit.
Common context is a governed brief, not one giant prompt.
Keep durable agreements and evidence shared; load only the context relevant to each role.
Available foundation
The public workflow describes compiled briefs and handover records. The homepage describes curated skills and services registries. These are the starting point for cooperation.
For knowledge retrieval today, connect your existing sources through their supported MCP/REST tools, subject to worker permissions. Store stable references and report provenance so another harness can retrieve the same evidence.
Knowledge federation · partly planned
Do not confuse the roadmap with deployment
RelayHall’s knowledge page marks configuration, outbound policy, signing and sealed handles as available for beta testing. Federated fan-out queries, coverage records, the hall-as-source feed and provenance wrapping remain planned.
A unified retrieval endpoint is a useful target architecture. Until those parts are available and tested, a shared external knowledge service plus source-specific connectors can fill the gap.
Check current knowledge-plane status ↗A concrete cooperation loop
You give one brief to the orchestrator
It records the goal, constraints and definition of done in RelayHall and splits the work into eligible tasks.The external launcher selects a bench
It checks capability, credentials, quota and isolation, then starts the supported CLI/SDK/service adapter. RelayHall’s notification can announce a task ID; it does not itself launch the agent.The worker authenticates and pulls context
It claims its task and receives the permitted brief. It executes using its own harness tools and model settings, with a separate checkout or session where needed.Evidence crosses the hall
The worker reports artifacts, checks, uncertainties and measured usage. A different authorized verifier reviews the work. The next task consumes that evidence and continues.Illustrative allocation: one model researches an API, a coding harness implements the change, a browser-capable worker tests the UI, and a separate reviewer verifies the result. Choose actual workers from your measured task results.
The potential is complementarity.
You gain provider diversity, specialty tools, resumable handovers and quota-aware scheduling without replacing every native agent loop. The limits are adapter coverage, provider terms, telemetry gaps and coordination overhead. Integrating many harnesses is feasible as an incremental program; universal compatibility and full quota visibility are not guaranteed.
RelayHall is an architectural reference for this report. The fleet design is a recommendation; no installation or integration was performed. Visual styling follows the linked public website without implying endorsement.
Tailored to your RelayHall plan
Connect the benches. Measure the work.
Recommended integration design and purchase sequence. This is a research proposal; no agents have been installed, accounts created, subscriptions purchased or RelayHall adapters tested.
RelayHall task→External quota router→Official adapter→Isolated worker→Events + artifacts
Start with three dispatch interfaces
Codex: official exec/App Server; documented account-quota reading is a strong fit for your goal.
Claude Code: official CLI/Agent SDK; structured tool, session and cost events. Remaining subscription quota needs additional qualification.
OpenCode: embedded SDK/event stream and flexible providers; useful as the common API-model worker alongside provider-owned agents.
This priority reflects integration fit. It does not assert that these are always the three strongest models.
Keep GUI workers as a separate pool
Prefer CLI or service APIs for code and file work. Use desktop/browser workers when a task actually requires those surfaces.
One shared interactive Windows desktop is a bottleneck: agents compete for focus, windows and input. Run GUI jobs serially there, or give each worker a separate VM/session. Linux shell workers can run separately without inheriting Windows GUI capabilities.
RelayHall holds the task record; an external launcher controls execution. Register identity, host, exact harness version, model, tool permissions and isolation mode. Treat different surfaces of the same brand as different worker types.
Architecture recommendation; workload and available hardware determine concurrency.
A telemetry contract RelayHall can rely on
Task lineagerelay_task_id, worker_id, native_session_id, attempt_id, parent_agent_id; preserve provider-native identifiers.
Lifecyclequeued → running → waiting → completed / failed / cancelled; heartbeat, latency, exit status and reason.
Resource useInput, cached input, output and reasoning tokens where exposed; measured wall time; tool calls; browser/compute charges.
Cost provenanceActual invoice/API usage, provider estimate or local estimate. Subscription allocation is bookkeeping, not an extra token charge.
Quota stateBucket/model/surface scope, used or remaining fraction, reset_at, measured_at, source and confidence. Unknown stays unknown.
DeliverablesArtifacts, change set, validation results and task-success rubric. Useful completed work matters more than raw token throughput.
Dispatch by constraints, then optimize
Filter candidates by operating system, tools, permissions, model entitlement, reachable quota and task type. Choose among the eligible workers using your measured success rate, duration and marginal cost; reserve scarce premium capacity for tasks that benefit from it.
Use reset-aware queues and cooldowns after rate limits. Stop duplicate work with leases and idempotency keys. Keep one model-independent task format, but translate permissions and tool configuration through each harness adapter.
Never infer a universal “remaining tokens” number from a subscription: different providers meter messages, weighted tokens, credits, rolling windows or effort. MCP connects tools; it is not automatically a task queue, event bus or billing interface.
Integration readiness: what was actually verified
Subscription access is not a general API license
Use a supported login or explicitly permitted coding-plan endpoint. OpenAI now documents Sign in with ChatGPT plan usage for eligible open-source and locally hosted apps; client registration, consent and host identity apply. Mistral documents a shared allowance across Vibe Code, Studio and API. These are specific supported routes, not permission to reuse any desktop credential in an arbitrary proxy. Kiro specifically limits where its subscription can be used; Claude bare mode specifically bypasses subscription login. Store account secrets in the worker’s credential store, not in RelayHall telemetry.
A staged buying plan
Install and qualify before buying broadly
Try the free/open harnesses with a small metered API budget. Install Codex, Claude Code and OpenCode first; then test Hermes/OpenClaw for general-agent roles, and Qwen/Kimi/Mistral for diversity. Pin versions and probe headless runs, cancellation, resumption and event output.Buy one complementary pair of entry subscriptions
Where your account has access, ChatGPT Plus ($20) + Claude Pro ($20) is a $40/month USD list-price trial pair. It buys provider diversity, not guaranteed capacity. Upgrade only the bottleneck you actually measure. Add an API budget for routing that the subscriptions do not permit.Run a representative task basket
Use the same coding, research, browser and file tasks over at least a full reset cycle. Measure accepted artifacts, retries, elapsed time and quota depletion. Record model/effort/tool settings. A headline benchmark alone cannot predict your cost per successful RelayHall task.Add specialized plans selectively
Mistral Pro ($14.99) is a European-provider candidate; Google AI Pro ($19.99) adds the Google workflow; coding endpoints such as Z.ai/MiniMax can serve compatible workers if their plan rules allow it. Several IDE subscriptions overlap—install broadly, but avoid paying for every editor before proving incremental value.Promote only workers with a tested contract
A worker is production-ready when it reports lifecycle and usable artifacts, respects cancellation and isolation, and handles quota failure. Full telemetry is an aspiration: expose field-level gaps instead of filling missing quota values with guesses.Compare value using your own completed work
This calculator uses your estimates, not advertised task allowances. Edit the inputs to compare a plan you are considering.
Estimated cost per accepted taskExcludes your review time and local hardware depreciation. A fixed subscription has low marginal cost only while capacity remains.
The wider provider landscape
Major model labs and enterprise stacks do not always offer an installable personal-PC harness. These adjacent offerings are separated from the main product catalogue.
Scope boundary
“No harness verified” is a coverage statement, not a claim that the company has no agents anywhere. Enterprise suites, region-specific services and developer frameworks may require contracts or custom deployment. Entries with no source are explicitly marked as research gaps and are not purchase-ready recommendations.
Coverage review · 2 October 2026
Three independent reviewers checked US/European providers, Asian providers and community harnesses against primary documentation, then discussed version, billing and model-link discrepancies. This revision adds Fable 5.1 / Fable 5, Haiku, Qwen flagship and coding models, Kimi variants, Grok Build 0.1, Qoder Sonus and the ZCode native harness.
Exact catalogue integrations remain separate from configurable provider routes. Alternative benchmark conditions stay visible; Fable means select strict OSWorld and HLE with tools rather than counting both alternatives. Documentation review is not a runtime integration test.
Unresolved: DeepSeek Pro routing conflicts between an official announcement and its pricing page. MiMo Code, Muse Spark, LongCat, Hy4 and complete TRAE / Comate model catalogues need further provider-level verification.
Review completed . Review record →
Evidence, definitions & limitations
What counts as a harness?
The runtime around a model: an agent loop, tools, state, permissions and execution environment. This report also includes model-access plans and frameworks, clearly labeled, because they are useful components of your fleet.
A desktop chat app, CLI coding agent, IDE agent and cloud worker are different surfaces. Windows browser access is not a native Windows application; Linux support is not proof of native Linux computer use.
“Local” separates locally installed code from locally hosted inference. A local CLI can still send all prompts to a cloud model.
How the research was evaluated
Primary sources: official product docs, pricing/download pages, vendor model cards and upstream repositories. Public-page snapshot checked on 2 October 2026; no paid accounts or installed product flows were used to validate quotas.
Prominence labels are qualitative editorial groupings. There is no verified common adoption statistic for every product; “popular” does not imply a precise market ranking.
Missing prices, telemetry fields and unsupported platform claims remain unverified. Product marketing and plan documentation can disagree; profile caveats preserve those discrepancies.
Benchmark methodology
Captured percentages stay on their original 0–100 scale. Means require at least two captured metrics. Single results remain single results. No score is invented for models lacking a verified panel.
Means cover different task mixes and cannot produce a global winner. Matching benchmark versions improve comparison, but vendor harnesses, effort, retries, runtimes and partial evaluations still matter. Historical/deprecated models are labeled.
These are vendor-reported snapshots, not independent replications or a measure of harness popularity. For fleet decisions, run your own accepted-task evaluation.
Commercial methodology
USD monthly list prices where available. Annual-equivalent and promotional prices are labeled. Taxes, region, account eligibility, credits and hosting charges may be additional. Current checkout is authoritative.
API rates are per million tokens when stated and exclude caching, long-context premiums, batch discounts and tool fees unless explicitly noted.
No universal cost-to-quota leaderboard is provided: providers do not expose comparable fixed task allowances. The buying strategy and calculator use transparent assumptions.
Citation numbers link directly to the primary source. Sources below retain full URLs for offline reading and audit.