Cross-Talk

Cross-Talk lets TatsuCode windows on the same machine send messages to each other, whatever model each one runs. A window on Gemini can hand a summary to a window on Claude Code; a local-model window can ask an OpenRouter window to run the tests and report back. The receiving window's model reads the message, acts within that window's own permissions, and replies only if asked.

Nothing leaves the machine. Windows find each other through files under your user profile and talk over loopback with per-window tokens.

Two kinds of cross-talk

TatsuCode has always let models talk to other models inside one window: the main model delegates to Task Agents running on cheaper or more specialised models, hands work to a delegated Claude Agent run, and passes a session from one provider to the next with Cross-Agent Relay. All of that happens in a single window and a single conversation.

Cross-Talk is the second kind: messaging between windows. Each window keeps its own project, session, provider, and permissions, and the two exchange messages rather than sharing a conversation. Use it when two pieces of work belong in separate windows but still need to coordinate, such as a refactor in one project and its consumer in another, or a long-running agent that reports to the window you are watching.

	Inside one window	Between windows (Cross-Talk)
Who talks	The main model and the agents it delegates to	Two main models, each in its own window
Shared state	One conversation, one project, one permission policy	None; only the message crosses
Typical use	Cheap exploration, delegated runs, provider handoff	Coordinating separate projects or sessions
Tool	Task Agents, Claude Agent, Cross-Agent Relay	Peers

What it looks like

Every window has an address. The name is built from the project and the session: tatsucode-core-a1b2c3d4, or the session's custom name if it has one. Rename the session and the address follows.
Sending. Ask the agent to "send the other window a summary of what you changed" and it lists the reachable windows, picks the right one, and sends. The chat shows a Peers: Send card with the target and a receipt.
Receiving. The message renders as a distinct Message from <window> block above the turn it starts, never as something you typed. Reopening the session restores the block in place.
Idle or busy. If the receiving window is idle, the message starts a turn there right away (receipt: started). If it is mid-turn, the message is queued and handed to the running model at its next safe point (receipt: queued).

A Message-from block from another window, followed by the receiving agent reading it and preparing a reply

The Peers tool

Available to the main chat model in every window; loaded automatically, no skill required.

Action	What it does
`list`	Reachable windows with state (idle, busy, unreachable), model, project, and queued count
`send`	Deliver a message to one window. Target by exact name, a unique prefix, or `name#pid` when two windows share a name
`status`	One window's live state
`whoami`	This window's own address

Prompts that work:

List the other TatsuCode windows
Send the unreal-sandbox window a note that the material names changed; list the new names
Ask tatsucode-core-a1b2 to run the test suite and message me the failures

Messages are self-contained: the receiver cannot see the sender's conversation, so the agent puts what the message is about on the first line and includes what the other side needs.

Claude Code windows

A window running Claude Code as its main model has two ways to talk:

Native session messaging for other Claude Code sessions, including a plain claude session in a terminal. See Talking Between Sessions.
Cross-Talk for everything else. Claude Code sees the same Peers tool as tatsu_peers and uses it to reach windows on any other provider.

Both render the same way in the chat, so a message from a Gemini window and a message from another Claude session look alike on the receiving side.

Safety and limits

Loopback only. Each window listens on 127.0.0.1 on a random port. Nothing is exposed on the network.
Per-window tokens. A window's address file under %UserProfile%\.tatsu\peers\ carries a random token that every message to it must present, and the sender must present its own token too, so a window can only speak as itself. Address files are cleaned up when a window exits, or on the next listing if it crashed.
The receiver stays in charge. The message is labelled as coming from another window, not from you, and the receiving model acts only within that window's permission settings. A message cannot grant permissions it does not have.
No runaway loops. Reply chains are capped at eight hops, senders are rate-limited, duplicate deliveries are dropped, and a single message is capped at 20,000 characters.
Same machine, same user profile. Windows under a different Windows account, or on another machine, are not reachable.

Next Steps

Claude Code — native session messaging and the tatsu_peers twin
Permissions and YOLO — what a receiving window is allowed to do
Task Agents — delegating inside one window instead of across windows