Complete Community Edition under Apache 2.0. No telemetry.See the source
Agents City

How to use Claude, Codex, OpenCode, and Kimi in one project

Choose the best runtime for each window without forcing every provider through the same terminal fallback or losing one coordination boundary.

Reviewed against Agents City 0.3.0-beta.22 · commit c985198 ↗
01

The real problem

A developer prefers Codex for the chair, Claude for API work, OpenCode with a local model for analytics, and Kimi for research. Separate launchers work, but they do not share a typed local envelope, one goal, or a visible decision process.

02

Target outcome

Each window keeps its provider-native last mile while Agents City supplies the city identity, role, goal, bus envelope, Hall activity, and committee protocol.

multi-model-lab

Domain
software
Goal
Build and verify one product slice using the most appropriate runtime for each evidence source.
Chair seat
Codex
Units and evidence
seatchair · Codex

Goal ownership, synthesis, decisions, and road boundary

apidev · Claude

Backend implementation and contract evidence

analyticsdata · OpenCode

Local-model analysis through HTTP/SSE

researchresearcher · Kimi

Source review through REST/WebSocket delivery

04

Before you start

  1. 01

    Install and authenticate every runtime you intend to use before adding it to Agents City.

  2. 02

    Validate any OpenCode provider or local model directly with OpenCode first.

  3. 03

    Know that live runtime benchmarks can consume provider quota or money.

05

How to do it

  1. Step 01

    Create the project city

    Select the repositories, roles, and product goal first. Runtime selection should serve those responsibilities rather than define them.

    TERMINAL
    agents-city setup --city multi-model-lab
  2. Step 02

    Choose a native runtime per window

    Open the engine picker and assign Codex, Claude, OpenCode, or Kimi to each window. Persistent choices stay on the owner card.

    TERMINAL
    agents-city seat --city multi-model-lab --engines
  3. Step 03

    Launch and inspect visible activity

    Open the city session, use the Hall for the read-only live view, and separate semantic activity from diagnostics when investigating a runtime failure.

    TERMINAL
    agents-city seat --city multi-model-labagents-city logs --activity --lines 50agents-city logs --diagnostics --lines 200
  4. Step 04

    Measure the real path only when needed

    Run the offline stress benchmark first. Use the live benchmark only after checking authentication, limits, and cost for every selected provider.

    TERMINAL
    agents-city benchmark stress --jsonagents-city benchmark live --runtime claude --runtime codex --runtime kimi --timeout 180 --json
06

What you should get

  • Known providers receive work through their native adapters rather than silent terminal injection.
  • The Hall and logs expose visible work and failures without collecting provider reasoning.
  • Changing a runtime does not change the city’s authority model or repository ownership.
07

What this does not solve

  • Agents City does not include provider subscriptions, accounts, or model quota.
  • Models may produce different answers; the chair and verification protocol still matter.
  • Outbound network remains available unless you add stronger external isolation.