Sufficiency

How the engine estimates the output tokens a request needs.

A sufficient answer is one that does the job the request asked for. The engine estimates the output tokens such an answer needs, which is neither the shortest possible answer nor the longest the model would write.

The estimate varies widely by request. Figures below are the current engine's output, not measurements of answers that were checked for correctness:

The ceiling Meted applies is derived from this estimate rather than from a fixed limit, so a request the engine reads as large is allocated more than one it reads as small.

What the engine looks at

The Sufficiency Engine considers:

• Task type. A definition, a fact, a refactor and a research report have different shapes.
• Complexity. trivial, simple, moderate, complex, open_ended.
• Requested detail. "briefly", "in detail", "comprehensive", "just the".
• Explicit length constraints. "in 50 words", "in three bullet points", "at least 800 words".
• Number of requested items. "give me 10 ideas" is a hard lower bound.
• Supplied context and code. A summary scales with its source; a patch has to restate part of its input.
• Explanation requirements. "explain why", "step by step", "with examples".
• Conversation state. "tell me more" after a short answer means more; "make it shorter" means less.
• Provider and model capabilities, including hidden reasoning tokens, which bill against the same ceiling.

What it returns

type SufficiencyDecision = {
  taskType: string
  complexity: 'trivial' | 'simple' | 'moderate' | 'complex' | 'open_ended'
  targetOutputTokens: number
  maxOutputTokens: number
  confidence: number
  rationaleCodes: string[]
}

targetOutputTokens is the engine's estimate of the output tokens needed. maxOutputTokens is the ceiling derived from it. See Target vs maximum.

rationaleCodes are stable, machine-readable strings explaining how it got there:

task:coding
complexity:moderate
base_table
detail:detailed
shape:code
tests_requested

meted inspect --json returns them alongside the decision, so you can see which signal is driving an allocation before a single request is sent.

Where it runs

The engine runs in the gateway process. It makes no network calls and no model calls, so a decision costs microseconds of CPU and no tokens. This applies to the Apache-2.0 baseline implementation and to the proprietary one, which loads as a private package or a WASM module.

When the estimate is wrong

Three mechanisms limit the effect of a bad estimate:

1. In observe mode no ceiling is applied, so an estimate cannot truncate an answer.
2. Each decision carries a confidence. A mode skips allocation below its minConfidence and reports low_confidence.
3. An applied ceiling that cuts an answer short is visible as finish_reason: "length". meted eval counts those as under-allocation.