Rewind or Fork? Two Ways to Recover a SolonCode Conversation

A coding-agent conversation rarely fails all at once. More often, it drifts.

One incorrect assumption enters the context. The next answer builds on it. A correction adds more text but does not remove the original premise. Before long, the agent is consistently answering the wrong question.

At other times, nothing is wrong. You simply have two plausible approaches—a minimal patch and a structural refactor—and want to explore both without sacrificing the useful conversation that led you there.

Those situations look similar in a chat window, but they require opposite operations:

• Rewind removes recent conversation history so you can redirect one timeline.
• Fork preserves the original conversation and creates another timeline for a different experiment.

SolonCode supports both patterns. The important part is knowing which state you want to keep.

The shortest decision rule

Ask one question:

Is the recent context wrong, or is it valuable enough to preserve?

If it is wrong, rewind it. If it is valuable but you want another path, fork it.

Situation	Best action	What happens to the current route?
Recent messages pushed the agent in the wrong direction	Rewind	Recent conversation history is removed
The current route is valid, but you want to test an alternative	Fork	The original is preserved and a copy can diverge
The latest answer is wrong, but the request is still correct	Re-run	The last request is executed again
The current answer or task stopped before completion	Continue	The current work is extended

This is not merely UI vocabulary. Each action expresses a different intention about history.

Rewind: edit the conversation's recent past

SolonCode provides the built-in command:

/rewind [n]

It removes the most recent n messages from the current conversation context. The default is 1.

For example:

/rewind 3

means: discard the three most recent messages from this conversation, then continue from the earlier context that remains.

The unit matters: it is messages, not an assumed number of user/assistant pairs.

When rewind is useful

Imagine that you ask SolonCode to simplify an authentication module. During the conversation, you accept an assumption that the service is stateless. Two messages later, you discover that it must preserve server-side sessions for an existing client.

Adding another correction may not be enough. The old assumption remains in the conversation and can keep influencing later decisions.

A rewind lets you remove that contaminated tail and replace it with a clearer direction:

/rewind 3

Then:

Keep the existing server-side session contract. Limit the change to token parsing and add regression tests for the legacy client.

You are not asking the model to argue with its own recent history. You are removing that history from the active conversation context.

What rewind does not promise

Rewinding a conversation is not the same as rolling back a repository.

The command concerns conversation messages. Do not treat it as a replacement for:

• git restore, git revert, or resetting a branch;
• undoing a database migration;
• reversing a command already executed in a terminal;
• canceling a request already sent to an external service.

If an earlier agent run changed files, inspect the working tree and use normal version-control practices to decide what should be kept or reverted.

That distinction is essential for coding agents: conversation state and workspace state are related, but they are not the same transaction.

Fork: preserve the route and create another one

SolonCode Web added conversation fork/copy support in v2026.7.9.

Forking is appropriate when the existing conversation is useful. Instead of deleting its recent history, you copy the conversation and let the copy develop in another direction.

Consider a dependency upgrade that can be handled in two ways:

• Route A: make the smallest compatible change;
• Route B: refactor the integration around the new API.

The analysis collected so far—affected modules, tests, compatibility requirements, and constraints—is useful to both routes. Repeating that discovery from an empty chat would waste time and might produce a different baseline.

A fork gives both experiments a common conversational starting point. You can keep the original route intact while directing the copy toward the alternative.

Treat a fork as a conversation experiment

A useful fork has a hypothesis and the same acceptance criteria on both sides.

For example:

Original conversation

Implement the smallest compatible patch. Do not change public interfaces.

Forked conversation

Explore a structural refactor, but preserve behavior. Report every public API change before editing.

Then compare the outcomes using engineering evidence:

• changed files and diff size;
• test results;
• public API impact;
• migration risk;
• maintainability;
• unresolved assumptions.

The fork is valuable because the initial context is shared. The decision should still be based on the resulting code and tests, not on which conversation sounds more confident.

What fork does not imply

A copied conversation should not be confused with an isolated development environment.

The available product documentation supports the conversation-copy behavior. It does not, by itself, establish that each fork receives:

• a separate Git worktree;
• an isolated filesystem;
• a separate container;
• independent long-term memory;
• automatic branch merging.

If two conversations operate on the same project directory, normal workspace coordination still matters. For genuinely parallel code experiments, create explicit Git branches or worktrees and assign each conversation a clear workspace.

Rewind versus fork: rewrite or preserve

The difference can be expressed as a timeline.

Before either operation:

A → B → C → D

If C and D are based on a bad assumption, rewind removes the unwanted tail:

A → B → C → D
        ↓ rewind
A → B → E

There is still one timeline. You changed where it goes.

If A → B → C → D is useful but you want to evaluate another option, fork preserves it:

A → B → C → D
        └→ E → F

Now there are two conversational routes. One is not automatically better; they are two experiments from a related baseline.

This leads to a reliable mental model:

• Rewind is subtraction.
• Fork is preservation plus divergence.

Where Re-run and Continue fit

Rewind and fork become easier to choose when placed beside two other SolonCode actions.

Re-run: keep the request, replace its result

Use Re-run when the latest user request is still correct but its answer is not. You want the agent to execute that request again rather than preserve the old result.

Typical intent:

Same request, another attempt.

Continue: keep the route, add more work

Use Continue when the current direction is correct but incomplete. The agent may have stopped halfway through a refactor, omitted tests, or ended before reporting verification results.

Typical intent:

Same route, keep going.

Rewind: remove misleading recent context

Use Rewind when the problem spans more than one answer or correction. The recent conversation itself has become a liability.

Typical intent:

Forget the recent messages; I want to redirect from an earlier context.

Fork: keep one route and test another

Use Fork when you do not want to destroy the current route. You need an alternative exploration with a comparable starting context.

Typical intent:

Preserve this route and let me try another one.

A practical recovery workflow

Suppose SolonCode is modernizing an order-processing module.

1. Interrupt before repairing history

If the agent is currently running and you can already see it moving in the wrong direction, stop or steer the active run first. Rewind is for conversation history that already exists; it is not the same operation as interrupting a live execution.

2. Inspect both states

Before choosing an action, inspect:

• the last several conversation messages;
• the Git diff or working-tree status;
• commands and tests already run;
• external side effects, if any.

This prevents the common mistake of repairing the chat while forgetting that the workspace has already changed.

3. Choose the smallest state operation

• One bad answer, same request: Re-run.
• Correct route, unfinished work: Continue.
• Several misleading messages: Rewind.
• Two valid approaches worth comparing: Fork.

4. Restate constraints after the operation

Do not continue with a vague “try again.” State the corrected constraint or the fork's hypothesis explicitly.

Good examples:

Preserve all public interfaces. Do not introduce a new cache. Run the existing integration tests before proposing additional changes.

In this alternative route, optimize for maintainability rather than minimum diff size. List migration risks separately.

5. Verify in the repository

Conversation controls help manage reasoning context; tests and version control validate the implementation.

At minimum, review:

git diff --stat
git diff

Then run the project's documented build and test commands. If you used a fork for A/B exploration, apply the same acceptance criteria to both routes.

A compact checklist

Before using Rewind:

• Are recent messages actually harmful to later reasoning?
• How many messages—not turns—should be removed?
• Did earlier runs already modify files or external systems?
• Have you captured any useful findings that would otherwise be lost?

Before using Fork:

• Is the current conversation valuable enough to preserve?
• What exact hypothesis will the copy test?
• Will both routes use the same acceptance criteria?
• Do code experiments need separate Git branches or worktrees?

The bigger lesson

Coding-agent productivity is not only about writing a better next prompt. It is also about controlling which history the next prompt inherits.

Use Rewind when recent history is part of the problem. Use Fork when recent history is an asset worth preserving. Use Re-run for another attempt at the same request, and Continue for more work on the same route.

Once those intentions are separated, conversation recovery stops being trial and error. It becomes a small, explicit state-management decision—and the repository remains the final source of truth.