Core concepts
Chats, turns and runs
How work is organised, what a run costs, and how follow-ups build on each other.
Work is organised as chats. A chat holds a sequence of turns, and most turns dispatch a run. Understanding the difference is worth two minutes, because runs are the unit you are billed in.
The three words
| Term | Meaning |
|---|---|
| Chat | One thread of work, listed in the sidebar. It has a title, a status, and everything produced inside it. |
| Turn | One exchange: what you asked, and what came back. Turns are numbered and stacked in the conversation column. |
| Run | The work a turn dispatched: writing a module, editing a project, or verifying something. It is paid from your credit. |
Not every turn is a full run. Asking a question about a module you already generated is answered as a conversational call. It uses credit too, but usually less than a build.
Follow-ups build on what came before
The composer stays at the bottom of a chat after a run finishes. Anything you type there is a follow-up, and the next run starts from the state the last one left:
Add a terminal-count output that pulses high on 255
- From scratch chats re-seed each run from the conversation, so a follow-up rewrites the module with your change applied.
- Project chats edit the files in place, so changes accumulate in the workspace across turns.
Tip
Keep one chat per module. A chat that has drifted across three unrelated blocks gives every follow-up more context to misread; starting fresh is usually cheaper than correcting it.
Where a chat's title comes from
Titles are generated from your first message, and the module name is shown underneath in the sidebar so two counters are told apart without opening either. A chat that opens with a clear description is a chat you can find again a month later; that is the practical argument for writing the first message properly even when you are in a hurry.
Your half-written message is kept
Text you have typed but not sent is saved per chat. Open another thread, check your billing page, come back, and the message is still there. It is cleared once the run it belongs to is dispatched.
While a run is going
A run happens on our side, not in your browser. That has a few consequences worth knowing, because they are the questions people ask first:
- You can close the tab. The run carries on and the result is waiting in the chat when you come back. Nothing is lost by navigating away, and refreshing does not restart anything.
- You can start another chat in the meantime. Runs in different chats are independent, and credit is set aside for each one as it starts, so two runs cannot spend the same last dollar.
- The step indicator is the progress. A long gap on one step is normal, particularly with verification on or inside a project; it is working, not stuck.
- You can stop it. Anything finished so far is kept, and you are charged for what it used rather than what it might have used; see When a run stops early.
Tip
Wait for a run to finish before sending the next message in the same chat. A follow-up is meant to start from what the last run produced, so one sent into a chat that is still working is being written against a state that no longer exists by the time it is read.
Chat statuses
| Status | Meaning |
|---|---|
| in progress | A run is live. The step indicator shows where it is. |
| completed | The last run finished and its files are attached. |
| answered | The last turn was a question rather than a generation. |
| failed | The last run stopped. The chat says on which step. |
Deleting a chat
The ... menu on a chat row offers Delete chat. It removes the chat, its turns and the files generated in it, and it cannot be undone.
- A chat with a run still in progress refuses to delete. Wait for the run to finish or fail, then try again.
- Billing records are not deleted with the chat; your ledger stays complete.
- An uploaded project workspace is detached rather than destroyed, and is cleaned up on its own schedule.