UK-based independent AI efficiency projectEvidence before claims ยท 2026

Request Boundary: Why a Short Reply Can Follow a Large Input

ONE BOUNDED GPT-6 LUNA AUTH CANARY ยท OBSERVED

Request Boundary: Why a Short Reply Can Follow a Large Input

A long-scroll visual companion to the article. It summarizes the articleโ€™s evidence boundary and method; it does not extend the underlying result.

At a glance

Request Boundary: Why a Short Reply Can Follow a Large InputFour-step visual: VISIBLE TASK; ASSEMBLED REQUEST; PROVIDER USAGE; LIMIT: NO ATTRIBUTION. One bounded run only. The provider total does not attribute tokens to wrappers, tools, history, or any other component.ONE BOUNDED GPT-6 LUNA AUTH CANARY ยท OBSERVED1VISIBLE TASK2ASSEMBLED REQUEST3PROVIDER USAGE4LIMIT: NO ATTRIBUTIONEvidence labels and limits travel with the visual.
Measure the serialized request at the provider boundary. A short visible answer does not reveal the size or composition of the request.

Evidence in scope

  • Input: 13,289 tokens
  • Cached input: 0
  • Output: 10 tokens

Evidence boundary: One bounded run only. The provider total does not attribute tokens to wrappers, tools, history, or any other component.

How to use the diagram

Preserve provider-reported input, cached-input, and output fields separately; bind them to one request and version.

What this visual explains: Measure the serialized request at the provider boundary. A short visible answer does not reveal the size or composition of the request.

What it does not establish

No component-level token split, general cache claim, benchmark, or repeated-workload conclusion is established.

โ† View article ยท Return to source article