Council
Send one chat turn to a council of models. Several engines answer at once, review each other anonymously, and your chat's own model writes one reply. You can read the whole discussion in the chat.
Some turns deserve more than one opinion. Council sends a single chat turn to several models at once, lets them check each other, then hands you one answer.
Ask a turn to several models
Type /council and it arms your next message. Write the request as you normally would, and instead of one engine replying, several do, at the same time.
It runs in place. No new tab opens and the thread keeps its own model. The council does its work behind that one turn, and the synthesized answer streams into the same conversation as the reply.
Who sits on the council
The members are the local engines on this Mac that are installed and signed in, running under your own subscriptions rather than a hosted catalogue billed by the token. Studio takes them in a fixed order, Claude Code, Codex, Grok, Kimi, Antigravity and OpenCode, and seats the first three that are ready. Each member runs on a model picked for council work on its engine.
Readiness is checked before anyone answers. An engine that is not both installed and authenticated never takes a seat; the next ready engine in that order takes it instead.
Antigravity's own command line approves file writes whatever mode it is started in, so Studio holds an Antigravity member to reading with a hook of its own for that run: any tool call that is not a read is refused, and a hook that fails or times out refuses too. That is what lets Antigravity take a seat and keep the promise in the next section.
Read-only by design
Council is for a decision rather than a change: an architecture call, a tricky trade-off, a design someone wants sanity-checked, a review before you commit to a direction.
So members are not merely asked to leave your files alone. Each one runs a read-only turn that its own engine enforces. It can read the project to ground its answer, but it cannot write a file, change anything by running a command, fetch a web page or call an MCP tool. It never stops to ask you for permission either, so a council turn runs to the end without prompts.
When you want the work actually done, that is what Workflow is for.
They review each other
The members are anonymized, known to each other as Member A, Member B and so on rather than by engine or model. Once everyone has answered, each member reads the others' answers with the names hidden. Every reviewer is shown your original request and a brief of the conversation, so it judges each answer against what you actually asked.
- With three answers, each member ranks the other two by accuracy and insight, with a one-line reason for each.
- With two answers, a ranking would be a list of one, so each member critiques the other instead: what it gets right, and what it gets wrong or leaves out.
Reviewers write in the language of your request, and they cannot reveal or guess who wrote which answer. That anonymity is the point: an answer wins on its merits, not on which model it came from, and a single model's blind spot is less likely to survive contact with the others.
Read the discussion in the chat
What the members said is not hidden behind the reply. The discussion appears in the chat ahead of the answer and opens by default, in the order it happened:
- Answers. What each member said about your request.
- Reviews. How each member judged the others.
Each entry names the engine and the label the other members knew it by, so you can follow who said what even though they could not. Long texts are cut short with a fade and open in full with Show all. While the council runs, each member's state sits next to its name: waiting, answering, reviewing the others, and when a member falls short, that it did not answer, did not review, or did not take part. A click on the header folds the whole discussion away.
The discussion stays on your Mac. The members' texts are not sent to Pathrule's cloud, and the iPhone app shows the council's reply but not the discussion behind it yet.
Your chat model has the final word
The chairman is your thread's own model. It already holds the full conversation and the voice the thread has been speaking in, so it is the one that reads every answer and every review, reconciles the disagreements, keeps what is strongest, and writes a single reply in that voice. It does not paste the members' answers back to you or name them; it synthesizes.
The same context, several readings
Each member starts from the same path-scoped memories, rules and skills for the path you are working in, plus a brief of the conversation so far. So a council is several engines reading the same product knowledge and the same constraints, not several sessions you would have to explain your product to one by one.
When there is no council
A council needs at least two voices. With fewer than two ready engines, or when fewer than two members produce an answer, there is nothing to compare, so your chat model answers the turn on its own, without a discussion. You still get a full reply rather than an error.