Skip to content

Opt-in runtime adapters will clamp read size, output size and fan-out from profile-derived limits

**Planned.** Optional, provider-specific hooks into a worker's runtime that clamp how many lines a single read may return, condense oversized tool output (head, diagnostic lines, tail, with a note that it was truncated), and cap how many sub-workers a session may spawn — with every limit derived from the task's profile rather than a global constant.

declared statusdeclared status: planned Specified and not implemented. Named so the omission is visible.

recorded evidencerecorded evidence: no test Not judged: only a guaranteed claim is held to a recorded run. how evidence is recorded

The one implementation studied was rolled back within days because its limits were global constants rather than task-derived.

What it means

Planned. Optional, provider-specific hooks into a worker's runtime that clamp how many lines a single read may return, condense oversized tool output (head, diagnostic lines, tail, with a note that it was truncated), and cap how many sub-workers a session may spawn — with every limit derived from the task's profile rather than a global constant.

How it works

Nothing is implemented. The design is drawn from a mechanism that ran briefly in the source environment: a read clamp, a semantic output condenser and a sub-worker budget, all real and all deterministic. It was rolled back within days because its limits were fixed constants that applied to every task alike, so the person disabled the governor and nothing was measured at all.

How to see it

There is nothing to run. This page exists so the omission is visible rather than assumed.

What it does not cover

Everything; it is a plan. When it lands it will be opt-in per provider and will never mutate a worker's input silently — drift will be surfaced before it is forced.

Why it exists

Context per session is the largest cost term and the one profiles can only advise on today. Runtime clamps are the first place where profile axes become enforceable rather than projected.

Detail rendered from docs/claims/runtime-adapters.md.

From the statement to the proof

  1. 1 · the public statement

    Opt-in runtime adapters will clamp read size, output size and fan-out from profile-derived limits

    No feature or README responsibility names it; this page is where it is stated.

  2. 2 · the canonical claim

    runtime-adaptersdeclared status: planned in docs/CLAIMS.yaml

    Defined in read it on this site · docs/DESIGN.md

  3. 3 · the implementation

    Nothing implements it yet.

  4. 4 · the test and the scenarios

    No executable evidence linked: the claim names no test, and no use case executes it.

  5. 5 · the recorded runs

    recorded evidence: no test how evidence is recorded

What would make this guaranteed

Profiles become runtime constraints rather than advice PLANNED Shipping the milestone does not promote the claim: it reaches guaranteed when an implementation, a behavioural test and a blocking CI job exist for it.

Searches the titles and descriptions of every page this site publishes.