# Development sessions

> The record of a developer’s work with the model in Buff Code: who needs it, what it consists of, what is recorded and what is not, who sees it, where to look.

Buff Code’s work is **recorded in full on Buff’s side**. Buff Code keeps the record itself: every
message of a session, the reasoning, each tool call and its result go into its own database and, right away,
to Buff; the server that every model request passes through adds the model, tokens and
charge to the turn. The developer does not need to set anything up for this.

The workspace section **“Development sessions”** shows these records: a list of sessions with totals for a
period, each session step by step — with the session timeline, the feed and the action inspector — and the
**“Questions”** tab, where you can ask the model about the records.

_Illustration: A session is named after the first line of the developer’s first message; the owner sees everyone and filters by developer._

## Who needs it

| Who | Why they open the section | Where to start |
| --- | --- | --- |
| **Team lead** | Who on the team works with the model, how many turns and tokens were spent, what it cost — by period, project and developer, without asking around. What the model did in a particular session: which commands it ran, which files it edited, where it went wrong. | [Find a session](/en/docs/buff-code/sessions/list), then [Ask about sessions](/en/docs/buff-code/sessions/ask) |
| **Developer** | Remember what the model did yesterday and why; show a colleague the session with the solution instead of retelling it; ask a question about the record — “what is still open”. | [Read a session](/en/docs/buff-code/sessions/view), [What exactly the agent did](/en/docs/buff-code/sessions/action) |
| **Information security** | What exactly went to the model — verbatim, call by call; who looked at other people’s sessions and who exported them — from the audit log. | [What exactly the agent did](/en/docs/buff-code/sessions/action), [Audit log and Buff Code](/en/docs/buff-code/sessions/audit) |

## Section glossary

The terms below are the same as in the interface; the pages of this section use them without explanation.

| Term | What it is |
| --- | --- |
| **Session** | One Buff Code session of a developer — one record in the workspace. It is named after the first line of the developer’s first message; if the session has no text — “Calls without saved text”. |
| **Turn** | One Buff Code request to the model and its answer. A turn has a model, a status, a duration, tokens by type and the amount charged. The answer to one developer message often takes several turns: the model called a tool, got the result, asked again. |
| **Action** | A tool call together with the result that came back: “Ran `make test`”, “Edited `src/api.py`”, “Searched the handbook”. In the feed — one line under the model’s answer; in the inspector — in full. |
| **Step** | One mark on the session timeline: a developer message or one action. The caption “step 12 of 40” counts exactly these. |
| **Service call** | A turn Buff Code made not for the work but for itself: to come up with a session title, to compact the context. It is recorded like the rest, but hidden in the feed by default. |
| **Session timeline** | The strip under the session header: a mark for each step, coloured by the kind of action, errors in red. A click or the arrow keys take you to a step. |
| **Inspector** | The right-hand column (on a phone — a bottom sheet) with the selected action in full and the “Files” tab. |

## What is recorded

A session is stored in full, in the form Buff Code keeps it:

- **the developer’s words** and the files attached to them;
- **what came from the model**: the answer text, the reasoning, tool calls with arguments and
  the result of each call — the contents of files read, command output, connection answers;
- **who and where**: the developer, the device, the organisation, the project;
- **how much** — for every turn: the model, the answer status, the duration, the tokens — input, output,
  reasoning, cache (read and write) — and how much was charged.

A failed turn (a model refusal, a dropped connection, a refusal due to the balance) is stored too and not charged.
Service calls — the session title, context compaction — are counted and charged on a par with
working ones; compaction is visible in the feed as a service message.

## What is not recorded and what is not shown

**Not recorded** is whatever does not go to the model: files on disk that Buff Code did not
pass to it; terminal commands and their output if they were not given to the model; edits the developer
made by hand. Connection passwords and tokens never appear in a record — they do not leave the connector.

**Neither recorded nor shown**: the system prompt and the tool descriptions that
Buff Code adds to every request, and the parameters of the model request itself. They are not in
the inspector or in the export: the record keeps the developer’s work with the model — what they asked for, what
the model answered and did — not the inner workings of Buff Code.

## Where it is stored and who sees it

Records are stored in Buff, in your organisation’s data, on the same terms as the organisation’s other
materials (see [Security](/en/docs/security)). They are not deleted: when an employee leaves,
their sessions stay with the organisation.

| Who | What they see |
| --- | --- |
| Developer | their own sessions |
| Organisation owner | the sessions of all the organisation’s developers |

A member who opens someone else’s session gets a refusal: “Only the organisation owner sees other people’s
development sessions”. An owner who opens someone else’s session sees the warning “Someone else’s session”:
viewing and exporting are recorded in the [audit log](/en/docs/buff-code/sessions/audit).

## Section map

| Page | About |
| --- | --- |
| [Find a session](/en/docs/buff-code/sessions/list) | Filters by period, developer and project; “Total for the selection”; how a list row reads; “Ask about the selection” |
| [Read a session](/en/docs/buff-code/sessions/view) | The header and metrics; the session timeline; the feed of messages and actions; service calls; “Follow” and “Live”; the phone layout |
| [What exactly the agent did](/en/docs/buff-code/sessions/action) | The inspector: kinds of actions and what each shows; statuses; “Raw call and result”; the “Files” tab |
| [Ask about sessions](/en/docs/buff-code/sessions/ask) | Three ways to ask; what the model gets; how to read the answer; who sees it; usage and the log |
| [Export](/en/docs/buff-code/sessions/export) | Markdown and JSON: what is in the file, an example, what is left out |
| [Audit log and Buff Code](/en/docs/buff-code/sessions/audit) | Which events around Buff Code go into the audit log, with what severity, and which do not |