Questions people ask

Because you probably pay for more than one, and they are good at different things. Baya lets a task list say “plan with one, build with another” and handles the plumbing.

Tools such as T3 Code focus on interactively controlling agent sessions. Baya focuses on executing a task list from start to finish. Its advantage for that workflow is automation: one command handles planning, model selection, ordering, parallel execution, context handoff, process reuse, and recovery while coordinating the subscriptions and coding agents already on your machine.

Yes, three ways.

A task list picks the model per task, so the light steps run on a cheap model (luna, terra) while the expensive ones are reserved for work that earns them.

Then Baya spawns as few agent processes as it can. Tasks that share a provider, model, permission level and directory go into one process and are worked through in order — a whole layer of independent tasks, or a chain where each step builds on the last. That process reads package.json once, orients itself once, and keeps its context across the tasks, instead of every task paying for that from scratch.

What grouping can’t cover — a task on a different model, or one that needs different permissions — is covered by memory: what earlier tasks found (which commands work, which fail, which files changed) is derived from the providers’ own logs and handed to later tasks, so nobody pays twice to discover the same thing.

You are still spending under subscriptions you already pay for. Both are on by default: --group-size 1 gives every task its own process, --no-memory starts every task blind.

One model reviewing your work has blind spots, and it will rubber-stamp its own kind of mistake. Consensus runs the same review across several provider CLIs in parallel and blind, then a moderator reconciles their findings into a new draft and the loop repeats until nothing blocking is left or the --rounds ceiling hits.

Blind and independent means no model anchors on another. The moderator never picks the answer — it writes the criteria, reconciles each round, and reports only whether the reviewers agree, so you see where the models actually converge versus where one is guessing confidently. Use it when being wrong is expensive: a spec, a diff, or a design question, where a second and third opinion is cheap next to shipping the mistake.

It is not a run: no DAG, no lock, and baya runs / baya resume never see it. Consensus is for reviewing, not developing — in the workspace posture the reviewers run unsupervised with write access to your tree, so commit or stash first. Full detail: wiki-llm/consensus.md.

No. It drives locally installed CLIs under whatever subscription you already have.

Tasks the planner marked read-only run concurrently; anything read-write is serialized by the scheduler. access is about what a task needs permission to do, not what it edits — a task that only runs the test suite is read-write, because a runner that cannot write its cache cannot run.

One Baya runs per directory — a second is refused rather than left to fight over the same files. To run two task lists against one repo, give each its own git worktree.