UK-based independent AI efficiency projectEvidence before claims · 2026

Token Optimisation

AI efficiency · measured
Discuss a diagnostic

WAIT_RESOURCE: What a Provider-Free Resume Test Can—and Cannot—Show

A synthetic fake-adapter sandbox is visually separated from live provider calls and production outcomes; the test validates transitions only.

Written by

Token Optimisation

in

,

Classification: SYNTHETIC. This describes a fake-adapter recovery exercise; it is not a provider benchmark or live job result.

Provider-Free Test BoundarySYNTHETIC · V20 AND V21 SEPARATE. FAKE ADAPTER → TEST INVARIANTS → 0 PROVIDER CALLS → PRODUCTION UNKNOWN. V20 simulated lane/events; V21 six test cases; do not combine versions.SYNTHETIC · V20 AND V21 SEPARATE1FAKE ADAPTER2TEST INVARIANTS30 PROVIDER CALLS4PRODUCTION UNKNOWNV20 simulated lane/events; V21 six test cases; do not combine versions.
SYNTHETIC · V20 AND V21 SEPARATE. V20 simulated lane/events; V21 six test cases; do not combine versions.

View the full infographic → · View this article

WAIT_RESOURCE is useful only if a job can persist what it was doing, wait outside the constrained request and resume without duplicating completed actions. A simulation can test those invariants; it cannot prove that a real service will provide capacity later.

The test question

When a simulated worker receives a resource wait, does the orchestrator record the cause and checkpoint, pause the same job, reconcile the prior attempt, and resume from the last verified boundary when the fake dependency becomes ready?

What was simulated

The KD11 V20 harness represented 1,000 WAIT_RESOURCE lanes and 1,000 WAIT_AUTH lanes. It reported 2,000 synthetic resume events. The adapter made zero provider calls, used zero provider tokens and ran zero production jobs.

Those counts describe simulated transitions only. They do not tell us how long a real provider limit lasts, how many live tasks resume, whether resumed work is useful, or how much human time recovery takes. Do not translate 2,000 simulated resumes into throughput or productivity.

Useful invariants

  • Each wait belongs to the same durable job ID and checkpoint.
  • WAIT_RESOURCE and WAIT_AUTH route to separate handlers.
  • Backoff is bounded and respects provider retry guidance when present.
  • An ambiguous prior attempt is reconciled before another write or model call.
  • Completed stages are not replayed without verifier failure or new evidence.
  • A resumed result stays pending until acceptance checks pass.

Next evidence for a production claim

Instrument an authorised workload with wait start/end, attempt identity, checkpoint hash, retry reason, provider usage, human intervention and verifier outcome. Report denominator, failures and measurement window beside resumed successes. Until those fields exist, production recovery is UNKNOWN.

See the agent rules tool and heartbeat article.

Read the public-safe synthetic harness scope; it does not establish production recovery.

More posts