Sessions, runs and artifacts

You ran a quench study on Tuesday. On Friday someone asks which cooling rate produced the diagram in your slide. You need to find that exact run, not re-derive it. This page describes what Phases keeps, where it keeps it, and how you get back to it.

Sessions#

A session is one conversation. When you send your first message as a signed-in user from the home page, the URL is quietly rewritten to /sessions/<id> — that is the permanent address of the conversation. Inside a workspace the equivalent address is /ws/<slug>/chat/<id>.

The conversation and the simulation record share one identity: the chat and the backend session have the same id, the same owner and the same workspace, and every run created in that conversation inherits the same workspace. That is enforced in the database, not by convention, which is why a run can never end up attached to a conversation you do not own.

Older links keep working. /chat/<id> and /sessions/<id>/activity both redirect to /sessions/<id>.

Signed-in users find past conversations under Recents in the left sidebar, or through the command palette on ⌘K, which searches chats and offers actions such as New chat and Open simulations.

A session created by an external agent over MCP opens as a read-only replay instead of an editable chat: the recorded tool calls are rendered, with log_note entries shown as assistant messages, and there is no composer. To continue that line of work you start a new chat. See Use Phases from an MCP client.

Runs#

Every simulation execution reserves a run version — an integer starting at 1, allocated under a lock on the session so two concurrent requests cannot claim the same number.

Version numbers are never reused. The next version is one more than the highest version ever seen for that session, including versions that were deleted. If you delete run 3, the next run is 4, not 3. A deleted session id is likewise retired permanently. This is deliberate: a run number in a report always refers to one execution, forever.

Run artifacts live under a run-scoped storage prefix, session/<sessionId>/run_NNN, where NNN is the version zero-padded to three digits. Run 3 is run_003. That is the same name the product shows you.

Artifacts#

Artifacts are the files a run produced: plots, animations, the configuration that was executed, and the material cards involved. What each simulator writes is described on its own page — heat treatment, CCT, RSW, V-Gleeble.

The storage bucket is private. Nothing is served by guessing a path. Content comes back one of two ways:

Inline text is served only for .txt, .json, .csv, .k, .log, .yaml, .yml and .md files that are valid UTF-8 and under 2,000,000 bytes. Anything else must be fetched as a URL — the API answers Binary artifacts must be requested as a URL.

One consequence is worth stating plainly: a signed URL issued before you delete a run keeps working until it expires. Deleting the run does not revoke a link somebody already holds.

Getting back to earlier work#

The Simulation Runs sidebar (the header history control, or Runs in the sidebar) lists the runs of the session you are looking at, headed Simulation Runs with the session id truncated beneath it. Each run appears as Run <version> with a file count; expanding it lists the files. When a session contains more than one kind of run, filter chips appear. With no runs yet it reads:

No simulation runs found for this session. Runs will appear here after simulations are executed.

For an ordinary user the file list is filtered to images — .png and .gif — and there is no download button beside each row. Clicking a viewable file opens an inline File Viewer that shows the image or the text and does have a Download file button. Viewable types are the text list above plus .png, .jpg, .jpeg and .gif.

The Results tab of the simulation panel lists stored runs for the active simulator as a table — Run, Date, Grades, BC, t_end, Peak T, Status, Images, Actions — with up to three actions per run: View / Hide (an inline gallery plus the configuration summary, offered only when the run produced at least one image), Reconfigure (loads that run's configuration back into the Configure tab), and a delete button. The status pill is derived from what was stored: complete when the run has at least one image, incomplete when it has files but no images, failed when it has none. There is no download button in this tab. Reuse and share runs walks through the reconfigure loop.

You can also ask, in the conversation:

List the simulation runs in this session.

Show me the results from run 2.

Closing the tab during a long run#

A simulation does not stop because your browser went away. The backend keeps executing and buffers the event stream so a returning client can replay what it missed. When the page reattaches, a banner reads Resuming simulation from background....

That replay buffer has limits you should know about. It is held in the backend process, so it does not survive a restart, and a finished task is kept for replay for 10 minutes. Come back after that and the reconnect endpoint answers No active task for this session — the run's stored artifacts are still there, but the live narration is gone. Open the run in the Results tab or the Runs sidebar instead.

Only one execution runs at a time per session. A second submission while a turn is active is refused before anything executes, with Another chat turn is still running. Wait for it to finish, then retry. Common problems collects the other messages you might meet here.

Deleting#

Deleting a chat from the sidebar asks Are you absolutely sure? and warns that it permanently deletes the chat and removes your data from the servers. Deleting a single run from the Results tab asks Delete <run>? and warns that it permanently deletes all files for that run.

Deletion is refused while work is in flight, with an explicit reason rather than a silent partial cleanup — for example Run is still active; retry after it reaches a terminal state, Session has an active run; retry after it reaches a terminal state, or Run has an active artifact write; retry after it completes. Retry once the run is finished. Interrupted deletions stay resumable rather than leaving orphaned storage behind.

Clear chat history in the user menu deletes everything, confirms with This permanently deletes your chat history. This action cannot be undone., and reports honestly when it could not finish — for example Deleted 12; retained 3 because simulation data is active or unavailable. Retry later.

Sharing a conversation#

Sharing is per conversation, not per run: the … menu on a chat in the sidebar offers Share, and the resulting /share/<id> link carries the same id as the session.

The one thing to take literally is the dialog's own description, Anyone with the URL will be able to view the shared chat. That page has no owner check and no sign-in requirement, and there is no un-share control in the product, so treat sharing as a one-way decision. Reuse and share runs covers the dialog and what the recipient does and does not see.