# Ask about sessions

> Asking the model about development session records: three ways, examples by role, what the model gets, how to read the answer, who sees it, usage and log.

You can ask questions about the records of [development sessions](/en/docs/buff-code/sessions) — just as
[“Ask”](/en/docs/ask) answers about code. The model reads the records rather than retelling from memory,
and backs every claim with a reference to a session and a step. The answer arrives on the section’s
**“Questions”** tab, where it is stored.

## Three ways to ask

| From where | What goes into the question | Dialogue title |
| --- | --- | --- |
| The **“Ask”** button in an open session | this session | “Ask about the session” and the session title |
| The **“Ask about the selection”** button above the list | all sessions under the current filters: period, developer, project | “Ask about the selection”: how many sessions, for what period, whose, in which project |
| **“New question”** on the “Questions” tab | the sessions you tick in the window: search by query, developer, project or machine, a checkbox for each, a “Selected: N” counter | “New question” |

The dialogue has a question field and a hint: ask in your own words what the developer did, why
this solution was chosen, where most of the time and money went, what is still open.
Send it with the **“Ask”** button or **Ctrl+Enter** (⌘+Enter on a Mac). While no session is ticked in “New
question”, the button is unavailable; if no session matches the selection filters, the question is
not created: “No sessions in the selected period”.

_Illustration: The “Questions” tab: what has already been asked about the records and about which sessions; the answer opens next to the list._

_Illustration: The set of sessions for a question is put together by hand: search and checkboxes._

_Illustration: A question from an open session: the dialogue names the session, hints at what to ask and sends the question to the “Questions” tab._

## What to ask

| Who | Examples |
| --- | --- |
| **Manager** | “What did the team do this week and what did it cost?” · “Which tasks took the most tokens?” · “Where did the model go round in circles?” |
| **Team lead** | “What obstacles came up for the newcomer on this project?” · “What is still open in the migration session?” · “Which tests failed and how were they fixed?” |
| **Product manager, analyst** | “What did the developers find out about exporting reports?” · “What questions about deployment did they ask the model?” |
| **Developer** | “Why did I end up choosing this option?” · “Which files did I change the day before yesterday, and why?” |
| **Information security** | “Did files from the `secrets` folder go to the model?” · “Which commands were run with `sudo`?” |

An answer about several sessions is a summary of the records, not of the code: the model sees what was done
and what came of it, but not the current state of the repository.

## What the model gets

- **The list of sessions** in the set — only those. A session that is not in the set is unavailable to the model,
  even if it guesses its identifier.
- Two tools for the records: the session’s **table of contents** (`dev_session_toc`) — who, when, which model,
  totals for tokens and charges, and the **steps**: what the developer said and what was done about it —
  model calls, tools, files, errors, tokens, charges; and **reading a range of
  messages** (`dev_session_read`) — the developer’s words, the model’s answers and reasoning, tool calls
  with arguments, their results, errors. The model first reads the table of contents, then
  only the steps it needs for the answer.
- The organisation’s **knowledge base** — read-only, as in “Ask”.
- **No code.** The sessions ran on the developer’s machine; the project’s repository is not connected in this
  mode. You can ask about the code in the ordinary [“Ask”](/en/docs/ask).

Nothing is written: the question reads the records and changes neither them nor the knowledge base.

## The set is frozen

The set of sessions is fixed when the question is created. New sessions that appear later
do not get into this question, even if they match the same filters — the answer can always be
reproduced from the same records. If you need fresh sessions, ask a new question. A live session
that got into the set is read as it is at the time of the answer: the set is frozen by
sessions, not by turns.

## How to read the answer

The answer is in Markdown, in plain language. The model backs every claim about a session with a reference
of the form **“session `id`, step N (time)”**. This is text, not a link: there is no way to follow it in the interface
— open the session from the list and find the step by its time on the session timeline.

**A step in the answer and a step on the timeline are different things.** In the table of contents the model reads,
a step is one developer message and everything done about it (service calls are not part of
steps). On the timeline a step is every mark: a message or one action. So
“step 3” in the answer is the developer’s third request, not the third mark. The model states money
from the charges in the table of contents. If the records do not contain the answer, the model says so.

The dialogue works as in “Ask”: you see the reasoning, you can attach a file (Word, Excel,
PowerPoint, PDF, text) and ask a follow-up — the field is called **“Follow up on the sessions
question”**. If your choice is not enough for the model, it asks itself — in the list the question is marked
“Awaiting your reply”.

## The list of questions

On the “Questions” tab each question is captioned with what it is about: **“Session: …”** — about one
session; **“N sessions: …”** with titles — about sessions ticked by hand; **“N sessions · from … · login ·
project”** — about a selection. Next to it — the day and the author; a spinner means “Buff is thinking”. On a phone the list and
the open question take the screen in turn; the **“All questions”** button goes back.

## Who sees the question

The question is visible to the **organisation owner** and to whoever **has access to all sessions in the set** — that is,
to a developer if the set contains only their sessions. A thread with other people’s sessions will not open for a member.

A question needs the permission to ask questions (as for “Ask”) and a positive balance.

## Usage and the log

The answer is charged according to the [organisation’s plan](/en/docs/tariffs), like “Ask”; in the billing history
the row leads to the “Questions” tab. Creating a question about sessions goes into the
[audit log](/en/docs/buff-code/sessions/audit) as an `ask.create` event with the list of sessions in
the set.