Everything you build in Studio starts as a conversation. You describe what you want, an agent works through it, and a test comes out the other end. That conversation is a session, and Studio keeps every one of them.
Most people never think about sessions until the day they need one back. This page is about finding them, reusing them, and the fact that a single test can have several.
A session is not a test
The distinction is worth getting straight early, because the two are easy to confuse.
| A test | The artifact. It belongs to a project, has instructions and generated actions, runs, and passes or fails. |
| A session | The conversation that produced or changed it. What you asked for, what the agent understood, what it tried, and what it told you along the way. |
The test tells you what it does. The session tells you why it does it that way — which is the question you cannot answer from the steps alone, and the one that comes up six weeks later when somebody asks why a test checks a figure nobody recognizes.
The Sessions screen
Sessions in the left sidebar lists every session in the account, newest first. Each row shows the session's title, when it was last active, and the initials of whoever ran it.
| Search sessions | Matches the title. Titles are generated from what you asked for — Boltas Split AC Price Check, Locked Out User Login Verification — so searching for a feature name usually finds the conversation about it. |
| Last Activity | The sort. Recency is the default and is usually what you want. |
| Select | Turns the list into checkboxes and offers Delete and Cancel. That is the whole set — there is nothing to run here, because a session is a record rather than a job. |
| New Session | Starts a fresh conversation, the same as the button at the top of the sidebar. |
The … on a row offers Rename, Delete, Open link in new tab, Copy link address and Copy session title.
Generated titles are good, not perfect, and a list of two thousand sessions is only searchable if the important ones are named the way you would look for them. Renaming the session where you worked out a tricky sign-in flow costs five seconds and saves the next person a morning.
A test can have more than one session
This is the part most people do not discover on their own, and it changes how you work.
Open any test and look at the top of the agent pane on the left. Next to the test name there are two controls:
- + starts a new session on this test — a fresh conversation against the same artifact.
- … opens More actions, which lists every session attached to this test. The one you are in carries a check mark; each has its title and when it last ran, and a trash icon to delete it.
So a test is not tied to the conversation that created it. You can come back a month later, start a clean session, and ask for a change without dragging a thousand lines of old context along with you.
When to start a new session, and when to keep going
| Keep going | You are still on the same problem. The agent's memory of what it just tried is the most useful thing in the room — "that assertion is too loose, tighten it" only makes sense with the previous turn in view. |
| Start a new one | You are changing subject, coming back after a gap, or the conversation has gone round in circles. A long session that has wandered carries every wrong turn in it, and the agent weighs all of it. |
There is a stronger version of this rule when you are checking work rather than building it. A session that built a test is the worst possible place to review it, because everything the agent believes about the application is already in the room. See The Independent Tester Principle: Never Build and Test in the Same Session.
Giving yourself more room
The test editor is three panes, and two of them fold away.
| Hide session | Collapses the agent conversation on the left, leaving the steps and the browser. Right for reading a test rather than changing one. |
| Hide footer | Collapses the evidence tabs at the bottom — Data, Log, Extension, Variables and Components Model. Right when you are editing steps and do not need the evidence. |
Both are toggles, both remember nothing alarming, and both are reversible with the same button. The sidebar collapses too, to an icon-only rail, with Toggle Sidebar at the top.
On a laptop screen, hiding the session pane is the difference between reading a long instruction and squinting at it.
Sessions and credits
A session on its own costs nothing to keep. What consumes credits is work: an agent generating or repairing a test, and a test executing. Keeping two thousand old conversations is free; it is only ever the running that counts. See How Credits Work.
That is an argument for deleting sessions only when they are genuinely noise, not as housekeeping. The old conversation is often the only surviving record of why a test looks the way it does.
Where to go next
- Starting a Session: The Studio Home Screen — where a session begins, and what to put in the prompt box.
- The Independent Tester Principle: Never Build and Test in the Same Session — why the second session matters more than the first.
- History: Every Change and Every Run, Recorded — the other timeline, and where Restore version lives.
- Operating the Steps Pane: Instructions, Actions and Components — the middle pane, once you have given yourself room to see it.
A PDF of this page, for reading offline, printing, or passing to somebody who does not have a Studio account yet.
Sessions: The Conversations Behind Your Tests (PDF, 237 KB)