Every run starts in the composer. It is one writing surface with a row of controls beneath it, and each control settles a question about the run before the run exists: who answers, what the agent may change on its own, and what it is allowed to read.
Describe an outcome
Write the result you want the way you would describe it to a colleague, and let the agent work out the steps. A message that says what should be true when the work is finished leaves room for a plan, and it gives you something to check the result against.
A message that dictates every step is a message you have to correct later. Name the files or areas that matter when you already know them, and say what must not change.
Model and thinking level
The model control names the agent and the model that answers this thread. Open it to choose a different model, a provider account, or a thinking level, and to apply a saved profile, which sets a model and a thinking level together.
The choice is saved with the thread. Reopen the thread tomorrow and the composer is set the way you left it, so a long piece of work does not drift onto a different model between sessions.
Thinking level sits in the same control. A higher level spends more of the run on reasoning before anything is written, which is worth it for a design decision and wasted on a rename.
Permission level
The permission level decides what the agent may do without asking you first. Auto Review answers permission requests for you, except the ones you have denied. Full Access approves everything. Full Access is drawn in the warning colour with a different shield, so the level you are running with is never a guess.
Changing the level while a run is in progress applies to the next turn. The turn that is already running keeps the level it started with, so the control cannot quietly widen a run that is halfway through a change.
In a chat, the permission levels appear once the chat has file access, because a level has nothing to permit until then.
Attachments and file access
Attach Files is in the chat options menu. Files you attach travel with the message and stay with the thread, and the composer lists them above the writing surface so you can remove one before sending.
A model that cannot take attachments says so: the entry is disabled for that model instead of failing after you send.
The File System switch is the boundary for a chat. With it off, the chat answers from what you type and from what you attach. With it on, the chat can work with files and the permission level starts to apply. A project thread always has file access, because the project is the folder it works in.
Chat options
The chat options menu is the plus control at the left of the row. What it holds depends on where you are.
In a chat it carries the File System switch. In a project thread it can carry Independent Audit, which brings in an auditor with the thread's context to audit the work in progress, and Start after, which holds this thread until other threads you name have finished. Attach Files sits at the bottom of the same menu.
Send, queue, or stop
One control on the right does all three, and which one it is follows the state of the work.
When the agent is idle, it sends. When a run is in progress and you have typed something, it queues that message for the next turn. When a run is in progress and the box is empty, it becomes a stop control, and a second press confirms the stop rather than ending a run on a stray click.
Cmd or Ctrl and Enter sends, or queues while a run is in progress. A bare Enter starts a new line, so a long message never leaves early. To put a message into the turn that is already running, use Cmd or Ctrl, Shift, and Enter, which steers it into the live turn and skips the queue entirely.
Queueing is how you keep your own line of thinking while the agent works. Nothing you queue interrupts the run in front of it, and once the turn ends the queued message goes next.
The composer also expands. When a message grows past a few lines, the expand control gives it a taller, wider writing area, and the same control collapses it again.
What the context meter shows
The reading beside the send control is the context this thread is holding. Four cells fill as the window fills, and the colour moves from green to amber to red as the room runs out. Before you send, the reading uses the window of the model you have selected, so changing the model changes the reading.
Open it for the detail. The panel states the context of the latest request as used, available, and window, then the input, output, reasoning, and cache tokens behind it, then the quota for the provider account the thread is running on. When the context is close to full, the same panel offers Compact Work, which summarizes older work to free room, and a send at that point compacts the context first and then sends.
Cost and rate live here too. The panel reports what the thread has spent and which provider windows are close to their limit, and the rate beside the meter reads the generation speed of the turn that is running.
What happens after you send
The message leaves the composer and becomes part of the thread. The run starts in place, beside the conversation you can already read, and the thread keeps your place while you go elsewhere.
When the run finishes, the bell in the header carries the result: a finished run, a question waiting on you, or a specification that needs review. Each entry names the project and the thread it came from, and opening it returns you to the point where the work stopped. You are never required to sit and watch a run to find out how it ended.