A context setting is not a context test

Why audit the receipts?

A server can accept a large context configuration without demonstrating useful work at that length. I separated configured capacity, an actual request, and a successful result before making another speed claim.

The largest successful coding receipt contained 49,124 prompt tokens and 51,239 total tokens on the older GPTQ INT4 setup. Its configuration was 81,920. The newer HQ512 build was still in progress, so it supplied no new long-context result.

Speed depends on the workload

In a separate fixed-512-output-token, one-GPU sweep, GPTQ without drafting measured 45.3 tokens/s, MTP2 65.7, and MTP3 61.6. The CyanKiwi profile measured 38.9. These figures belong to that sweep; coding-request rates include prefill and varying concurrency.

An INT8 receipt generated 32,337 tokens but failed retrieval on a 7,758-token prompt. Its 260k setting cannot be counted as a successful context test. The 335k AWQ receipt explicitly marked long-context testing false.

The finding

Capacity, decode rate, retrieval and task completion need separate evidence. The useful next run is a fixed retrieval and coding protocol over increasing prompt lengths, with the same output budget and concurrency.

Evidence and publication boundary

This is an edited account of the recorded experiment. The linked archive is private; the methods, aggregate findings and limits are included above. Reference recordings, raw conversations, authentication material and workstation configuration are excluded.

• Source record 1