> ## Documentation Index
> Fetch the complete documentation index at: https://docs.traycer.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Chats

> Use chats, composer controls, child chats, and terminal agents inside a Task.

A **chat** is a coding-agent session inside a Task. The **Chats** panel is where those sessions are listed and organized.

Traycer has two session types in Chats. They serve the same broad purpose: working with a coding agent inside a Task. The difference is the interface and how much can change after the session starts.

| Type               | Interface                                   | Session controls                                                                                                                                                                                                        |
| ------------------ | ------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Chat**           | In-app conversation with composer controls. | Mode, model, permissions, thinking effort, fast mode, attachments, and voice can change turn by turn.                                                                                                                   |
| **Terminal Agent** | Terminal-style coding-agent session.        | Workspace folder or worktree, coding agent, mode, model, thinking effort, and CLI arguments are chosen at launch and stay fixed for that session. Traycer can resume the underlying agent session on its original Host. |

Both types stay inside the Task and appear in the Chats panel. A plain **Terminal** is different: it is a shell session and lives under [Terminals](/panels/terminals). The full distinction is covered in [Terminal Agents VS Terminals](/concepts/terminal-agents-vs-terminals).

## What Chats Keep

Both chats and terminal agents keep:

* conversation history
* the selected coding agent and model for each run
* the mode used for each run
* permission and thinking-effort choices
* artifacts, file changes, tool calls, and follow-up context produced by the agent

Chats also use the composer controls for attachments, voice input, per-turn permission changes, and model changes.

Chats are separate sessions. Changing settings in one chat does not rewrite another chat.

## Chat Composer

The composer is the prompt area in a chat.

| Control                  | What it changes                                                    |
| ------------------------ | ------------------------------------------------------------------ |
| **Mode**                 | Choose **Regular Mode** or **Epic Mode** for the next agent turn.  |
| **Coding agent / model** | Pick the agent path and model used for the next turn.              |
| **Permissions**          | Decide what the agent can do before asking.                        |
| **Thinking effort**      | Choose reasoning depth when the selected model supports it.        |
| **Fast mode**            | Use a faster service tier when the selected chat model offers one. |
| **Attachments**          | Add files, images, or context to the prompt.                       |
| **Voice**                | Dictate a prompt instead of typing.                                |
| **Send / Stop**          | Start the next turn or stop the active one.                        |

Mode, model, permission, thinking effort, and fast-mode changes apply to the next agent turn. They do not rewrite a turn that already started.

## Terminal Agents

A Terminal Agent starts with a fixed launch setup:

* workspace folder or worktree
* coding agent
* model, when supported
* Regular Mode or Epic Mode
* thinking effort, when supported
* terminal-agent CLI arguments, when supplied

After a Terminal Agent starts, those launch choices stay with that session. Traycer stores the upstream coding-agent session id so the Terminal Agent can resume the same agent session on its original Host. Start a new Terminal Agent when you need a different mode, model, worktree, or launch argument set.

Worktree choices are covered in [Worktrees](/concepts/worktrees).

Terminal Agents live in **Chats**, not in **Terminals**, because they are agent sessions. The **Terminals** page is only for plain shell sessions.

Terminal Agents also receive Traycer's agent context: mode instructions, artifact guidance, skills, and agent-to-agent instructions. Claude Code Terminal Agents can participate in agent-to-agent communication today; see [Terminal Agents VS Terminals](/concepts/terminal-agents-vs-terminals) for the support details.

## Chat Permissions

Permissions control how much the agent can do without another approval.

| Permission            | Meaning                                       |
| --------------------- | --------------------------------------------- |
| **Supervised**        | Ask before commands and file changes.         |
| **Auto-accept edits** | Auto-approve edits, ask before other actions. |
| **Full access**       | Allow commands and edits without prompts.     |

Supervised is the safest starting point. Some coding agents expose fewer permission options; those compatibility details live in [Agents & Models](/agents-and-models/coding-agents).

## Thinking Effort And Fast Mode

**Thinking effort** controls the reasoning level for models that support it. The available levels depend on the selected coding agent and model.

**Fast mode** appears only when the selected chat model offers a faster service tier. It is a chat control, not a terminal-agent launch option.

## Attachments And Voice

Attachments add context to the next turn. Use them when the prompt needs a screenshot, file, or specific supporting material.

Voice input turns speech into prompt text. It is useful for longer instructions, quick notes, or hands-free follow-up while reviewing code.

## Regular Mode And Epic Mode

Chats can switch between Regular Mode and Epic Mode as the conversation evolves.

| Mode             | Use it when                                                                                        |
| ---------------- | -------------------------------------------------------------------------------------------------- |
| **Regular Mode** | The next step is direct coding-agent work: explain, inspect, edit, run, or debug.                  |
| **Epic Mode**    | The work needs planning, durable artifacts, tickets, reviews, or more careful intent preservation. |

For the deeper mode model, see [Modes](/concepts/modes).

## Chats Sidebar

The Chats panel contains two kinds of entries:

| Entry              | What it is                             |
| ------------------ | -------------------------------------- |
| **Chat**           | An in-app conversational session.      |
| **Terminal Agent** | A terminal-style coding-agent session. |

Terminal agents live in **Chats**, not in **Terminals**, because they are agent sessions.

## Chat Hierarchy

The Chats panel is a tree, not a flat list.

Top-level chats and terminal agents appear at the root of the panel. When an agent starts another agent, the new chat or terminal agent appears beneath the agent that spawned it. This creates a visible lineage:

```text theme={null}
Chat: feature planning
├─ Terminal Agent: investigate failing tests
│  ├─ Chat: summarize the failure cause
│  └─ Terminal Agent: rerun the focused test
├─ Chat: review proposed fix
└─ Chat: update release notes
```

These nested entries are often the "sub-chats" of the original conversation. They are separate agent sessions, but the tree shows which conversation created them.

The delegation model is covered in [Agent-to-Agent](/concepts/agent-to-agent).

The hierarchy helps answer:

* which agent started which follow-up
* which chats belong to the same branch of work
* where a terminal agent came from
* what context a child conversation is attached to

Chats and terminal agents can also be grouped under artifacts, so an investigation or follow-up can sit beneath the spec, ticket, story, or review it belongs to.

## Parents And Children

In the Chats panel, a parent can be:

* a root Task-level chat
* a terminal agent
* an artifact that the chat is grouped under

A child can be:

* a chat
* a terminal agent

Manual organization is intentionally narrower than agent-spawned lineage. You can group chats under artifacts, but chats are not general-purpose folders for arbitrary items.

## Controls

The panel supports:

* filtering by **All**, **Chats**, or **Terminal Agents**
* sorting by **Last Updated**, **Date Created**, or **Name**
* creating new chats and terminal agents with the `+` action
* renaming and deleting entries from row actions

When a filter is active, Traycer keeps the relevant parent chain visible so a matching child chat or terminal agent does not appear detached from its context.

## Session State

Each chat or terminal agent keeps its own history and active run state. A Chat is flexible turn by turn. A Terminal Agent is fixed after launch because it is running through a terminal-style coding-agent session.