> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ollim.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Forks
> Branch your conversation to explore tangents, do focused work, or run background tasks — without cluttering your main session.
Forks let you branch your conversation into a separate space.
Explore a tangent, research something, or do focused work — then
choose whether to keep the results, report a summary, or discard
everything. Your main session stays clean either way.
## Overview
ollim-bot has two fork types:
* **Interactive forks** — you enter a branched conversation, talk to
the agent, and choose how to exit. All messages route to the fork
until you end it.
* **Background forks** — the bot runs a task separately and
discards the conversation by default. Results reach you through
notifications or a summary report.
Forks cannot be nested. You can only have one interactive fork at a
time, though background forks run concurrently without blocking
anything.
## Interactive forks
You can start a fork explicitly with `/fork`, or describe what you need — the bot will fork on its own when it makes sense:
```text theme={null}
"I want to research meal prep options without cluttering our main conversation."
```
```text theme={null}
"Let's brainstorm workout routine ideas — fork it so we can go deep."
```
The bot enters a fork, explores the topic with you, and when you're done, you choose whether to keep the context, report a summary, or discard everything.
Use `/fork` to start an interactive fork with an optional topic:
```text theme={null}
/fork topic:research meal prep options
```
If no topic is given, the agent waits for you to lead. The agent can
also start a fork on its own when it decides a tangent needs its own
space.
By default, interactive forks use **adaptive** thinking — the bot
decides whether to think step-by-step based on how complex your
request is, even when the main session has thinking off. You can
change this with [`/config`](/core-usage/slash-commands#config) —
set `thinking.fork` to `off` to disable it, or to a number like
`32000` for a fixed thinking budget.
When a fork starts, the bot sends a purple embed showing the topic
(or a short description like "branched conversation — changes stay
separate from main.") along with three buttons for exiting:
| Button | Style | Action |
| ---------------- | ------- | ------------------------------ |
| **Save Context** | Green | Promotes fork to main session |
| **Report** | Blurple | Reports summary, discards fork |
| **Exit Fork** | Red | Discards fork, returns to main |
### Haiku auto-upgrade
Haiku has a 200k context window — smaller than Sonnet and Opus (1M each). If your main session's context exceeds 200k tokens and you're running haiku, the bot automatically upgrades the fork to sonnet. The fork embed shows a warning — "context exceeds haiku limit — using sonnet" — so you know the model changed. This only applies at fork creation time; if context grows past 200k mid-fork, the model stays as-is.
While inside a fork, all your messages go to the fork instead of
the main session. Pending updates from background tasks are previewed
but not cleared, so the main session still receives them when the
fork ends.
Replying to any message sent by a fork — background or interactive —
starts an interactive fork that resumes from that fork's session.
This lets you pick up where a task left off and continue the
conversation interactively.
Resumed forks receive a **staleness notice** telling the agent how
old the fork is and that `save_context` is unavailable. The agent
is guided to use `report_updates` instead, since the main session
has diverged.
If the fork session has expired (past the 7-day TTL), the bot tells
you with a small note — "this session has expired — starting fresh
with quoted context" — and falls back to quoting the message content
instead. If you reply to a fork message while already inside an
interactive fork, the reply is added as context to the current fork
rather than opening a new one, and you see a note confirming this.
## Exit strategies
Every interactive fork ends with one of three actions — **report updates**
is the default. You can trigger them via the buttons on the fork embed,
or the agent can call the corresponding tools directly. When the fork
ends, the exit embed title reflects what happened:
| Exit action | Embed title |
| -------------- | --------------------------- |
| Save | Fork Ended — saved to main |
| Report | Fork Ended — summary queued |
| Exit / Discard | Fork Ended — discarded |
Saves a short summary and discards the fork. The summary is
included in the next main-session message, so you get the
findings without the full conversation history.
* **Button**: Report (agent is prompted to call
`report_updates` before exit)
* **MCP tool**: `report_updates(message)` — `message` is
required
Clean discard. The fork is disconnected and the main session
resumes as if the fork never happened. No context is preserved.
* **Button**: Exit Fork
* **MCP tool**: `exit_fork` (no parameters)
Keeps the fork and makes it your new main session. All
conversation history from the fork carries forward.
When the agent calls the `save_context` tool, it sends a yellow
confirmation embed instead of saving immediately. The embed has
three buttons:
| Button | Action |
| ---------------------------- | ---------------------------------------- |
| **Confirm** (green) | Promotes the fork to the main session |
| **Report Instead** (blurple) | Switches to report mode |
| **Dismiss** (grey) | Deletes the embed and continues the fork |
The save only happens when you click **Confirm**. This prevents
unintended saves when the agent calls the tool proactively.
The **Save Context** button on the fork enter embed — the purple
one at the top of every fork — still saves directly without a
confirmation step.
`save_context` is blocked in three situations:
* **Main session has diverged** — the main session received new
messages after the fork was created, so promoting would discard
that history.
* **New background updates arrived** — background forks appended
updates after the fork was created, so promoting would lose them.
* **Resumed fork** — the fork was resumed from a prior background
session (via reply or button), so the main session has already
moved on.
In all three cases the agent is guided to use `report_updates`
instead.
If the save fails for other reasons (e.g., the fork session was
already disconnected), the exit embed reflects the actual outcome —
"fork discarded (no session to save)" — rather than falsely
reporting success.
Use only when the main session needs the decisions going forward.
Most forks don't qualify — unnecessary saves clutter the main
session's memory.
* **Button**: Save Context (direct save via fork enter embed)
* **MCP tool**: `save_context` (no parameters — sends confirmation
embed)
Use **report** (the default) for lightweight findings. Use **exit**
for throwaway exploration. Use **save** only when the fork produced
context worth keeping going forward — plans, research results, or
configuration changes.
The bot will never call `report_updates`, `save_context`, or `exit_fork`
on its own during an interactive fork — it waits for you to explicitly
ask to wrap up, save, or leave. Your fork stays open until you decide
to end it (or the [idle timeout](#idle-timeout) fires).
Exit tools also require at least one user turn before they can be
called. The initial topic prompt counts as turn 0 — once you send
your first reply, `exit_fork` and `report_updates` become available.
This prevents the agent from immediately exiting before you've had a
chance to interact.
## Idle timeout
Interactive forks have an idle timeout to prevent abandoned forks
from blocking normal conversation. The default is 10 minutes —
configurable via [`/config fork_idle_timeout`](/core-usage/slash-commands#config).
The timeout works in two stages:
1. **First timeout** — after the configured idle period, the bot
sends a visible note ("fork idle — checking in...") and then
prompts the agent to decide on an exit strategy. It may choose
to report, exit, or save.
2. **Second timeout** — if another idle period passes
with no activity, the agent receives a stronger prompt to
exit. The agent always decides the final exit strategy;
there is no forced auto-exit.
## Background forks
Background forks run routines and reminders in separate
conversations that are discarded when done. They differ from
interactive forks in several ways:
| Aspect | Interactive | Background |
| ---------------------- | -------------------------------------------------- | --------------------------------------------------- |
| Started by | You (`/fork`) or the agent | Scheduler (routines/reminders) or external triggers |
| Output | Streamed to Discord | Discarded (agent notifies or reports) |
| Timeout | Idle timeout (`fork_idle_timeout`, default 10 min) | Hard timeout (`bg_fork_timeout`, default 30 min) |
| Permission mode | Inherits from main session | Always `default` — never inherits |
| Save context | [Conditional](#exit-strategies) | Not available |
| Report to main session | Available | Available |
| Blocks conversation | Yes (one at a time) | No (multiple run concurrently) |
When you're mid-conversation at the time a background fork starts,
the fork runs in quiet mode — non-critical notifications are blocked,
and the agent reports findings to the main session instead.
For full background fork configuration (isolated mode, model
overrides, tool restrictions, reporting modes), see
[Background forks](/scheduling/background-forks).
## Pending updates
Pending updates are the bridge between forks and the main session —
when a fork reports its findings, the summary is included at the start
of your next main session message. Updates are capped at **10 entries**
to keep things manageable. When the cap is exceeded, the oldest entries
are dropped and the bot notes how many were omitted. See
[Context flow](/architecture/context-flow#pending-updates) for the full
pending updates cycle.
When pending updates are included in the main session, the bot sends
a visible note — "catching up on background activity..." — so you know
context from background tasks is being included.
## Next steps
Background fork configuration — isolated mode, model overrides,
tool restrictions, and reporting modes.
All Discord commands, including `/fork` and `/interrupt`.
How the main conversation works, including reply-to-fork behavior.
How background forks manage notification limits.