# How to orchestrate multi-agent coding in Orca ADE with OpenCode and GLM-5.2

Running a single coding agent in your terminal works fine until a task spans backend schema changes, frontend components, and integration tests at the same time. When you open a second or third shell and try to wire those agents together with custom bash scripts, `tmux send-keys`, or shared lockfiles, the setup breaks down fast.

Terminal user interfaces repaint the screen on every token, so raw stdout pipes return unreadable escape sequences. Blindly injecting keystrokes into another pane fails whenever an agent pauses on a permission prompt, and running a 30-second watch loop in your lead agent burns context tokens just to ask whether a worker has finished.

### How do you coordinate two or more OpenCode agents across shells in Orca ADE without polling loops, corrupted terminal buffers, or git branch collisions?

In this guide, we show how to connect [OpenCode](https://opencode.ai/) to our European API ([see our step-by-step OpenCode API setup tutorial](https://regolo.ai/using-regolo-models-with-opencode/)) and use the native `orca` CLI built into **Orca ADE** to orchestrate multi-agent workflows with `GLM-5.2`. You will learn both native cross-shell patterns: supervised mailbox orchestration (`orca orchestration`) for task graphs with automatic wake-ups, and direct PTY terminal control (`orca terminal`) for side-by-side interactive sessions.

 ORCA ADE MULTI-SHELL ARCHITECTURE · OPENCODE + REGOLO EU MODELS### How multiple OpenCode shells communicate inside Orca ADE with Regolo models

Inside Orca ADE, each OpenCode shell runs in its own git worktree or split pane, powered by a dedicated model on `https://api.regolo.ai/v1` and connected by the native `orca` CLI runtime bus.

 

 

Orca ADE · Workspace: repo-123 (multi-agent OpenCode session)

orca daemon: active

 

  ORCA WORKTREES & TERMINALS

  **main (Coordinator)** 

Mailbox: `run:r-901` · OpenCode

Model: `regolo-ai/glm-5.2`

 

  **wt-1: auth-pkce-refresh** 

Mailbox: `dispatch:d-101` · Task 1

Model: `regolo-ai/qwen3.8-27b`

 

  **wt-2: session-middleware** 

Mailbox: `dispatch:d-102` · Task 2

Router: `regolo-ai/brick-v1-beta`

 

  **split: security-reviewer** 

PTY handle: `term-8841`

Model: `regolo-ai/glm-5.2`

 

SHARED CONFIG (~/.config/opencode)

`provider: "regolo-ai"`

`baseURL: "api.regolo.ai/v1"`

`env: REGOLO_API_KEY`

 

    SHELL 1 · COORDINATOR AGENT (OpenCode TUI) GLM-5.2 · run:r-901 

$ orca orchestration run-create --objective "OAuth2 PKCE + session headers"

$ orca orchestration worker-start --task task-1 --worktree new-top-level --name auth-pkce-refresh --agent opencode --model regolo-ai/qwen3.8-27b

$ orca orchestration worker-start --task task-2 --worktree new-top-level --name session-middleware --agent opencode --model regolo-ai/brick-v1-beta

→ Turn ended (0 tok/s sleep). Woken automatically by Orca when d-102 sends ask or d-101 reports worker_done.

 

 

 ORCA NATIVE CROSS-SHELL COMMUNICATION BUS (ZERO POLLING)

 **↓ worker-start / send** Spawns isolated git worktree & delivers task spec to `dispatch:d-101` 

 **↑ ask → auto-wake → reply** Worker asks schema question; Orca wakes `GLM-5.2` lead to reply 

 **↔ terminal send & read --screen** Direct PTY bridge to `term-8841` with `turn_started` receipt 

 

 

   SHELL 2 · WORKER 1 (wt-1) Qwen3.8-27B · d-101 

[Preamble: Task task-1 | Dispatch d-101]

$ pnpm test src/auth/refresh.test.ts

\# 361-line log (9,493 tok) stays local

→ Reports 92-tok worker_done summary to run:r-901

 

 

  SHELL 3 · WORKER 2 (wt-2) Brick → 120B / 27B · d-102 

\# Brick routes grep turns to GPT-OSS 120B

$ orca orchestration ask --question "Return 401 + X-Token-Expired: 1?"

→ Pauses turn; woken when GLM-5.2 replies

 

 

  SHELL 4 · SPLIT PANE PTY GLM-5.2 · term-8841 

\# Driven via orca terminal send --wait-submit

Stage 1: input_accepted ✓

Stage 2: turn_started ✓ → tui-idle

→ Lead reads clean frame via --screen

 

 

 

 

 

   **REGOLO EUROPEAN INFERENCE API (`https://api.regolo.ai/v1`)** Certified Zero Data Retention · Flat €39/mo Regolo Core Pool (600M tokens) 

 GLM-5.2 (Lead & Review) Qwen3.8-27B (Patch Worker) Brick → GPT-OSS 120B (Fast Scans) 

 

 

## Connect OpenCode to our API and verify the Orca CLI

Before spawning multiple agents in Orca ADE, every terminal session needs access to your OpenCode configuration and our European inference endpoint (`https://api.regolo.ai/v1`). If you have not installed OpenCode or created an API key yet, follow our dedicated tutorial on [using Regolo models with OpenCode](https://regolo.ai/using-regolo-models-with-opencode/) first.

### Step 1: Register GLM-5.2 and Brick in ~/.config/opencode/opencode.json

Export your API key in your shell profile (`~/.zshrc` or `~/.bashrc`) so every new terminal pane and git worktree opened by Orca inherits it automatically:

```
export REGOLO_API_KEY="your-regolo-api-key"Code language: JavaScript (javascript)
```

Next, place this configuration in `~/.config/opencode/opencode.json` (or grab our ready-made templates from [regolo-ai/opencode-configs](https://github.com/regolo-ai/opencode-configs)). It registers `glm-5.2` as your primary orchestrator model alongside `qwen3.8-27b`, `gpt-oss-120b`, and our [Brick semantic router](https://github.com/regolo-ai/brick-SR1) (`brick-v1-beta`):

```
{
  "$schema": "https://opencode.ai/config.json",
  "model": "regolo-ai/glm-5.2",
  "small_model": "regolo-ai/gpt-oss-120b",
  "compaction": {
    "auto": true,
    "prune": true,
    "reserved": 10000
  },
  "provider": {
    "regolo-ai": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Regolo European API",
      "options": {
        "baseURL": "https://api.regolo.ai/v1",
        "apiKey": "{env:REGOLO_API_KEY}"
      },
      "models": {
        "glm-5.2": {
          "name": "GLM-5.2 (Orchestrator & Multi-File Reasoning)"
        },
        "qwen3.8-27b": {
          "name": "Qwen3.8-27B (Fast Implementation Worker)"
        },
        "gpt-oss-120b": {
          "name": "GPT-OSS 120B (High-Speed Repo Discovery)"
        },
        "brick-v1-beta": {
          "name": "Brick Semantic Router (MoM Gateway)"
        }
      }
    }
  }
}Code language: JSON / JSON with Comments (json)
```

### Step 2: Resolve the native Orca CLI executable for your platform

Orca ADE ships with a built-in CLI that controls worktrees, PTY terminals, and the inter-agent message bus directly from any shell. Pick the right binary name once per session and reuse it:

- **macOS (inside Orca terminals or from the app bundle):** Run `orca` if it is in your `$PATH`, or invoke the bundled binary directly at `/Applications/Orca.app/Contents/Resources/bin/orca`.
- **Linux:** Inside an Orca-managed terminal, run `orca`. Outside Orca terminals on Linux, always run `orca-ide` so you do not accidentally launch the GNOME screen reader at `/usr/bin/orca`.
- **WSL and managed remote sessions:** Use the path exported in `$ORCA_CLI_COMMAND`.

Inside your lead OpenCode terminal, ask the CLI to print its version-matched orchestration and terminal manuals so the agent has the exact command contract in context:

```
# Load the structured multi-agent orchestration contract
orca skills get orchestration

# Load the worktree and cross-terminal PTY control contract
orca skills get orca-cliCode language: Bash (bash)
```

  SOVEREIGN EUROPEAN INFERENCE 

Run OpenCode and GLM-5.2 in Europe with Zero Data Retention

Get 600 million monthly tokens on our flat Regolo Core plan (€39/mo, ~€0.065/1M tokens). Orchestrate parallel OpenCode workers on 100% green European GPUs without per-seat throttling or US CLOUD Act exposure.

[Start 30-day free trial (no card required) →](https://regolo.ai/pricing/)

Free credits included · 100% green energy · ✓ EU Green Datacenters ✓ Certified [Zero Data Retention](https://regolo.ai/zero-data-retention/)

## Pattern 1: supervised multi-agent orchestration with orca orchestration and GLM-5.2

When your lead agent needs to break a feature into sub-tasks, assign them to two or more worker agents, answer their questions, and verify their output before merging, use `orca orchestration`. This subsystem gives your `GLM-5.2` coordinator a dedicated mailbox (`run:<run_id>`) and assigns each worker its own dispatch address (`dispatch:<dispatch_id>`).

### Step 1: Create an orchestration run and a task dependency graph

From your primary OpenCode shell (running on `regolo-ai/glm-5.2`), bind a new orchestration Run and define the tasks. Tasks that can run in parallel have no dependencies, while integration verification waits on both upstream tasks via `--deps`:

```
# 1. Create and bind the orchestration Run for this coordinator shell
orca orchestration run-create --objective "Add OAuth2 PKCE token refresh and integration tests"

# 2. Create two parallel implementation tasks (returns task-1 and task-2)
orca orchestration task-create --spec "Target: src/auth/refresh.ts. Implement PKCE token rotation with retry lock. Run pnpm test src/auth/refresh.test.ts and report the exit status."
orca orchestration task-create --spec "Target: src/middleware/session.ts. Wire refreshed tokens into session headers without breaking existing cookie fallback. Run pnpm typecheck."

# 3. Create a downstream verification task that waits for both workers
orca orchestration task-create --spec "Run the full auth integration suite and inspect any regression logs." --deps '["task-1", "task-2"]'

# 4. List tasks that have all dependencies satisfied and are ready to launch
orca orchestration task-list --ready --briefCode language: Bash (bash)
```

### Step 2: Start parallel OpenCode workers in isolated worktrees and end the turn

If two workers edit overlapping files in the same directory at the same time, their git staging areas will collide. Pass `--worktree new-top-level` when starting parallel file editors so Orca creates a clean git worktree for each worker automatically (use `--worktree current` only when workers perform read-only audits or touch completely separate folders):

```
# Find your repository ID in Orca
orca repo list --json

# Launch Worker 1 in its own isolated git worktree on GLM-5.2
orca orchestration worker-start \
  --task task-1 \
  --worktree new-top-level \
  --repo id:repo-123 \
  --name auth-pkce-refresh \
  --agent opencode \
  --model regolo-ai/glm-5.2

# Launch Worker 2 in a second isolated git worktree on Qwen3.8-27B
orca orchestration worker-start \
  --task task-2 \
  --worktree new-top-level \
  --repo id:repo-123 \
  --name session-middleware \
  --agent opencode \
  --model regolo-ai/qwen3.8-27bCode language: Bash (bash)
```

Once `worker-start` returns the dispatch receipts, **your coordinator agent must immediately end its turn**. Never write a bash `while true; do sleep 30; orca orchestration check; done` script. A background shell script that runs a plain `check` consumes the unread messages from the queue, which hides them from the coordinator and prevents Orca from triggering an automatic wake-up.

 PATTERN 1 LIFECYCLE · ORCA ORCHESTRATION AUTO-WAKE### How the event-driven coordinator loop replaces bash polling

Instead of running a 30-second watch script that steals messages from the inbox, the `GLM-5.2` coordinator ends its turn after spawning workers and lets the Orca runtime wake it on demand.

Stage 1 · Coordinator

Create DAG &amp; spawn workers

Binds `run:<id>`, creates `task-1` &amp; `task-2`, and launches parallel OpenCode checkouts.

 

orca orchestration worker-start

 

Stage 2 · Zero-poll sleep

Coordinator ends its turn

Lead shell sleeps at **0 tok/s** while workers edit files and run tests in isolated git worktrees.

 

status: idle (awaiting wake)

 

Stage 3 · Worker signal

Worker calls ask or worker_done

Worker hits a schema question or finishes its test suite and posts to `run:<id>`.

 

orca orchestration ask / done

 

Stage 4 · Runtime wake

Orca wakes GLM-5.2 shell

Orca triggers a single coordinator turn to run `check`, send `reply`, and resolve gates.

 

orca orchestration check &amp; reply

 

 

 **Why bash watch loops break Orca:** Running `while true; do orca orchestration check; done` consumes unread mail in the background shell, hiding it from the wake hook. **1 wake turn** vs 30 polling turns / 15m 

Orca ADE runtime contract (`orca skills get orchestration`) with OpenCode on `https://api.regolo.ai/v1`.

### Step 3: Event-driven cross-shell messaging (ask, check, reply, and send)

Inside each spawned shell, Orca injects a preamble containing the worker's `Task ID` and `Dispatch ID`. When a worker hits an architectural ambiguity, it does not guess or block on stdin. Instead, the worker sends a structured question back to the `GLM-5.2` coordinator and ends its turn:

```
# Executed inside Worker 2's shell when it needs a schema decision
orca orchestration ask --question "Should expired refresh tokens return HTTP 401 with X-Token-Expired: 1 or trigger an inline redirect?"Code language: Bash (bash)
```

As soon as Worker 2 runs `ask` (or finishes its assignment and reports `worker_done`), the Orca runtime wakes the sleeping `GLM-5.2` coordinator shell and provides the exact `check` command to run:

```
# 1. Coordinator inspects unread messages from all workers in the Run
orca orchestration check

# 2. Coordinator replies directly to Worker 2's question (Orca wakes Worker 2 with the answer)
orca orchestration reply --id msg-409 --body "Return HTTP 401 with X-Token-Expired: 1 so API clients can refresh without following HTML redirects."

# 3. Coordinator can also push new instructions to any specific worker or broadcast to @all
orca orchestration send --to dispatch:disp-102 --subject "Header casing" --body "Keep header names lowercase in the test assertions."
orca orchestration send --to @all --subject "Freeze schema" --body "Do not modify packages/shared-types in this run."Code language: Bash (bash)
```

Because each worker runs its own test suite and log inspection inside its isolated worktree, thousands of lines of compiler and test runner output stay inside the worker's disposable session. The `GLM-5.2` coordinator receives only the concise `worker_done` summary and verification receipt, preserving its context window for high-level reasoning.

 CONTEXT WINDOW ISOLATION · WORKER WORKTREE VS COORDINATOR### What stays in the worker worktree vs what reaches the GLM-5.2 coordinator

Each `worker-start --worktree new-top-level` session acts as a context firewall: noisy compiler logs and test runner dumps stay inside the disposable worker shell.

1. Inside worker worktree (disposable)

Raw test logs &amp; file diffs stay local

Worker runs `pnpm test` &amp; `pnpm typecheck` across 361 lines of output (**9,493 raw tokens**) plus intermediate file edits in its isolated git checkout.

 

worktree: repo-123::/path/auth-pkce

 

→

2. Orca mailbox bus

Structured dispatch envelope

Worker settles its assignment or asks a targeted question over `dispatch:disp-102 → run:<id>` without forwarding raw terminal scrollback.

 

mailbox: dispatch:disp-102 → run:r1

 

→

3. Coordinator shell (GLM-5.2)

Receives 92-token verified receipt

Coordinator reads only the task status, exit code, branch name, and concise summary (**-99.0% log noise removed** from main context).

 

worker_done: exit 0 · 92 tokens

 

 

Measured on a 361-line test runner log on `https://api.regolo.ai/v1`: 9,493 raw tokens in the worker shell condensed to a 92-token coordinator receipt.

### Step 4: Guard risky operations with decision gates

When a task involves database migrations, authentication rules, or public API changes, you can attach a blocking decision gate before the downstream task runs:

```
# Block the final verification/merge task until GLM-5.2 reviews both diffs
orca orchestration gate-create --task task-3 --reason "Verify zero breaking changes in public session types before integration run"

# List pending gates across the current Run
orca orchestration gate-list

# Unblock the gate once the coordinator verifies the worker diffs
orca orchestration gate-resolve --gate gate-12 --decision approve --note "Checked git diff across both worker worktrees; types are backward-compatible."Code language: Bash (bash)
```

## Pattern 2: direct cross-shell PTY communication with orca terminal

Sometimes you do not need a multi-step task DAG. You simply have two interactive terminals open side by side in Orca ADE, such as an OpenCode coder pane and an OpenCode security reviewer pane, and you want one shell to pass a prompt to the other and read back its screen output.

### Step 1: Launch a sibling agent or split pane and locate its PTY handle

You can start a second OpenCode agent in the current worktree or split your existing terminal vertically:

```
# Option A: Start a fresh OpenCode agent in the current checkout
orca agent launch --agent opencode --worktree current --model regolo-ai/glm-5.2 --prompt "Act as a security reviewer for auth patches." --json

# Option B: Split the current terminal pane left/right and launch OpenCode
orca terminal split --direction vertical --command "opencode" --jsonCode language: Bash (bash)
```

Never match terminals by their window title, because TUI agents repaint their terminal title on every turn. Instead, join the `paneKey` (`<tabId>:<leafId>`) from `orca worktree ps --json` with `orca terminal list --json` to grab the immutable runtime handle (for example, `term-8841`):

```
# List active agent panes and their runtime terminal handles
orca worktree ps --json
orca terminal list --worktree current --jsonCode language: Bash (bash)
```

### Step 2: Send prompts with submission proof and wait for TUI idle

Before sending input to another shell, read its rendered screen frame with `--screen` to confirm it is ready. Then use `orca terminal send --wait-submit 10`. Unlike `tmux send-keys`, Orca tracks two distinct verification stages (`input_accepted` followed by `turn_started`) and refuses to inject text with `agent_prompt_blocked` if the target agent is currently displaying a permission or trust menu:

```
# 1. Inspect the target agent's current rendered TUI screen (no raw ANSI noise)
orca terminal read --terminal term-8841 --screen --json

# 2. Send the cross-shell prompt and wait up to 10s for turn_started proof
orca terminal send \
  --terminal term-8841 \
  --text "Review src/auth/refresh.ts for token replay edge cases and list any findings." \
  --enter \
  --wait-submit 10 \
  --json

# 3. Wait until the target OpenCode TUI finishes generating and returns to idle
orca terminal wait --terminal term-8841 --for tui-idle --timeout-ms 300000 --json

# 4. Read the clean final screen output back into your first shell
orca terminal read --terminal term-8841 --screen --jsonCode language: Bash (bash)
```

 PATTERN 2 PTY PROTOCOL · ORCA TERMINAL SEND &amp; READ### Anatomy of a verified cross-shell PTY handoff (orca terminal)

How Shell A safely drives Shell B across split panes without corrupting TUI menus or reading broken ANSI escape sequences.

1. Address resolution

Join paneKey to handle

Match `agents[].paneKey` (`tabId:leafId`) from `worktree ps` to `terminal list` instead of volatile window titles.

 

handle: term-8841

 

2. Permission guard

Block blind injection

If Shell B is paused on a trust or permission dialog, Orca refuses text+Enter with `agent_prompt_blocked`.

 

--wait-submit 10

 

3. 2-stage receipt

Prove turn started

Tracks `input_accepted` → `turn_started` with a replay-safe `operationId`, then waits for `tui-idle`.

 

--for tui-idle

 

4. Clean viewport

Read rendered screen

Captures the current TUI frame buffer cleanly via `--screen` instead of stacked ANSI redraw fragments.

 

terminal read --screen

 

 

Orca ADE terminal contract (`orca skills get orca-cli`): deterministic cross-pane control for OpenCode, Claude Code, and Codex.

## Comparing cross-shell methods and cutting worker token costs with Brick

The table below summarizes when to use raw shell utilities, direct PTY control via `orca terminal`, or supervised orchestration via `orca orchestration` when running OpenCode on our API.

Cross-shell agent communication methods in Orca ADE

Comparing raw shell scripts, direct PTY terminal commands, and supervised mailbox orchestration

 

 Orca CLI runtime contract (Nov 2026) 

 | Capability | Ad-hoc tmux / pipesManual bash scripts &amp; lockfiles | orca terminalDirect PTY bridge (--screen / --wait-submit) | orca orchestrationSupervised mailbox, DAG &amp; auto-wake |
|---|---|---|---|
| Delivery verificationProof the prompt started a turn | 0 stages (blind)Types into permission prompts by mistake | 2 stages verified`input_accepted` → `turn_started` | Durable mailbox receiptTracked per `dispatch:<id>` &amp; `run:<id>` |
| Completion detectionHow the lead agent knows work finished | Polling loop (30 turns/15m)Burns tokens checking every 30 seconds | Blocking CLI wait`terminal wait --for tui-idle` | Event-driven auto-wakeCoordinator ends turn; woken on `ask` or `worker_done` |
| Git workspace isolationPreventing staging &amp; branch collisions | Manual git worktreeNo automatic cleanup or UI tracking | worktree create --agentGood for 1-way fire-and-forget handoffs | worker-start new-top-levelManaged lifecycle + auto-close on settle |
| Context window hygieneTest log noise sent to GLM-5.2 lead | 9,493 tok raw dumpIncludes ANSI redraw fragments | 1 screen frameClean viewport via `terminal read --screen` | 92 tok summary (-99%)Full logs stay inside the worker worktree |
| Approval gates &amp; DAGsMulti-step dependencies &amp; human/lead review | None built-inRequires custom state machine code | Manual turn-by-turnBest for 2 interactive shells side by side | Native --deps &amp; gate-createBlocks downstream tasks until `gate-resolve` |

When you scale from one coding agent to three or four parallel workers, token volume grows quickly. If every worker uses a frontier proprietary API for routine file discovery, log grepping, and test execution, a single 7.2-million-token multi-agent task costs around $5.59 on the Artificial Analysis Coding Agent Index v2.0 baseline.

To keep multi-agent runs affordable without sacrificing architectural accuracy, assign `regolo-ai/glm-5.2` to your coordinator shell and point routine worker sub-tasks at `regolo-ai/brick-v1-beta` (as detailed in our guide on [OpenCode and Brick for multi-agent coding](https://regolo.ai/opencode-brick-for-multi-agent-coding-and-optimize-costs-up-to-80/)).

 MULTI-AGENT FINOPS ROUTING · GLM-5.2 LEAD + BRICK WORKERS### How to route coordinator and worker turns across our European model pool

Keep architectural decisions on `GLM-5.2` while routing high-frequency worker exploration to compact models through `brick-v1-beta`.

Coordinator shell · High-reasoning lead

regolo-ai/glm-5.2 (Pinned)

Handles low-frequency, high-leverage turns: decomposing the objective into a Task DAG (`task-create --deps`), answering worker `ask` escalations, and reviewing cross-worktree diffs at `gate-resolve`.

 

--model regolo-ai/glm-5.2

 

Worker shells · Mixture-of-Models gateway

regolo-ai/brick-v1-beta (Dynamic routing)

Inspects each worker turn: routes file discovery, grep checks, and log summaries to fast models (`gpt-oss-120b` at 237 tok/s or `qwen3.5-9b`) and escalates multi-file patches to `qwen3.8-27b` or `glm-5.2`.

 

--model regolo-ai/brick-v1-beta

 

 

 **Regolo Core flat pool (€39/mo for 600M tokens, ~€0.065/1M):** An estimated 7.2M-token multi-agent run costs **~€0.47** under EU Zero Data Retention (vs **$5.59** on frontier multi-model baselines). **100% EU ZDR** · Zero long-context surcharges 

Configured in `~/.config/opencode/opencode.json` on `https://api.regolo.ai/v1` ([regolo-ai/brick-SR1](https://github.com/regolo-ai/brick-SR1)).

**Explore related OpenCode and agent harness guides on Regolo:** Start with our foundational tutorial on [configuring OpenCode with Regolo](https://regolo.ai/using-regolo-models-with-opencode/), learn how to cut multi-agent token spend in [OpenCode + Brick for multi-agent coding](https://regolo.ai/opencode-brick-for-multi-agent-coding-and-optimize-costs-up-to-80/), check our [Qwen3.8-27B harness engineering configs for Pi, OpenCode, and Kilo Code](https://regolo.ai/harness-engineering-for-qwen3-8-27b-a-technical-guide-to-pi-opencode-and-kilo-code/), add cross-session context with [persistent codebase memory via ai-memory](https://regolo.ai/getting-started-ai-memory-regolo-persistent-codebase-memory/) and [Context Engineering 101 Part 2 (Retrieve, offload, delegate)](https://regolo.ai/context-engineering-for-agents-101-part-2-retrieve-offload-delegate/), or browse all supported tools on our [agent integrations hub](https://regolo.ai/integrations/).

 ZERO DATA RETENTION 

Get engineering notes and model releases in your inbox.

Sovereign AI inference, OpenAI-compatible, EU-hosted. Benchmarks, new models (Mistral, Qwen, GLM), and cost insights. One email, no spam.

✓

Thank you for subscribing!

Please check your inbox to confirm your subscription.

 

   Subscribe Free 

   I accept the [Privacy Policy](https://regolo.ai/privacy-policy/) \*  

    100% European infrastructure · Zero spam · Unsubscribe anytime.

 

## Frequently asked questions

**Does Orca ADE have a native CLI for cross-shell communication between coding agents?**
Yes. Orca ADE includes the `orca` CLI, which provides two native cross-shell mechanisms: `orca orchestration` for supervised coordinator-to-worker mailboxes, task dependency graphs, and automatic turn wake-ups, and `orca terminal` (`send`, `wait`, `read --screen`) for direct PTY interaction across split panes and worktrees.

**How do I connect OpenCode to Regolo to run GLM-5.2 across multiple Orca shells?**
Export `REGOLO_API_KEY` in your shell profile and register `https://api.regolo.ai/v1` under the `regolo-ai` provider in `~/.config/opencode/opencode.json` with `glm-5.2` set as the default model. Every terminal or git worktree spawned by Orca ADE automatically inherits that global OpenCode configuration, as shown step by step in our [Using Regolo models with OpenCode guide](https://regolo.ai/using-regolo-models-with-opencode/).

**Why should a GLM-5.2 coordinator end its turn after starting workers in Orca ADE?**
In `orca orchestration`, the runtime monitors worker state and automatically wakes the coordinator shell whenever a worker asks a question (`orca orchestration ask`) or completes its task (`worker_done`). Running a bash polling loop with `orca orchestration check` steals messages from the queue before the wake hook can fire and wastes tokens on empty checks.

**When should I use orca orchestration worker-start vs orca worktree create --agent?**
Use `orca orchestration worker-start` when the lead agent needs to supervise the worker, answer questions, enforce decision gates, and receive the final result back in the coordinator shell. Use `orca worktree create --name <task> --no-parent --agent opencode --prompt "..."` for a full one-way handoff where the new agent takes independent ownership and nothing needs to report back.

**How can I reduce token costs when running multiple OpenCode workers in parallel on Regolo?**
Keep `regolo-ai/glm-5.2` on the lead coordinator shell for task decomposition and diff review, and configure worker sub-tasks to use our open-source `brick-v1-beta` semantic router or `gpt-oss-120b`. Brick classifies each prompt and routes low-complexity file reads and grep checks to compact models on our flat €39/month Regolo Core pool (600M tokens) under European Zero Data Retention.

    PRODUCTION-READY EU INFERENCE · ZERO DATA RETENTION  OpenAI-Compatible API 

Ship Private AI. Not Infrastructure.

 You have the architecture and the open-source workflow. Now give it a sovereign European inference layer built for production: fast access to **GLM-5.2, Qwen3.5, Mistral, Llama, DeepSeek**, and **Brick Complexity Pro** with zero data retention and no new SDK to learn.

 DROP-IN ENDPOINT `export OPENAI_BASE_URL="https://api.regolo.ai/v1"` Keep your existing SDK &amp; agent setup 

 

  [    30-DAY FREE TRIAL 

Start your 30-day free trial →

Build, test, and deploy with no infrastructure to maintain. Core plans from €11.70/mo (70% off first 3 months).

 ](https://regolo.ai/pricing/)  [    OPEN-SOURCE CODE 

Clone the GitHub repository →

Get the full implementation, configuration scripts, evaluation benchmarks, and ready-to-run templates.

 ](https://github.com/regolo-ai/tutorials/)  [    BUILDER COMMUNITY 

Join the Regolo Discord →

Meet engineers building with coding agents, private RAG, local LLMs, and production open-weight models.

 ](https://discord.gg/bqGrVJHeF)  [    ARCHITECTURE REVIEW 

Talk to an AI Infrastructure Engineer →

Scaling beyond a proof of concept or running regulated EU workloads? Get a tailored architecture and commercial plan.

 ](https://regolo.ai/contacts/) 

 **Private AI should not require a private data center.** Regolo gives your team an EU-native path from local experimentation to production-grade inference. 

 [API Docs](https://docs.regolo.ai) · [GitHub](https://github.com/regolo-ai/tutorials/) · [Discord](https://discord.gg/bqGrVJHeF) · [X (@regolo\_ai)](https://x.com/regolo_ai) · [Reddit](https://www.reddit.com/r/regolo_ai/) · [Contact](https://regolo.ai/contacts/) 

Built by the Regolo team · 100% EU Sovereign GPU