Saving and recovery.

Studio keeps your working state, its server autosave, and the named saved project separately. Backups add recovery points alongside those copies. A successful background sync does not by itself update the last explicit save.

#Know which copy holds your work

This example starts with project A saved with a blue-kite image. The current edit uses a coral kite. Each choice starts independently from that situation.

Device-only edit: the example assumes the coral edit was saved locally. The server autosave and named saved project still hold the earlier blue state. Autosave synced: the local state and server autosave contain the coral edit; the named saved project remains blue. Explicit save confirmed: the local state, server autosave, and named saved project all contain the coral edit after the save and synchronization have succeeded.

All three copies refer to project A; these states do not create a second project. The kite images are authored illustrations, not actual files or run results. These controls only explain the saving model and save no work.

The local working copy helps the browser recover interrupted work. The server autosave lets Studio resume working state it has received. An explicit Save updates the named project. None of these should be treated as an unlimited history of every edit.

#Save the named project

On desktop, use Save Project in the graph toolbar. For a first save, enter a name and choose Save. For an existing saved project, choose Save to update it, or Save As... to name a separate project and confirm with Save. Wait for the confirmation rather than assuming the click succeeded.

Save As... switches the current tab to the new project's ID. The source keeps its earlier explicit save and its working autosave, which may already contain your recent edits. Use Save As before changing an alternative if you want the source's working state to stay as it was. See Projects for conversation settings, project identity, and opening workspaces.

#Check saving before leaving

The desktop toolbar's More Options reveals the sync indicator. Open it for notifications about saving. It reports synchronization across open projects, not just the one on screen. Some failure notices do not name a project. Its All changes saved status concerns working synchronization, not a new explicit Save.

• Saving... or Changes pending: work is still being sent or waiting.
• Offline: the server may not have your latest work. Follow the detailed notice about whether the local copy was written.
• Save failed: read the explanation. It distinguishes edits kept on this device from edits that have not been saved anywhere yet.
• Conflict detected or Saving paused: decide which work to keep before expecting synchronization to continue.
• Recovering data...: Studio is recovering interrupted working state.

#If saving fails

Keep the tab and its browser data. Reconnect or resolve the reported problem and wait for acceptance. Clearing site data can remove the only local copy. Do not assume local storage always succeeds: browser storage can be unavailable or full.

For Project too large to autosave, keep the work open and reduce the reported project content, such as old Penny conversations or large node-history outputs, before retrying. Retain any media or history you need before removing it. Offline editing does not make cloud models or connected services work offline.

#Reopen or reload deliberately

Opening a project that is already open activates its tab. Opening it afresh can resume its available working autosave instead of the last explicit save.

If a newer explicit save needs to replace that autosave, Studio asks with Open newer saved version. Deliberately choosing Reload latest saved version also asks first. The replaced working state is protected in a seven-day safety copy; if that protection cannot be saved, replacement stops.

#If reopening fails

If the server copy cannot be loaded and no suitable local copy is available, the project stays in a retryable, non-editable state instead of becoming an empty replacement. Use the visible Retry control. When a newer server version was loaded over this device's unsent edits, a notification can offer Use this device's copy to bring them back as working edits. Read that notice and check saving afterwards; it is not a second named project.

#Find a recovery point

On desktop, open Open Projects and use the project's history icon (tooltip: Restore backup) to open Restore Backup. From Browser → Projects, use the project's Recover from backup action, including when the project cannot open. The phone project list also offers Recover from backup. A closed or unloadable project can be recovered as a separate copy.

Compare each entry's timestamp, node and connection counts, and thumbnail when available. A thumbnail helps identify a point; it is not a complete inventory of the backup. A placeholder can appear when no preview is available.

#Understand backup retention

The list separates Recent backups from Safety copies · kept seven days:

• Studio checks for changed project snapshots about once a minute while you work. Unchanged content is skipped; loading, connectivity, and failed saves can delay a snapshot. This is not a backup after every edit.
• Current retention keeps up to five recent periodic backups per project, rotating older ones as new ones arrive. Periodic entries also expire after 90 days.
• Safety copies are kept separately for seven days. Labels include Before restoring, Before reverting to saved, Conflict: this tab, and Conflict: other session. Check the expiry shown beside the entry.

Safety-copy capacity is limited. If protection cannot be created, the replacement is refused. Review the error and existing copies before retrying. Delete backup requires confirmation and permanently removes that copy. Deleting a backup is not an undoable way to free a slot.

#Open a copy or restore this project

Use Open as copy when you want to inspect older work alongside the original. It saves a separate project named Recovered - … with its own ID and opens it. The original stays unchanged. If the new project is saved but its working autosave is still pending, Studio says so; keep that tab open until it finishes.

Use Restore only when you intend to replace the open project's working state. Studio first protects the current work, then loads the selected backup and attempts to save that restored working state to the server.

#Compare recovery outcomes

The independent examples start with current project A showing the coral kite and an earlier backup showing the blue kite.

Open as copy: A keeps the coral state. A separate Recovered project B contains the blue backup. This example assumes the new project and its autosave have saved successfully.

Restore confirmed: A's working state becomes blue, and its server autosave has accepted that restore. A Before restoring safety copy preserves the coral state for seven days. This does not update A's named explicit save.

Restore pending: A shows the restored blue state on this device, and the coral safety copy has already been protected. The server autosave has not yet accepted the restore. Keep the tab open while saving recovers; this is not confirmed server synchronization.

The images and A/B labels are conceptual examples. These controls do not create, restore, overwrite, or delete a real project.

#Finish a restore

A successful restore offers Undo in its notification. It returns the pre-restore working state and needs to sync like another edit. This short-lived action is separate from the durable safety copy; do not rely on Undo remaining available after leaving the session.

If Studio reports Restore not yet saved, the change is on this device until saving succeeds. Check the sync notice and keep the tab open. After reviewing a recovery, use Save when the named project should include it. A recovered project still needs its referenced files and services; keep deliverable media separately using Files and results.

#Resolve the right kind of conflict

For an autosave conflict, Studio pauses when this tab has edits and another session has saved newer working content. Load latest protects this tab's alternative before loading the server autosave. Keep mine protects the other server autosave before sending this tab's work. If protection or reading fails, that replacement does not proceed. Check sync status after choosing.

#When an explicit save conflicts

An explicit save conflict is different. The graph toolbar's Project changed elsewhere prompt offers Save as new project, Reload latest version, or Cancel. The first saves a separate project whose name ends in (local copy); reloading uses the protected saved-version flow; Cancel leaves your current edits. See Projects for the complete explicit-save workflow.

#Recovery in a team workspace

Working autosaves, backups, and safety copies remain private to the signed-in user, including while editing a team project. Restoring its working autosave does not publish those edits to the team's named saved project. An explicit Save does that, subject to the team's write permissions and version checks.

Open as copy in a team workspace creates a team-owned Recovered project, visible according to that team's permissions, and requires permission to save there. Choose the intended workspace before recovering and keep it selected until the operation finishes. Teams explains ownership and roles.