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.

planned Specified and not implemented. Named so the omission is visible.

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.

Provenance

defined in
read it on this site · docs/DESIGN.md
implemented in
nothing yet
proved by
no test — which is why this is not marked guaranteed
claim id
runtime-adapters

What would make this guaranteed

0.2 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.