Keeping a session going with /forever

/forever stands a mechabedo agent on a session that never lets it be done. Every finished turn and every halt is continued, including a turn that reports success: the claim is the moment to look again, make it more robust, or take the goal further. There is no report and no exit. You end it.

Its sibling /nohalt is the same loop with an exit: when the session says it finished the task, the agent checks that against what it actually did. A finish that holds gets a closing report and the agent retires; one that does not is sent back with what is missing. Reach for /forever when the job is long enough that a model will declare it done early, and you would rather stop it yourself.

What actually happens

Type the ask and the token on one line:

Bring every page under src/pages/settings onto the house components, one page per turn, and run the type check after each /forever

• The job is created before the prompt is sent, and it carries your sentence as its goal. From then on the agent knows what the session was asked to do independently of what the session itself still remembers. That detail matters below.
• Every finished turn wakes the agent. It runs on mechabedo's Think tier, reads the session (idle minutes, context size, turn count, how the last turn ended, the last few messages) and continues it with what the goal still needs. A turn that stopped short is continued; so is one that says it is finished. If the agent decides to send nothing, mechabedo sends "look again" itself. Each wake is one Think call, which is the cost of the technique.
• A halt is retried. An API error, a failed tool call or a dead agent process gets a message quoting the error and asking the session to pick up where it stopped. A bare /forever has a budget of three halts in a row; a clean turn refills it. A session that spends it is rolled into a fresh one: mechabedo compresses its record into a handover and the work carries on there, as often as it takes. /nohalt does the same three times, then leaves it for you.
• A question card waits for you. A session holding a question or a permission on its card is left alone. Answer it, or chain /answer so mechabedo answers from the goal and what the session has settled, and skips what it cannot know. A question asked in plain text at the end of a turn is not a stop: the session is told to decide on its own judgment and carry on.
• Where you see it. The notice above the prompt box, the Agent tab of the right pane, the agents panel on the launch page, and the rail row's ctx count and stopwatch.
• Ending it. Stop the turn from the composer: it names the agents standing on the session and ends them on one click. Or cancel the job in the Agent tab. Cancelled is gone for good.
• A restart does not end it. mechabedo writes the agent down, so a relaunch or a nightly update brings it back: the session is reopened where it was, on the same footing it had, and sent back to work, since the turn it was waiting on ended with the old process. A session that had halted is recovered instead. If the session cannot be reopened, the agent comes back disabled and its log on the Agent tab says why. /nohalt survives the same way and waits for the session's next turn.

Example 1: one session, through compaction

The sweep above is a good shape for it: small units, one per turn, each verified. The agent reads turns, so a turn that lands one page and its check gives it something honest to judge and continue from.

Sooner or later the context fills. mechabedo does not compact a harness's conversation; each harness does that itself when its window fills, by its own rule. mechabedo's own coding agent is the exception and compacts by a per-model policy under Settings, which roll has to stay under (example 4). What you see is the ctx count in the rail dropping, the Info tab's context falling, and in the transcript the prompt-size-per-turn plot stepping down; the archive flags what the compaction left behind.

The loop survives it, for the reason noted above: the goal is in the job, not in the session. After a compaction the session knows its own summary of the work; the agent still knows the original ask, and its next continue message puts what that ask still needs to the session. What the session loses is its own detail, the dead ends and the things it already tried. Two habits make up for it:

• Ask for the remainder to be written down in the directory, as a plan file or the project's deferred-work notes, so the list survives any compaction.
• Ask for each unit to be verified before the next, so the session's summary is made of landed facts rather than intentions.

Cost is linear in turns: one Think call per finished turn, for as long as it runs. For a sweep of forty pages that is forty wakes.

Example 2: carry it into a fresh session with /fork, by hand

When the session has compacted twice and reads confused, or you simply want a clean context, a fork with a compressed handover starts over without losing the work. The order of the steps matters, and two of them are not obvious.

Be clear about what this is: a manual step, done once. Nothing here makes /forever fork on its own. You end the agent, fork, and arm a plain /forever on the new session, which is then an ordinary /forever until you do it again. The automatic version of this is example 3.

1. End the agent on the old session first. A job is scoped to the session it was aimed at, and a fork is a new session: the old agent would keep continuing the old session beside the new one. Stop the turn and end the agents it names, or cancel the job in the Agent tab. Fork from an idle session, so the record is complete.
2. Fork with a focus level. Type

   /fork detailed

   mechabedo reads the whole record, not only the conversation: prompts, replies, thinking, tool calls with their paths, inputs and clipped outputs, plans, questions and failed turns. Past a budget of roughly forty thousand tokens it thins the record from the middle outwards, keeping how the session started and where it got to. The Think tier writes a handover at the focus level's depth, and it lands in the composer of a new session on the same loadout, with the session's facts above it. Nothing is sent yet, and the old session stays in the rail.
3. Arm on the seeded line. Read the handover, trim it if you like, put one sentence of the goal at the top, append /forever, and send:

   Continue the sweep: every page under src/pages/settings onto the house components, one per turn, type check after each.
   
   <the handover mechabedo wrote>
   
   /forever

   The token comes off the line wherever it is. The job is created on the new session with that text as its goal, and the handover goes as the first prompt.

The token goes on the seeded line, not on the fork

/fork detailed /forever is refused. The fork line takes a harness word, a loadout word, a focus level and a tier, in any order, and answers any other word with the list it does take. Modes are aimed by the line you send after the fork.

Which focus level. The handover is bounded by the level's own written budget:

Level	Handover	Use it when
compress	One paragraph, at most 150 words	Little work remains and the next session mostly needs to know it is done
annotate	At most 300 words, short sections	The order of what happened matters more than the reasoning
detailed	400 to 700 words in headed sections, with the files and checks	The default for carrying a long job across
extensive	900 to 1500 words, dead ends and open questions included	The session tried several things and the next one must not retry them

none, or no focus at all, is the plain fork: the conversation's prompts and replies carried whole, oldest dropped first past the budget, and none of the working. It is the right choice for a short session and the wrong one for the case this page is about.

Which tier. think by default; auto, fast or edge may be named. A focus costs one gateway request, and the prompt line says which tier is reading while it runs. Without a gateway configured, the plain transcript goes instead and the report under the seed says why.

What the fork does not carry. It is a new session: the kit's standing brief is composed fresh for it, which is a feature, and a prompt you stood on the old session with /inject system does not come along. Stand it again.

Example 3: a rolling context window

roll after /forever makes the rolling mechabedo's job. The agent standing on the session watches its context size on every finished turn, and when the policy says so it rolls the session into a fresh one itself: it reads the whole record, has its Think tier write a handover, opens a fresh session on the same loadout and standing prompts, sends the handover as the first prompt with whatever was carried as it was, moves itself onto the fresh session, and detaches the old process. The old session stays in the rail, resumable, and the loop carries on in the new one.

Two shapes:

Sweep the settings pages onto the house components, one page per turn /forever roll

roll alone rolls after every finished turn: the whole record so far is compressed into a handover, and the next turn runs in a fresh session that opens with it. Each turn starts from a short, current account of the work and nothing else, which is the tightest window there is. It costs a Think call and a new harness process per turn, so it suits work that lands one clear unit per turn.

Sweep the settings pages onto the house components, one page per turn /forever roll 400k 0.5

With a threshold and a share, the session works on in place until its context holds 400k tokens, then rolls: the oldest half of the record, by size, is compressed into a handover and the newest half is carried into the fresh session exactly as it was. The window slides rather than resets. The threshold takes 400k, 400000 or 12.5k; the share takes 0.5 or 50%, in either order. A share of 1 compresses everything at the threshold. The share is always the compressed part: to keep the newest 70% verbatim, write 30%.

You do not have to remember any of this. Type /forever and a space, and the / menu offers roll. Take it and the menu offers a threshold, each named for the context window it suits: 80k for a 128k window, 120k for 200k, 400k for 1M. Take one and it offers the share, each row naming both halves, such as Oldest 25% compressed, newest 75% verbatim. The line under the menu reads the whole token as typed. Tab or the arrows take a row, Enter on a row you have not picked sends the line as it stands, and a number typed by hand, 300k or 30%, works the same. After you send, the notice above the box reads the policy back.

What holds it together:

• The goal is the job's. The seed opens with why the session exists, then the work as you typed it, then the handover, then what was carried. The agent is told that a fresh session in its scope is the same work continuing.
• The handover is written at the detailed focus level, the same depth /fork detailed uses, from a record capped near forty thousand tokens and thinned from the middle outwards when it is longer. mechabedo's own handover instructions are the ones the fork uses, so both read the same way.
• Nothing is redone. The working directory is the same and the files are as the record left them; the fresh session is told so.
• The threshold is arithmetic, not a judgment. It reads the context size the harness reports after a turn. A harness that reports none never crosses a threshold, so roll alone is the shape that works everywhere.
• When the handover cannot be written, because no Think model is set or the tier fails, the roll still happens: the compressed part goes as it was, with the reason, rather than the loop stalling.

The Agent tab shows a rolling job with a chip saying when it rolls, and the same switch and two fields are on the agent form under the completion trigger, so a job defined by hand can roll too. Every roll is one rolled line in the job's log, naming the session it opened.

Sessions accumulate

Every roll leaves the old session in the rail, detached, with its conversation. roll after every turn on a forty-turn sweep leaves forty of them. That is by design, since each is the record of work that happened, but it is worth knowing before choosing the shape.

Example 4: the mechabedo coding agent, rolling before it compacts

mechabedo's own coding agent shrinks its context in two ways, and neither knows about the other:

	Compaction	roll
Set in	Settings, mechabedo coding agent, Compaction	The /forever line
Fires	Inside a turn, once the context nears the window, or when the gateway refuses the request as too long	After a finished turn, once the context passes the threshold
Writes	A summary by the session's own model, in the same session	A detailed handover by the Think tier, in a fresh session

Compaction leaves a headroom free below the model's window: a tenth of it, at least 16k and at most 64k, unless Headroom says otherwise. It also never lets the context pass the Ceiling, 250k by default, whatever the window. A roll threshold below that point fires first. The Overview's context bar shows it: on a 256k model the line under it reads Compacts at 230k, keeps 20k, and on a 1M model Compacts at 250k.

When the gateway reports no window, compaction fires at the ceiling. To roll at 400k on a 1M model, raise the ceiling past it. Under Per model, add a row for the model, pick its window from the size chips, here 1M, and set its Ceiling to 0. The window is only a fallback; a window the gateway reports wins. On that model compaction fires at 936k, and

Port the remaining abserver screens, one per turn, type check after each /forever roll 400k 0.5

rolls at 400k. The oldest half becomes a detailed handover, the newest half is carried word for word, and compaction stays behind it as the backstop for a single turn that outgrows the window on its own. On a 128k model the same shape is /forever roll 80k 0.5.

On autonomous drive, every follow-up is a turn

Drive sends the follow-up a session offers as soon as a turn ends, so turns come quickly. A bare roll then costs a Think call and a fresh session for each one, and the window's corner reads ROLLS EVERY TURN. Use a threshold for a session on drive; the corner then reads ROLLS AT 400K.

Which to use when

Situation	Do
A long job in one session, context still comfortable	/forever, with small verified units and a written remainder
Halts keep coming, from rate limits or a flaky tool	/forever: past the budget the work rolls into a fresh session on its own
The session keeps asking you things	/forever /answer
Compacted more than once, or visibly confused	Stop the agent, /fork detailed, arm /forever on the seeded line
The job is long and you want the context to stay small on its own	/forever roll 400k 0.5, or /forever roll for a fresh session every turn
The same on mechabedo's own agent	A threshold below where it compacts (example 4)
You want it to finish on its own and tell you	/nohalt instead of /forever