Forking

What is Forking?

Forking creates a complete, independent copy of your current app - including its entire codebase, database schema, and a summarized version of the chat history up to the fork point. The forked app runs as a separate project with its own build pipeline, database, and published app.

Use forking when you want to:

Experiment with a major architectural change without risking your production app
Create a variant of an app for a different audience or use case
Preserve a stable snapshot before attempting risky refactors

Info

Forking is different from rollback. Rollback rewinds your current app to an earlier state; forking creates a new app that diverges from the original.

How to Fork an App

Open the Fork button

In the chat input bar (web only), click the Fork button to begin the forking process. This opens the Configure New Chat dialog.

Select Fork

Confirm your fork settings in the Configure New Chat dialog. The platform will duplicate the app state - code and cloned volume (including data) - into a new project, with a summarized (editable) chat history.

Name the fork

Give your fork a descriptive name (e.g.,

MyApp - Experimental Redesign

) so you can distinguish it from the original.

Continue building

The forked app appears in your workspace as a standalone project. Chat, build, and publish independently. Changes to the fork do not affect the original app, and vice versa.

Tip

Fork before starting a risky change. If the experiment succeeds, you can continue with the fork; if it fails, simply delete the fork and return to the original.

What Gets Copied

When you fork an app, Emergent duplicates:

Codebase: All files, dependencies, and configuration at the moment of the fork.
Database schema and data: The cloned volume includes code and data at the moment of the fork.
Chat summary: The conversation up to the fork point is condensed into an editable Chat Summary, so the agent retains context about why the code exists.
Build configuration: Publishing settings and integrations.

Warning

Secrets and API keys are not copied for security reasons. You must re-add any required secrets (database URLs, third-party API keys) in the forked app's settings before publishing.

When to Fork vs. Rollback

Scenario	Use
Undo a recent bad change	Rollback
Preserve the current app and try a big experiment	Fork
Create a variant for a different customer or region	Fork
Recover from multiple bad changes over time	Rollback to a known-good state, then fork if you want to try a different approach in parallel

Managing Forked Apps

Forked apps consume credits independently. Each fork:

Runs its own build jobs and incurs credit costs for agent work and published versions.
Maintains a separate database instance.
Appears in your workspace alongside the original.

Note

Delete forks you no longer need to avoid unnecessary credit usage and workspace clutter. Deleting a fork does not affect the original app.

Context Limits

Every chat - including the history in a forked app - operates within a context window: the maximum number of tokens (roughly words and code characters) the AI agent can "see" at once. Emergent uses models with large context windows, but even these have limits.

How to Work Within Context Limits

Scope tasks narrowly: Instead of "refactor the entire app," ask for one feature or module at a time.
Use multiple smaller projects: If your app grows very large, consider splitting it into microservices or separate Emergent projects that communicate via APIs.
Fork strategically: Forking resets the future chat (you start fresh after the fork), but the agent still carries the summarized pre-fork history in the forked app's context. If context is tight, fork early rather than late.

Info

When you approach context limits, Emergent's Infinite Chat system (described below) automatically compacts older messages to keep the conversation going.

Infinite Chat (Auto Context Compaction)

Emergent's Infinite Chat feature ensures long conversations never hit a hard wall. As your chat history grows, the platform automatically condenses older messages to free up space for new work.

How It Works

Squash at ~70% capacity

When the chat reaches approximately 70% of the context window, Emergent squashes older messages: it combines consecutive user-assistant exchanges into summary blocks that preserve key decisions and code changes but remove redundant back-and-forth.

Auto-compact at ~82.5% capacity

At roughly 82.5% capacity, the system performs a deeper compaction: it condenses multiple squashed blocks into high-level summaries, retaining architectural decisions and major feature descriptions while discarding fine-grained edits.

Truncation near 275K tokens

If the chat approaches ~275,000 tokens (the effective hard limit), Emergent truncates the oldest compacted summaries. Critical information - recent changes, active feature requests, and the current codebase state - always remain.

Tip

You don't need to do anything to enable Infinite Chat. It runs automatically in the background, and you'll see a brief notification in the chat when compaction occurs.

What This Means for You

Long-lived projects work smoothly: You can chat for weeks or months without manually restarting or losing context.
Fork preserves pre-fork context: A forked app inherits the summarized history up to the fork point, so the agent still "remembers" why the original code exists - but the fork's future chat starts fresh, giving you more headroom.
Older details may fade: After multiple compaction cycles, very early conversation details (e.g., initial brainstorming) may be summarized heavily. Keep important architectural notes in your codebase comments or README if you need them long-term.