NEP-0019
The workflow token budget — the portable cap leaves the agent verb
Draft · Standards Track · opened 2026-07-30 · 574 words
NEP-0019 · The workflow token budget — the portable cap leaves the agent verb #
- NEP: 0019
- Title: Generalize the one normative in-language cap (
max_tokens_total) from theagent:verb to the workflow, in the only unit that survives the freeze - Author: Thibaut Melen (SuperNovae Studio)
- Status: Draft
- Type: Standards Track
- Created: 2026-07-30
Abstract #
Today the language carries exactly one normative spend cap:
agent.max_tokens_total (02 §agent) — and it is
confined to one verb of four. This NEP proposes the workflow-level twin:
a declared, statically-checkable token budget the whole run must fit
inside, refusable at check when the static ceiling already exceeds it.
Tokens, never currency: a dollar cap in a durable file rots with
every price change and is meaningless on a local provider, while a token
cap is portable across providers, hardware and years — money stays what
it already is in the engine, a projection of tokens through the
versioned pricing snapshot the trace pins (NEP-0017). This closes the
gap 08 §H7 names (« reading IS
in-language · enforcement is NOT ») in the one unit that deserves to be
normative — the deferred budget: max_cost_usd block stays deferred,
and stays denominated in the wrong unit.
Motivation #
- The product promise is a bounded run; the standard promises
nothing.
nika checkrenders cost floors and ceilings, but a third-party engine can claim conformance without counting anything. The audit-before-run story deserves at least one normative, verifiable cap at the workflow boundary. - The right unit already won, locally.
max_tokens_totalis normative today — but only insideagent:. Aninfer:-only workflow, the majority shape, has no in-language spend bound at all. - The resource doctrine says the dimensionless invariant must
lead (the resource-algebra ratification, 2026-07-28): tokens
compose additively under both
;and‖, need no exchange rate, and are the denominator money and energy are projected from.
Specification (sketch — the Discussion shapes the final grammar) #
- A workflow-level declaration, e.g. under the existing
policy:surface (policy.limits.max_tokens_total: <integer>), judged HARD at check: if the static token ceiling of the plan (the same arithmetic the COST rung already performs ·Σ max_tokens × max_attemptsper task, iterations counted) provably exceeds the budget, check refuses with a taught error; otherwise the run enforces it cumulatively and a breach terminates with the budget error code. - UNBOUNDED stays honest: a plan whose ceiling cannot be bounded statically (dynamic fan-out) is not refused for the budget alone — the check names the unbounded contributor, and the runtime cap still binds (defense in depth, the NEP-0003 shape).
agent.max_tokens_totalis unchanged and nests: the verb cap bounds its task, the workflow cap bounds the sum (limits MEET · budgets escrow — the composition ruling).- Error family: the existing budget namespace; exact codes assigned at Accepted.
Compatibility #
Purely additive. No existing workflow changes meaning; absence of the
field means today's behavior. The deferred budget: block of
08 §Cost tracking annotations is
superseded-in-direction by this token-denominated form if accepted —
the currency-denominated cap stays out of the language.
Open questions (for Discussion) #
- Home:
policy.limits(judged, closed vocabulary today:max_tasks) vs a sibling — the one-obvious-way call. - Does the cap cover
infer+agentonly, or also tokenized tool surfaces (nika:jqis free; MCP tools are not tokens)? - Conformance: one fixture pair minimum (a provable over-budget refusal · a boundary pass), runtime fixtures for the cumulative breach.