Agent · Available now

Ensemble Agent

Gets several genuinely different approaches on the table and argued out before a single line is written. One focused workflow, with a clear result at the end.

Read docs

How it works

Ensemble Agent turns one task into a decision before it turns it into a diff. It reads your task and invents a set of specialist perspectives to look at it from, writing each one's full brief itself rather than picking from a fixed list, so the perspectives fit this task instead of being generic roles. Each specialist then works on your task at the same time, in its own copy of your repository that it is not allowed to write to. Each one comes back with five to ten distinct approaches, every one with its upsides, its downsides, its risks, and the files it would touch. You choose how many specialists with one flag, anywhere from 3 to 100.

Then it narrows. A selector reads every approach from every specialist and cuts the field in rounds, keeping about a fifth each round, weighing the trade-offs of what it keeps and recording why everything else was dropped. What survives is one approach and a written brief explaining the choice. Only at that point does a single write-enabled agent get your repository and implement it. That final agent is the only one in the whole run permitted to change a file, and the read-only restriction on the others is enforced by the sandbox rather than by asking them nicely.

It decides how to do the work; it does not attack work that is already finished or push an approach you already chose. If one specialist fails or runs past its five-minute bound, that is reported and the run continues, because a partial slate still beats a single opinion. The run stops only when every specialist has failed. The selector's written reasoning, including the rejected approaches, is part of what you keep.

runtime
local
one-time
ensemble
multi-agent
approach-exploration
architecture-decisions
trade-off-analysis
read-only-proposals
parallel-proposals
selection-rounds
decision-records
design-review
blast-radius
anchoring-bias
role-generation
refactor-planning

Agent environment

Pricing

$0.02 per launch

runtime
local
one-time

Ensemble Agent runs several Codex instances on your machine. Each explores the task from a different angle without changing your files; a selector compares their approaches, then one Codex agent implements the selected plan. Codex is the only supported host for this workflow, and your repository contents stay on your machine.

This agent is live today. Install vidbyte-cli, log in with your Vidbyte key, and connect your OpenAI account for Codex. The install prompt below checks your setup and gives you the first command to run.

Run it from your own agent

Copy prompt

Paste this into the agent you already use and it will ask you what you need, then write the exact Ensemble Agent invocation for your job.

You are helping me write the task text for Vidbyte's Ensemble Agent, which invents several specialist perspectives on my task, has each propose 5 to 10 approaches in a read-only sandbox, narrows them in rounds, and then implements exactly o…

Run it from the command line

Every agent starts with the same two setup commands: install vidbyte-cli, then log in with your Vidbyte key. Ensemble Agent also needs an OpenAI key stored for Codex, and then it is one command with a dial for how many specialists to use. Two read-only checks confirm your machine is ready before you launch anything.

bash
pipx install vidbyte-cli
Installs vidbyte-cli from PyPI, the command line every Vidbyte agent is started and tracked from. pipx gives it its own environment and puts the `vidbyte-cli` command on your PATH; without pipx, run `python -m pip install vidbyte-cli` inside an activated virtual environment instead, and read the CLI repository README for the full installation notes. Run `vidbyte-cli --version` afterwards, and if it prints a version number the install worked.
View subcommands
--python
Picks the Python interpreter pipx builds the CLI's environment with, such as `--python python3.12`. vidbyte-cli needs Python 3.11 or newer, so set it when your default Python is older and the install refuses to resolve.
bash
vidbyte-cli login
Stores your Vidbyte API key, which is what identifies you and what every agent's charge is billed against. It reads the key at a hidden prompt, checks it against Vidbyte before saving anything, and then keeps it in your operating system's keyring. Run `vidbyte-cli whoami` afterwards to confirm which account the stored key belongs to.
View subcommands
--with-token
Reads the key from standard input instead of a hidden prompt, which is how you log in from a script or a CI job. Pipe it in from your secret store rather than typing it into the command. There is deliberately no --api-key flag, because anything in the command line leaks into process listings, shell history, and CI logs.
--allow-file-fallback
Approves storing the key in a permission-restricted file when the machine has no operating-system keyring, such as a bare Linux server. Without it, login asks before falling back, or refuses when there is no terminal to ask on. Anything running as your user can read that file, so use it only where a keyring genuinely is not available.
bash
vidbyte-cli provider login openai
Stores the OpenAI key that every Codex fork in the run will use, separately from your Vidbyte key. Every specialist runs on that account, so choose it deliberately. The CLI resolves the key from OPENAI_API_KEY first, then from this stored profile.
View subcommands
--with-token
Reads the OpenAI key from standard input instead of a hidden prompt. Use it in scripts and CI, piping the key from your secret store. The key never has to appear in the command line or your shell history.
--allow-file-fallback
Approves storing the key in a permission-restricted file when no operating-system keyring is available. Without it, the command asks first or refuses when it cannot ask. Anything running as your user can read that file.
bash
vidbyte-cli runtime same-host-ensemble "<your task>"
Runs the whole four-stage sequence on your task in the current working directory: plan the roles, fan out the proposals, narrow to one, and implement it. Everything before the final implementation stage happens in read-only forks. Nothing in your working tree changes until an approach has been chosen.
View subcommands
--roles
Sets how many specialist perspectives the planner invents for this task, from 3 to 100, defaulting to 3. More roles widen the slate the selector has to narrow, which is what you want for a decision that is hard to reverse. Every role runs at the same time in its own fork on your own subscription, so this is the dial that moves your model usage.
--model
Forwards one model choice to every Codex turn and every fork in the run. Set it when you want the comparison between approaches to be like-for-like, or when the default model is not the one you want making an architectural call. Leave it out to use the provider default.
--reasoning-effort
Controls how much thinking each turn does, accepting none, minimal, low, medium, high, or xhigh. Raise it when the task is subtle enough that a fast answer is the wrong answer. Like the model flag, it applies to every turn in the run, so the branches stay comparable.
--idempotency-key
Lets you retry a launch whose outcome you never saw without being charged twice. Reuse the same key and the original admission is recovered rather than a new one purchased. Leave it out and a fresh key is generated for every run.
--host
Names the coding agent that hosts the ensemble, and codex is the only accepted value. Codex is the only host with verified thread forking and a sandbox per fork, which the read-only proposals depend on. The flag keeps scripts explicit and stable as more hosts are added.
bash
vidbyte-cli runtime doctor
Reports which supported coding-agent hosts this machine actually has. Run it before your first ensemble, so a missing Codex shows up as a diagnostic rather than a failed launch. It is read-only and costs nothing.
bash
vidbyte-cli runtime list
Lists the runtimes Vidbyte will admit, with the charge for each read from Vidbyte's catalog rather than hard-coded in the CLI. The same-host-ensemble line is the price you will actually pay. Use it to compare this agent against the others before picking one.

Use cases

Each example names the problem, the setup, the command to run, and the result you should expect.

Why use this agent

A general agent gives you one approach, and it gives it to you immediately. That speed is useful for small, reversible work and harmful for anything else, because the first approach is not chosen; it is the one that came out of the model first, and everything after that is rationalization. You can ask for alternatives, but you are asking the same agent that already anchored on one answer, in the same context. That produces variations on a theme rather than genuinely different framings. This agent gets the alternatives generated in parallel by separate agents that have not seen each other's work, which is the only cheap way to get real variety instead of rephrasing.

The second problem it addresses is that a general agent decides and implements in the same breath, so by the time you see the decision it is already a diff. Reviewing a diff is a bad way to evaluate an approach, because the alternatives are invisible and the thing in front of you has momentum. Here the two phases are separated by design. Proposals are made under a sandbox that physically prevents writes, the narrowing is a written argument with the rejected candidates recorded, and only the winning approach ever touches your working tree. You get to disagree before the code exists rather than after.

The third is that this kind of exploration is normally too much work to be worth it. Getting five colleagues to each write down several approaches with pros, cons, risks, and affected files is a week of meetings, and doing it yourself is an afternoon you will not spend. Here it is one command. That changes which decisions are worth exploring properly: not just the ones important enough to schedule a design review for, but any decision where you suspect the obvious answer is not the best one. The threshold for taking a decision seriously drops, and that is the real product.

Anchoring on the first idea
Proposals are generated independently and in parallel. The slate is not variations on whatever came out first. You are choosing between options rather than reacting to one.
Alternatives that barely differ
The planner writes each specialist's brief from your specific task rather than assigning generic roles. The perspectives differ because the task has genuinely different angles. Nobody is just putting on a different hat.
Decisions arriving as diffs
The proposal phase cannot write to your repository at all. The point at which you can still disagree cheaply comes before any code exists. Disagreement stops being a revert.
Read-only by request only
The restriction is enforced by the sandbox, not requested in a prompt. An agent that decides it should just make the change quickly is not able to. The only writer is the one that runs after the decision.
Unknown blast radius
Every proposal comes back with its pros, cons, risks, and the files it would touch. Blast radius becomes a fact you compare rather than a guess you make afterwards. That is often what separates two approaches that both work.
Rejected options vanishing
The selector records why each dropped candidate was dropped, round by round. That is the part of a design discussion that normally survives only in one person's memory. It is why the same decision gets relitigated three months later.
Exploration too costly to bother
One command replaces the design review you would have had to schedule. That changes which decisions are worth exploring at all. The threshold becomes a minute rather than a meeting.
Serial exploration eating afternoons
The specialists run at the same time rather than one after another. Widening the search costs concurrency rather than hours of waiting. That trade is what makes a high role count practical.
One failure sinking everything
A role that fails or exceeds its five-minute bound is reported, and the run continues with what the others produced. A partial slate still beats a single opinion. The run stops only when every role failed.
No control over search width
The role count is a flag from 3 to 100. A routine decision gets three perspectives and a genuinely hard one gets thirty. Breadth is something you choose rather than something you receive.
Comparisons that are not comparable
The model and reasoning-effort flags are forwarded to every turn and every fork in the run. Two approaches are therefore produced under the same conditions. One branch cannot look better just because it happened to think harder.

When to use it

When the decision is more expensive to get wrong than the exploration is to run.
When you suspect the obvious approach is not the best one.
When the change will be hard to reverse once it is in.
When you want to compare blast radius across approaches before choosing.
When the work is worth a design review but not worth scheduling one.
When you are the only person available to disagree with you.
When your team keeps relitigating a decision nobody wrote the reasoning down for.
When you want to see the rejected options, not just the winner.
When you want options generated before anything is allowed to touch your repository.
When you need the exploration to be genuinely parallel rather than a serial afternoon.
When a single agent has already given you an answer you do not trust.
When you want to widen or narrow how hard the search goes with one number.
When the same problem could reasonably be solved four ways and you cannot rank them yet.
When you are starting a piece of work rather than finishing one.
When the approach you would pick first is the one you trust least.
When you want the decision's reasoning written down before the code exists.
When you want the comparison to be repeatable, with the same model and effort across every branch.

Ensemble Agent

How it works

Agent environment

Run it from your own agent

Copy prompt

Run it from the command line

Use cases

Why use this agent

When to use it

Similar agents

Persistent Agent

Adversarial Team

Stages Agent