While a simulation is running

An accepted simulation is not a result#

A solver does not fit inside one web request, so Phases does not try. When you press Run Simulation, the tool hands the work to durable execution and comes straight back with a receipt:

HT simulation accepted for durable execution.

followed by a queued or running status and the note "The result will reconnect automatically if this chat reloads."

Read that as a receipt and nothing more. There are no phase fractions, no diagram and no conclusions attached to it, and the agent is prevented from writing any: the acceptance envelope keeps its real non-terminal status precisely so that neither the model nor any adapter can mistake it for a verified result. If a reply ever summarises science from a run that has not finished, that is a bug worth reporting.

What the status banner is telling you#

Underneath the turn that started the run, a banner reports state read from the database rather than guessed from the stream. It has eleven words in its vocabulary, and each one means something specific.

Queued, Running, the two waiting states, Retrying, Stalled and Cancelling are all active: the banner shows a moving progress track and keeps listening. The other four are settled, and the banner stops.

A percentage appears on the right only when there is a real one to show. A queued run reports zero, which is displayed as an indeterminate moving track rather than a literal "0%".

When a run settles you also get a short notification: "Background simulation completed!", "Background simulation cancelled." or "Background simulation expired before completion." A failure reports its own safe message where one exists.

The six stages of a running simulation#

While the status is Running, the banner names the checkpoint the work has reached. For a heat-treatment run the sequence reads:

1. Heat treatment simulation inputs are validated.
2. Heat treatment simulation run is prepared.
3. Heat treatment simulation solver is running.
4. Heat treatment simulation solver finished; preparing results.
5. Heat treatment simulation artifacts are saved; finalizing the result.
6. Heat treatment simulation result is finalized.

The other simulators use the same six checkpoints under their own names. Two things worth knowing: a long flat stretch at stage three is normal, because that is the solver doing the actual physics, and the percentage is progress through those stages, not progress through the solver's own integration. For step-by-step solver numbers, watch the tool card above the banner — it carries the live Step, t = …s, T = … K and dominant-phase readout while the solver integrates.

Stopping a run#

While the run is active the banner carries a Cancel simulation button. Press it and the label becomes Cancellation requested while compute is stopped; the status goes to Cancelling and then settles on Cancelled.

Cancelling is a recorded state transition, not a deletion. The run number that was reserved for the work stays used — run versions are allocated once and never reused — and anything already written before you cancelled stays written. What you do not get is a result: a cancelled run is terminal and must not be read as science.

If the request itself cannot be sent, the banner says so next to the button:

Cancellation could not be requested. Try again.

Closing the tab, reloading, coming back later#

Closing the tab does not stop the run. The solver is on the server, and nothing about the browser's lifetime governs it.

When you come back, the chat finds the workflow the turn started — from the live stream if it is still open, or from the stored message if it is not — and reconnects. While it catches up, the banner adds a line reading "Reconnecting to durable event history…". The events replay in order, the status lands on whatever the database currently says, and, if the work finished while you were away, the result card appears and the agent writes its interpretation of it.

This works because a durable run's history is stored, not buffered in memory: it survives a backend restart and it is not subject to the ten-minute in-process replay window described elsewhere in these docs. That ten-minute limit belongs to the legacy in-process path, which shows a different banner — "Resuming simulation from background…" — and no durable status word.

Two things can still go wrong, and both say so plainly rather than showing an empty chat: "Workflow replay is temporarily unavailable." if the replay service cannot be reached, and "Workflow access is no longer available." if the run is no longer yours to read.

If you come back long after the fact, do not go looking for the stream. Open the run instead — every simulation leaves a numbered run with its artifacts, and that is the durable record. Ask for it in chat:

List my previous runs

Show me the hardness from run 4

See Sessions, runs and artifacts for the run browser and how artifact links are signed.

Every run has a deadline#

Durable does not mean unlimited. Each simulation is submitted with an expiry, and if it has not finished by then the operation becomes Expired, which is terminal.

These are generous relative to what the solvers need; they exist so that a job which has genuinely lost its way cannot sit in the queue forever. An expired operation is never a result, however far it got.

One run at a time in one chat#

A session has an admission budget, and the shipped default admits one active durable workflow per session. Start a second simulation in the same conversation while the first is still active and it is refused rather than run alongside:

HT durable execution could not be accepted. Please retry.

"Please retry" is honest advice in that case: once the first run settles, the same request is admitted. Note that this is a different thing from Queued, which means a run that was admitted and is waiting for the fleet to give it a worker.

There is a second, unrelated lock you may meet first: only one chat turn runs at a time. Submitting while a turn is still in flight returns "Another chat turn is still running. Wait for it to finish, then retry."

If you genuinely need two long runs in parallel, start a second session. If you need many related runs, that is what a simulation study is for — it plans the trials, runs them under one approval, and reports them together.

Some refusals are not about capacity at all and retrying will never help. Those come back as a specific sentence you can act on — an out-of-range weld parameter, or a plate material asked for with the microstructure stage off. Read the sentence rather than pressing Run again.

What a finished run looks like#

A completed durable run does not paste a wall of figures into the chat. It renders a compact result card: an eyebrow naming the simulator, the run label, evidence badges describing what kind of claim this is, a short summary, a grid of headline metrics, and any verified detail sections the run produced.

At the foot of the card are two buttons:

• Open simulator — opens the simulation panel on the Results tab for that simulator, where the plots, the configuration summary and the per-file downloads live.
• Open artifacts — opens the run browser at that run number.

That split is deliberate. The card is the verified summary you can read in the transcript; the figures and the raw files belong to the numbered run, where they stay retrievable long after the conversation has scrolled away.

Driving a long run yourself, over MCP#

A generic MCP host has no banner and no reconnect logic, so it drives the same machinery by hand. Two tools exist for exactly this, and they are MCP-only — they are not available in web chat, which reconnects on its own instead.

A simulation tool returns an operation_id with a non-terminal status. From there:

1. Keep the operation_id. It is stable across disconnects, host timeouts and later conversations.
2. Wait at least the retry_after_seconds the response carries — 10 seconds unless the platform suggests otherwise — then call get_operation_status(operation_id). It never waits for the solver, and it never busy-polls on your behalf. Non-terminal responses repeat the advice: "Wait before calling get_operation_status again; do not busy-poll."
3. When the status is completed — the response also sets next_action to "Call get_operation_result with this operation_id." — call get_operation_result(operation_id).
4. Use only that verified terminal payload for scientific conclusions. It comes back with verified: true and a result checked against the durable workflow, run, tool-call and artifact identities.
5. Call inspect_run with the returned run version when you need fresh signed, user-openable artifact links.

get_operation_result never blocks. Ask for a result that is not ready and it returns the same bounded status projection instead of holding the request open. Two error shapes are worth recognising: {"status": "not_found", "message": "Operation not found."}, and {"status": "unavailable", "message": "Durable operation service is temporarily unavailable.", "retry_after_seconds": 10} — the second is worth retrying, the first is not.

Failed, cancelled and expired are terminal and must never be presented as successful science. The deadlines in the table above apply here exactly as they do in the browser.

The connection setup, the RSW review rules for hosts that cannot render a card, and the rest of the tool surface are in Use Phases from an MCP client and the Tool reference.

If something looks stuck#

Queued, Retrying and Stalled all look like nothing is happening, and none of them is a reason to resubmit — while the first run is still active, a second submission in the same chat is refused anyway. Give it time, then check the run history. Common problems covers the messages you are most likely to meet, and Reporting a problem covers what to send us when the answer is not there.