`takeover_when`: the 90% threshold where a human steps in

Jul 19, 20266 min readBy the Rysh team

Every budget has to answer one question: what happens at 100%? rysh answers it at 90 — with instructions you wrote before you walked away.

Every budget system for autonomous agents eventually has to answer one question, and most never do: what happens at 100%?

The default answers are both failures. Answer one: nothing happens, because there is no ceiling — and the bill finds you later. Answer two: the run is killed mid-thought — the browser mid-form, the article half-typed, the shortlist unsaved — and everything in flight is lost. The second failure is sneakier than the first, because it quietly teaches teams to remove budgets ("the cap keeps eating our work"), which loops you back to failure one.

rysh's answer is a single line of YAML:

budget:
  size: 4b                  # 4 books = 800k tokens, hard ceiling
  watch:
    takeover_when: 90       # at 90% spent, the wrap-up takes the wheel
    takeover_prompt: >
      The budget is used up — stop now. Save what exists, label it
      PARTIAL, report what remains, and exit clean.

At 90% of the budget consumed, the task prompt — the one chasing the goal — is taken off the wheel. The takeover_prompt inherits the reserved 10% as its budget, and its job is explicitly not progress. Its job is to land the plane.

"A human steps in" — let me be precise

I want to be careful with this framing, because agent marketing is drowning in hand-wavy "human in the loop" claims.

takeover_when does not page you. No Slack ping at 3am, no live approval dialog blocking the run (rysh has approval gates for dangerous operations, but that's a different mechanism). The human steps in by proxy, ahead of time: the takeover prompt is your voice, written before you walked away — your judgment about what a safe landing looks like, pre-loaded for the exact moment the run can no longer afford your goal.

And then the human steps in literally, on the other side: the takeover leg's entire purpose is to hand the work back to you in a state you can pick up. Saved artifact. PARTIAL label. A note about what's missing. The run ends at your desk, not at a wall.

Two real examples from recipes I actually run:

# publishing automation — Medium autosaves as you type
takeover_prompt: >
  Stop now. The story should exist as a DRAFT: report the draft URL,
  what remains to be done, and save that status to the results file.
  Do NOT publish a half-written article.

# discovery automation — scouting a candidate shortlist
takeover_prompt: >
  Stop browsing now. Save the shortlist as-is, add a note that it is
  PARTIAL, then print the file path and what to cover next time.

Notice both are domain judgments. "Don't publish half-written work" is not something a generic runtime could know. The threshold is generic; the landing is yours.

Why a percentage, not "detect when it's stuck"

takeover_when takes a number from 10 to 99 (default 90). People sometimes ask why it isn't smarter — why not trigger the wrap-up when the agent is stuck, or looping, or no longer making progress?

Because "90% of the budget is gone" is a fact, and "the agent is stuck" is a research problem. A guardrail you can't predict is a guardrail you can't trust: I know, before the run starts, exactly when the takeover fires and exactly what it has left to spend. Plain-language guardrails — "stop at any login wall," "never retry a payment" — absolutely belong in the system, but they live in the recipe's task prompt, where the agent applies them step by step. The takeover threshold stays dumb, deterministic, and honest.

One more piece of runtime paranoia I've come to appreciate: the reserved share is floored. If you set an aggressive threshold on a small budget and the remaining slice is too thin to land anything, rysh guarantees the takeover leg a minimum — on the order of ~5 minutes, 100 steps, one book — to finish its landing. A wrap-up that can't afford to save the file isn't a wrap-up; it's a slower crash.

After the landing: the loop continues

The takeover leg ends a session, not necessarily the job. In rysh's do/while loop machinery (deep-dive here: https://rysh.ai/blog/loop-engineering), an LLM judge reads the saved output against a written until: goal — a signal, not a proof, so write your goal crisply. If the goal isn't met, the next session starts with a fresh budget, seeded with the PARTIAL artifact the takeover leg just saved.

That's the elegant bit: the takeover prompt and the resume prompt are two halves of one design. The landing instructions say "label it PARTIAL, note what's missing"; the next pass's instructions say "the current shortlist is seeded — find what's missing, merge, save back." Each session hands a clean baton to the next, and you can interject at any point:

##auto web stop scout        # park the whole job
##auto web continue scout    # resume from the checkpoint, budget re-armed
##auto web status            # what pass, what state, what verdict

You are always one command away from the wheel. You're just not required to hold it.

The honest part

rysh runs on Claude — bring your own Anthropic key — and it's self-hostable: recipes, budgets, thresholds, and results are files in your repo, on your infra. And a candid limit: takeover_when guards the failure mode where a run exhausts its budget with work in flight. It does not detect a run that's confidently wrong at 40% — that's what crisp until: goals, approval gates, and reading your agent's output are for. One line of YAML buys you a graceful landing, not absolution.

But "every run ends with a saved, labeled artifact" turns out to be the property that makes walking away boring. Boring was the goal.

rysh is in private beta. If you run unattended agent jobs and want them to land instead of crash, we're onboarding design partners — free access, direct line to the founder: https://rysh.ai/design-partner

Try Rysh

Every pane is a shell and an AI agent — install takes one command.

Get started free →