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.
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:
/fork to start an interactive fork with an optional topic:
/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 |
Report updates (default)
Report updates (default)
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_updatesbefore exit) - MCP tool:
report_updates(message)—messageis required
Exit fork
Exit fork
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)
Save context
Save context
Keeps the fork and makes it your new main session. All
conversation history from the fork carries forward.When the agent calls the
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 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 |
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.
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)
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 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.
The timeout works in two stages:
- 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.
- 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 | Not available |
| Report to main session | Available | Available |
| Blocks conversation | Yes (one at a time) | No (multiple run concurrently) |
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 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 forks
Background fork configuration — isolated mode, model overrides,
tool restrictions, and reporting modes.
Slash commands
All Discord commands, including
/fork and /interrupt.Conversations
How the main conversation works, including reply-to-fork behavior.
Ping budget
How background forks manage notification limits.