Projects, memory & recovery
A project is more than its latest playable build. It can also contain requirements, working memory, unfinished files, conversation and records of what happened. The creator keeps these roles distinct so that recovering work does not silently approve it.
Saved source and unfinished work
Your saved game is the version accepted by its save workflow. An unfinished candidate may contain useful changes from a stopped, interrupted or rejected build. Continue, Fix and Finish work from the retained candidate for the same game when its checkpoint is valid.
Continuation requires current context. Unsaved edits, another tab's changes or an unavailable checkpoint can block it. Follow the recovery guidance or export the work for reconciliation. Do not clear browser data as a troubleshooting step before making a backup.
An interrupted provider request may still have incurred a charge. Known usage is retained; a lost response can leave an unknown-charge hold. Starting another attempt does not erase the earlier usage or make a refund claim. See plans and AI costs.
Memory and project records
Use Memory & docs for game rules, pinned reminders and the context supplied to the assistant. Keep these notes concrete: controls, win conditions, art direction and decisions you want preserved. Memory informs future work; it does not grant permissions or replace fresh checks.
The project record is a separate journal of observed requests, checks, reviews, saves and interruptions. It can retain exact versions of reference material the builder read. Recording starts when the feature observes a project; it does not reconstruct unknown earlier activity.
Clearing working memory and deleting record history are separate actions. Read each confirmation. Record deletion can also affect saved drafts and queued messages as disclosed in the interface.
Choose a backup
| Backup | Best for | Important boundary |
|---|---|---|
| Playable game and source ZIP | Playing, distributing or independently editing the game | Does not contain the complete private project journal |
| Private restart record | Resuming with source, memory, journal and retained references | Treat it as private project information |
| Optional account backup | Recovering supported project data through your signed-in account | Requires an explicit upload; it is not automatic device synchronization |
Browser project records remain on this device unless you export or use a supported backup action. Hosted Studio workspaces have separate server-side storage. Neither should be confused with a local credential vault.
Restore a restart record
Export the private restart ZIP from the project-record controls. Extract it and use Open a restart record to select project-record/RESTORE-PROJECT.json. The importer validates the bundle and creates a fresh project, preserving existing projects. It does not restore credentials, a fresh review badge or permission to resume paid work.
The current complete-restore limits are 8 MiB, 1,000 events and 512 retained reference versions; archive checks may reject a bundle earlier. Storage or export errors are reported rather than silently discarding old history to fit. Keep backups outside browser storage and verify an important restore before relying on it.
Need a hand with this workflow? Find help or contact support.