Chat Coordination and Cross-Device Messaging

Chats are not isolated from one another. One chat can look at another, assign it work, and wait for it to finish — and it can do this across computers. This capability is on by default.

Mentioning a chat in the input box

Type @ to bring up the mention menu. The first level lists sub-agents, enabled plugins, devices on the same account, friends, and recent chats directly (up to eight entries, filtered as you type), plus rows for the "File", "Folder", and "Tabs" categories — projects contain too many paths to list inline, so they are tucked into categories that search based on what you type only after you open them (the search uses the engine's file index and respects gitignore).

Pick a chat and a chat chip appears in the input box showing its title. This chip is not just a label — when the message is sent, Klaus knows "which chat you are talking about" and gets a hint about how to act on it (read it, or send it a message). So for something like "go see how far that chat called so-and-so has gotten", you do not need to copy a session ID.

Mentioning a device works the same way: pick a computer on the same account and you get a device chip, used to say "this message should go to a session on that machine". Device names can be changed on the desktop; see Devices and Access Management.

Mentioning a friend instead sends the message as a task to another Klaus account, which runs it on their own computer after they approve it. That is a separate mechanism; see Friends.

What it can do

• See: list chats on this computer (and other computers on the same account), list archived chats, and read the most recent turns of a given chat. Reading does not open or wake that chat.
• Wait: watch one or several chats and wait for them to finish or to need your input — far cheaper than refreshing them yourself over and over.
• Say: send a message to another chat. The message shows up there as a user message, and the recipient can see that it came from you.
• Create and delegate: start a new chat, fork one from the current chat, or change a chat's title / pin / archive state. Creating a new chat starts its first turn immediately.
• Cross-device: computers signed in to the same Klaus account can discover each other, read each other, and message each other. Each listed machine carries an online / reconnecting / offline status. Remote computers accept reading and messaging only; creating chats, forking, and changing metadata still happen locally.

What the recipient sees

A message sent from another chat renders at the recipient as an ordinary user bubble, with a line above it marking its source: "Sent by Klaus from 'some chat'", or "Sent by a session on some device" when it came across computers. So it never pretends to be something you typed yourself.

If the message arrives while that chat is running, it is folded into the current turn (the model sees it immediately); if it arrives while the chat is idle, it starts a new turn. Both count as normal delivery.

Boundaries

• Acting on another chat (sending a message, creating a chat, changing its state) always requires per-action approval — it is not "approve once, do anything later". This is more reliable than a single master switch: a switch can be talked into being turned on by one sentence and then forgotten, whereas asking every time means you nod each time.
• To cut chats off from each other completely, turn off thread_tools.enabled in the engine configuration; the whole toolset and the related system-prompt sections disappear starting with the next chat.
• Content coming from another chat counts as untrusted data: it can be relayed and analyzed, but any "instructions" written inside that text will not be executed as if they were yours.