Projects.

A project keeps an editable workflow together so you can return to it later. Its graph contains the nodes, their settings, and their connections. Running the graph produces results; saving the project keeps the work you can edit and run again.

The working project in an open Studio tab and its last explicit save can be different. Understanding that distinction makes saving, reopening, and working with another session much easier.

#What belongs to a project

Studio keeps more than the arrangement of nodes:

Part	What it keeps
Graph	Nodes, input values, connections, groups, and nested subgraphs
Creative work	Blocks, timeline scenes, storyboards, drawing boards, and other project-specific editing state when used
Context	Project variables and project-specific assistant state
Identity	A project ID, display name, preview when available, and saved-project version

Include conversation starts enabled for the session. You can change it in the name popover for a first save or Save As.... Its current setting controls whether the general Penny conversation goes into explicit saves, including later Save commands in that session. Working autosaves retain conversation state independently of this option. Lab also has project-specific state; it remains a different creation surface from the graph assistant. See Working with Penny and Lab for those workflows.

A project is not a promise that every result will remain available forever, or that every external dependency travels with it. Keep deliverable media separately and check access to the nodes, models, and connected services a workflow needs. Files and results explains how node outputs, the Files library, and downloaded files differ.

#Working autosave, Save, and Save As

Studio keeps working edits locally and, when server draft synchronization is available, syncs a working autosave to the server. That working state can be newer than the named saved project.

Use the graph toolbar's Save Project control when you want an explicit save. A project without a saved copy asks for a name and Save. For an existing saved project, choose Save to update it, or Save As... to name a separate copy and confirm with Save.

#Compare saving choices

This example starts with saved project A and newer working edits.

Keep editing: the working copy of A contains those edits; the last explicit save of A remains at the earlier state. Autosave and server sync can be offline or fail, so check sync status before leaving the work.

Save: the working copy remains project A, and the explicit saved project A is updated with the current work. Saving does not create a different project ID. Wait for the save confirmation.

Save As...: enter a new name and choose Save. The current work becomes a new saved project B, and the current tab switches to B. B has its own project ID. A keeps its earlier explicit save and its working autosave, which may already contain edits made before Save As. Reopening A can resume that autosave.

These are independent examples, not a sequence of clicks. They illustrate the saving model and do not save a real Studio project.

#Keep an alternative

Use Save As... before editing an alternative if you want A's working state to stay unchanged. Renaming a saved project changes its display name; it does not make a separate project. Two projects can have similar names, so names are not a reliable identifier for automation.

Wait for the save confirmation. A local working copy, a synchronized autosave, and a successful explicit save are different assurances. If sync fails or you are offline, keep the tab and its browser data until your work has synced. Saving and recovery covers sync status, backups, and recovery.

#Reopen the right work

Use Browser → Projects to find saved projects. The toolbar's Open Projects list shows projects already open; its Open project button takes you to the same Projects browser. Check the current Personal or team workspace if a project is missing, and use its name, thumbnail, and update time to identify it.

Opening a project that is already open activates its existing tab. When opening a saved project afresh, Studio can resume its available working autosave rather than the last explicit save. If a newer explicit save needs to replace that autosave, Studio asks first and protects the replaced work in a safety copy.

On desktop, switching between open projects keeps their graph and editing state separate. Closing a saved project's tab does not delete its saved project. A temporary project with content but no saved copy is different: Studio warns before closing it. Save work you want to keep before confirming that close.

The phone interface uses its own project menu and can ask before replacing the currently open project. See Finding your way around for its controls.

#Personal and team projects

The selected workspace determines which saved projects you browse and where new saves belong. Team projects follow team membership and role permissions; a viewer cannot save changes to a team project.

Working autosaves are private to the signed-in user. They do not turn a shared saved project into a live collaborative canvas. Save the shared project when you want the saved version to include your changes, and pay attention to notices that another session has saved newer work. See Teams for workspace access and roles.

#A version prevents an unnoticed overwrite

The saved-project version is a concurrency check. It is separate from the working autosave's own synchronization state, and it is not a browsable history of past versions. Backups provide recovery points.

When a save is based on an older saved-project version, the server refuses the stale write rather than silently overwriting newer work.

Both examples begin with your session having read saved-project version 7.

No newer save: the server is still at version 7. A write expecting version 7 can succeed and produces saved-project version 8.

Another session saved: the server has already advanced to version 8. A write still expecting version 7 is rejected. The newer version 8 remains in place; the stale write does not replace it.

For a conflict, re-read the latest project and reconcile before retrying, or keep your work as a separate project. This is a logical example, not a Studio dialog or an actual API response. These versions check concurrency; they are not a history browser.

#Resolve a save conflict

When saving from the graph toolbar, an explicit save conflict opens Project changed elsewhere with Save as new project, Reload latest version, or Cancel. The new-project choice keeps your work separately under a name ending in (local copy). Reloading replaces the open working state with the latest saved version after confirmation and safety-copy protection. Cancel leaves your current edits in place.

If a save from the Open Projects list conflicts, it shows a Project Changed notice asking you to open the project to reconcile it. Open it and use the graph toolbar's save controls to choose how to continue.

Autosave conflicts have their own recovery controls; use Saving and recovery for that flow. Do not keep retrying a stale save without deciding which work should continue.

#For API clients

The public API reads and writes explicit saved projects. Unsaved working state, including your own autosave, is not available through these endpoints. Paths below are relative to /api/v1 and require the appropriate API-key scopes.

Resource	Use it for
GET /projects	List project summaries visible to the API key owner
GET /projects/{id}	Read project details, including the current version
GET /projects/{id}/document	Read the editable document used for graph changes
PUT /projects/{id}/document	Replace the editable graph
PATCH /projects/{id}/document	Apply ordered semantic operations
GET /projects/{id}/graph	Inspect a sanitized graph snapshot and its version

The editable document uses named input maps and from/to connection tuples. It and the inspection snapshot serve different purposes; use the document for supported read/edit/write round trips. API document writes are validated and save an ordinary project that Studio can open.

Store the stable project id. Updates and deletion require the expectedVersion you last read; a conflict means re-read, reconcile, and retry. The list response is paginated with opaque cursors and ordered by most recently updated first. Use the returned cursor without constructing one yourself. Read a project's details, document, or graph for its version; project list summaries do not include it.

Optional externalId, externalUserId, and externalWorkspaceId let your application map and filter projects using its own records. These labels do not create Kaitoi accounts or grant workspace permissions.

If a thumbnail exists, thumbnailUrl is temporary; thumbnailExpiresAt describes its expiry. Store the project ID and request fresh details when you need a current URL. File deletion has a separate reference guard: a public file still used by an active project cannot be deleted. Deletion is also refused when Kaitoi cannot yet confirm that the file is unused.

Continue with Graphs and nodes for the workflow itself, or Work with projects and graph documents for API editing details.