Orchemax

The product, in full

The home page is the short version. This is the day-to-day flow, everything that ships under the seat, how a workspace differs from a project, the controls for whoever pays the bill, and the long answers.

Three more scenes

The home page lists three. These are the other three from the same repo.

“Two agents took the same ledger item.”

Both finished. Both were paid for. One diff had to be thrown away, and neither agent ever knew the other was there.

“Project A rebuilt what project B already had.”

Same workspace, same week, same retry helper. There was no way to ask the other project's agent whether it had already solved it.

“Every dashboard quotes a saving I cannot reproduce.”

A percentage on a slide is not a measurement. You want the number from your repo, and you want to see how it was counted.

How you work

Day-to-day flow only: what you do on your machine. No secret recipe; orch keeps the wiring under the seat.

1. Install & bind

Put orch in its own folder. Run orch setup and pick a separate workspace for your code. The client install is not the workshop home.

2. Open a seat

Go into a registered project folder and run orch opencode, orch claude, orch commandcode, or your agent. The first interactive seat is the Chair. A second Chair on the same project is blocked.

3. Chair vs workers

Why one Chair: if every agent acts like a director, they race the same files, invent duplicate helpers, and the work knots. Workers are for secondary tasks, directed by that Chair — not a second orchestra on the same project. Arrival order picks the Chair; you don’t appoint it in chat. Need more hands? Spawn workers; don’t open another Chair.

4. Shared code

Before editing common paths, take a lock. Search the registry before writing the helper. Edit, then release so teammates see the refresh. Don’t edit shared without a lock.

5. Claim the item, talk on the bus

Claim your ledger line so nobody else takes it. Leave short notes and handoffs for the other seats (inbox / notices). Use orch messaging, not a parallel vendor chat between agents.

6. Optional cloud

Link an Orchemax account when you want caps, spend visibility, and the CTO overlook. Source stays local; the cloud sees metadata, not your repo.

What ships under the seat

These exist elsewhere. What follows is how they differ here. Orchemax is written in Go for a small local binary; your workshops stay polyglot through ~30 language templates (TS, Python, Delphi, Rust, C#, …).

Worktrees and locks

A worktree per agent session is the industry default, and it only isolates. Orchemax adds the logical lock taken before the shared edit and the symbol registry consulted before the helper is written — then orch worktree promote merges fail-closed on conflict and never auto-pushes. Prevention and isolation, not one instead of the other.

A reaper that finishes the job

Watchdogs that notice a hung agent are common. This tick also fails the task, releases the lock, removes the worktree, sweeps expired externalized context and drops graph edges whose target symbol is gone — in one pass, with no extra database and no terminal multiplexer. Liveness watches the agent's own child PID with a grace window; the interval is yours, unset is 60s and 0 is off.

Gateway: your keys, one connection

Several keys per provider in a local vault as a rotating ring, each probed for connectivity before it is saved and never printed back. orch gateway status shows live/cooldown state, ring position and rotation counts, content-free. Claude Code keeps its plan: the gateway refuses an account bearer on purpose and tells you why.

Compression that reports net

The compressor is generic over any tool output, falls back to raw when parsing fails, and reports bytes saved after its own overhead. Errors, stack traces and non-zero exits are kept verbatim — compression that hides a panic is a bug, not a saving.

Heterogeneous workers over one protocol

Orchemax speaks ACP (JSON-RPC over stdio) as the client. Set agents.transport to acp and a Gemini CLI or OpenCode worker reports structured tool calls and results instead of scraped stdout; the default transport is still a subprocess. Verified for those two; Codex, Claude Code and Cursor run as subprocesses. A worker's permission request routes to the Chair through ask, so it can be approved by an agent rather than a human at the pane.

Active plan gates & DDL discipline

Free → Starter → Professional → Team → Enterprise. Agents call entitlements_status; quota and plan denials carry upgrade hints, and local Free caps apply when unlinked. Promote can require seeder and repository companions beside a migration so agents do not leave orphan schemas. ORCH_TASK_TOKEN_BUDGET caps a task's budget before it spawns; local secret masking keeps credentials out of the usage ledger and anything pushed as an event.

Gateway vs seat login

Gateway path: your API keys in the local vault

  • Crush and externalize shrink prompts before the provider, and rotation moves off a cooled-down key
  • Plan caps apply: concurrent agents, projects, runs/day
  • Company provider key stays on orch; agents get virtual keys

Seat-login path: Claude / Cursor on their own plan

  • Nothing is proxied and the login is untouched — orch will not substitute an account credential
  • The local PostToolUse hook still compresses tool output, and orch usage still counts those tokens from the transcript
  • Those agents are outside orch.agents.concurrent; plan agent counts do not limit them

One command: orch gateway enable, then orch gateway keys add <provider> and orch gateway status.

Workspace ≠ project

Illustration only: not a forced template. You declare paths; Orchemax binds .orch/ + orch.yaml and meters registered projects, not folder scans. Cross-project ask and search_shared_symbols {project} work inside one workspace like this one.

acme-workshop/                 ← WORKSPACE (not a billable project)
├── orch.yaml
├── .orch/                     ← Orchemax state only
├── apps/
│   ├── api/                   ← registered project (its own Chair)
│   ├── web/                   ← registered project (its own Chair)
│   └── worker/
├── shared/
│   ├── go/                    ← shared.go (+ orch:export)
│   ├── css/                   ← shared.css tip
│   └── js/                    ← shared.js tip
├── tools/
└── docs/

Order: 1 workspace → 2 register projects → 3 shared by language (+ assets)
api's agent can ask web's Chair; the answer carries project + path + line.

Ideal order to teach: workspace root → register projects → shared by language (and cross-cutting assets when every app assumes them). One Chair per project, several projects per workspace, one bus for all of them.

Controls for people who pay the bill

Solo builders get a governed local factory. Team CTOs get the overlook: who can run what, how much, and when — without babysitting every session.

Usage controls

Caps on projects, concurrent agents, devices, and runs. Token and spend visibility by project and model. Soft stop before the invoice surprises you.

Work schedules

Define when agents may run: business hours, quiet nights, freeze windows before releases. Policy travels with the org, not a sticky note in Slack.

Team allowlists

One Chair per project on the floor; Team+ allowlists who may dispatch and who may touch shared, so “anyone with a CLI” is not your security model.

CTO overlook

Governance events, ROI hours, live fleet pulse. Team Assist (approve/deny) live in /app; Telegram bot channel shipping. Metadata only, never source. You renew the subscription because you can see the floor.

Team integrations

Included with Team

  • Assist HITL (API live) · Telegram bot shipping
  • Webhooks · org overlook rollup

Add-ons (optional)

  • n8n workflow bridge
  • Zapier bridge
  • Activate under /app/integrations when ready

What you show leadership

CTOs answer “where did the AI money go?” with content-free facts — never source. Tokens, who spent them, gateway savings, and policy proof.

Sample figures, not live tenant data. ROI hours below are an estimate from attempt counts until work-pulse lands; compression and token mix are real gateway pushes. Your own numbers come from orch usage, not from this card.

ROI hours (estimate)

12.5h

Attempts × 0.25h — a renewal talking point, not a billing figure.

Compression

sample

Bytes kept off the wire vs sent, net of crush overhead. Read yours in orch usage.

Governance events

14

Promotes, denials, locks, claims — proof the floor is governed.

Live feed · fleet

5 online

Workstations + agent pulse. Pass / HITL / promoted to shared.

Team Assist: “Agent wants to change shared validators. Approve?” — console today; Telegram bot channel shipping. Tech Lead taps Approve from the café; the agent continues under org policy.

What we offer instead of a logo wall

No customer quotes, no logos, no counter. Three things you can check yourself:

  • The benchmark runs in CI, not in a slide. tests/benchmark/antidup is a Go test; the workflow .github/workflows/antidup-benchmark.yml uploads its JSON as the antidup-bench-json artifact on every run — duplicates shipped, duplicates blocked, broken merges, conflicts detected.
  • The overlook card on this page is a labelled sample. Every figure under What you show leadership is marked sample or estimate. Your real numbers come out of orch usage on your repo, on the free tier, on day one.
  • The privacy claim has a regression test. The overlook payload is content-free by schema and TestMarkdownContentFree fails if code text ever appears in it.

Before you install it

The four things people ask on the way in, answered without the sales version.

Is this another layer between me and my agent?

No. Orchemax does not proxy your traffic and does not replace your login. It registers MCP tools your agent can call and one harness hook. The CLI you open is the CLI you had.

Will it break my Claude or Codex subscription?

It used to — a bug injected API credentials into a plan login and killed the subscription. That is fixed, the gateway now refuses to substitute an account credential and says why, and plan-billed seats are compressed by the local hook rather than routed anywhere.

Does my source reach your cloud?

No. The runtime is local. A linked account receives counters, model names, session ids and governance events — content-free by payload schema, with a regression test that fails if code text ever appears in it. Unlinked workshops keep working.

We already use git worktrees. What is left?

Worktrees isolate and defer the collision to merge time. What is left is the lock taken before the shared edit, the registry consulted before the helper is written, the claim on the ledger line, the reaper that cleans up after a crash, and a promote that refuses rather than guesses.