Your coding agents can talk to each other now

The usual way to run several coding agents is to be the wire between them. One session finishes a piece of work, you read what it did, you copy the important part into a second session, and you explain the context again. You are the message bus, and you are the slowest part of the system.

DevThrottle sessions can now talk to each other directly. A session can send another one a message, ask it a question and wait for the answer, or start a new session altogether - on any machine you have connected. You stop being the wire.

Three verbs

Everything here is three commands, available inside any running session without setup:

• Send. One session posts a message into another. It arrives in that session's terminal, stamped with the name of the session that sent it, so the receiving agent knows who is asking.
• Ask. The same thing, but the sender waits for a reply. This is the one that changes how work is split: a session building a feature can ask the session that owns the database what a column means, and carry on with the answer.
• Spawn. A session starts another session. By default a session-initiated spawn becomes a Worker controlled by the session that started it, which is what you want when an agent is breaking a large job into parts. There is a flag to opt out and start a peer instead.

The full list, with the flags, is on sessions talking to sessions.

What it looks like in practice

A concrete shape that works well: one session reads the codebase and writes the plan, then spawns a worker per piece of the plan. Each worker does its piece. When a worker hits something it cannot decide alone - an interface that two pieces share, a naming choice that has to match - it asks the planning session rather than guessing or stopping to wait for you.

The failure mode this removes is the quiet one. An agent that cannot ask a question does not stop and tell you; it picks an answer and keeps going, and you find out three files later. Giving it somewhere to ask is cheaper than reviewing the consequences.

The rails, because a fleet that can message itself can also flood itself

Messaging every session at once is the obvious way to bring a fleet to a halt, so the scope is deliberate:

• A broadcast reaches your own team, meaning the sessions working on the same mission, not every session everywhere.
• Reaching the whole fleet needs a human grant, with a logged reason, and the grant expires after ten minutes.
• Ask has a two-minute default timeout, so a session waiting on a session that is busy does not wait forever.

These are not settings you have to find and turn on. They are how the commands behave.

Watching it rather than reading it

v2.0.6 added the other half: a session that a worker is stuck in can put its hand up, and the session driving the work can list the workers it is driving and see which ones are waiting. Supervision by exception, rather than by tailing eight terminals.

The walkthrough of one handoff, start to finish, is one agent starting another. If you have never split a job across two sessions, start there - it is about ten minutes and it is the clearest way to see why the messaging matters more than the parallelism.