# Saving and recovery > Save deliberately, read autosave status, reopen the right work, and recover a backup without confusing a local restore with a successful server save. Source: https://kaitoi.io/docs/studio/saving-and-recovery/ Section: Kaitoi Studio / Projects, files and teams Written for: Anyone saving, reopening, or recovering a Studio project. Last reviewed: 2026-10-24 --- 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. *Figure: Compare a device-only edit, a synchronized working autosave, and a confirmed explicit save.* 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](/docs/concepts/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. *Figure: Compare a separate recovered project with a protected in-place restore, including a restore awaiting server synchronization.* ## 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](/docs/studio/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](/docs/concepts/projects/#resolve-a-save-conflict) 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](/docs/studio/teams/) explains ownership and roles.