Orquestra Studio

The problem

Anyone who works with more than one coding AI becomes the link between them. They open a window for each one, copy by hand what one did over to the other, and keep in their head who does what, and in what order.

Leaving the AIs working on their own for hours brings another risk: using the strongest, and most expensive, one on a simple task that a smaller one could handle. And, in the end, there is no proof that the result was tested and checked.

What it does

1. 1
   Turns the request into a plan

   You describe what you want. One of the AIs splits the work into tasks and shows what depends on what, with an estimate of time and usage. Nothing starts before you approve.

2. 2
   Picks who does each part

   One AI plans, another carries out the work and a third checks it. The dashboard picks which version of each AI to use in each role and, if one becomes unavailable, hands the turn to the next one in line.

3. 3
   Runs several tasks at once

   Tasks that do not depend on each other move forward at the same time, each in a separate copy of the project, so one does not get in the way of the other.

4. 4
   Only checked work gets in

   Each task goes through the project's tests and a read by an AI from another company; if it asks for changes, the task goes back. Your project only changes when you open the changes and apply them.

On screen

The screens show a test project, with a simulated AI in place of the three.

1Plan2Run3Delivery

Tap outside the image to close it.

Tap outside the image to close it.

Tap outside the image to close it.

What changes

The person is no longer the link between the AIs. They describe the request, approve the plan and check the delivery; the order, the copies and the checking are left to the dashboard.

And the delivery comes with the proof: each task with its tests and checks recorded, from the starting version to the final result.

In one test round, the log of each step showed that 84% of the usage was the AI rereading what it had already read. That leads to the next step: choosing the right AI and effort for each task and learning from each round, to spend less on every project. It can serve any person or team that already works with more than one AI.

Problem, improvement and result

Problem

Three coding agents, Codex, Claude Code and Antigravity, each in its own terminal: context passes from one to the other by hand, the split, the order and the integration live in the operator's head, and there is no way to prove that the result was tested and reviewed. In a cycle that runs for hours, there is also the risk of using a large model, at high effort, where a smaller one would do.

Improvement

A deterministic core in Node.js, through the official CLIs and the subscription. The planner returns tasks as JSON validated in code; the independent ones run in parallel, each in a Git worktree, go through the project's tests and a review from another vendor, and enter the integration one at a time. The model is chosen by role and complexity, and usage is recorded per call, with what the CLI does not report marked as unavailable.

Result

With the three real CLIs, in test repositories: 4 tasks, 10 calls and 0 failures on October 19, 2026, with 18 of 18 tests at delivery; 1.38× parallel speedup with 3 tasks on October 20 (the agents' summed time over wall-clock time, 8 of 8 checks). The per-call log from October 19 showed that 84% of the 1.85 million tokens were context reread from the cache; the cost report now points to the cause, and that data guides the choice of model and effort per task.

Evidence

• Full cycle with the three real CLIs: 4 tasks, 10 calls, 0 failures

  Validation on October 19, 2026 in a test repository: Codex plans, Claude Code implements and Antigravity reviews; four integrations with the tests after each one, and 18 of 18 tests at delivery. One review asked for changes, and the second one approved.

  Measured.

• 1.38× parallel speedup with three tasks

  Live validation on October 20, 2026, with 2 independent tasks and 1 dependent one: 6 real sessions and 8 of 8 checks. The agents' summed time divided by wall-clock time, on a small test project.

  Measured.

• 121 automated tests passing

  Run on October 30, 2026 on the 0.7.1 base: unit and integration tests with real Git, real test commands and simulated agents, with no credentials or quota.

  Measured.

On screen

1Plan2Run3Delivery

Tap outside the image to close it.

Tap outside the image to close it.

Tap outside the image to close it.

How it works

As in a musical score, each task has its own line: it leaves the integration line, goes through the tests and the review, and only then returns to it.

1. Plan

   The planner reads a snapshot of the folder, without .env or keys, and returns tasks as JSON; the code validates the dependencies, and the person approves.

   JSON
2. Copies

   Each ready task gets its own worktree and branch; tasks that share files do not run together.

   Gitup to 4 in parallel
3. Tests

   The implementer edits the files and Orquestra runs the project's tests; if they fail, the output goes back to the implementer.

   npm test
4. Review

   An agent from another vendor reads the diff and the automatic checks, and ends with APPROVED or CHANGES.

5. Integration

   Only the approved task goes in, one at a time, with the tests after each merge.

   merge --no-ff
6. Delivery

   The tests run on the full integration; the person's branch only changes when they open the changes and apply.

{
  "id": "juntar",
  "title": "Juntar as mensagens",
  "dependsOn": ["ola", "tchau"],
  "files": ["juntar.txt"],
  "acceptance": ["juntar.txt existe"]
}

Decisions

Limits

• This page describes the main cycle of the 0.7.1 base, validated live with the three CLIs in test repositories.
• The next step is to store each round, with the model, the effort, the usage and the review's verdict, and use that history to choose the model and effort for the next task and estimate the spend before running.