UK-based independent AI efficiency projectEvidence before claims · 2026

Token Optimisation

AI efficiency · measured
Discuss a diagnostic

WAIT_AUTH: Separate Authentication Recovery from Resource Waiting

Authentication and resource waits branch to separate handlers and rejoin at checkpoint reconciliation; callback and browser errors remain separate components.

Written by

Token Optimisation

in

,

Evidence labels: OBSERVED redacted OpenCode logs and a separate SYNTHETIC fake-adapter harness. Human recovery time and production resume outcomes are UNKNOWN.

Two Wait Classes, Two PathsOBSERVED AND SYNTHETIC SCOPES SEPARATE. CLASSIFY WAIT → RESOURCE PATH → AUTH PATH → RECONCILE. No live accepted-resume or human reauthentication-time result.OBSERVED AND SYNTHETIC SCOPES SEPARATE1CLASSIFY WAIT2RESOURCE PATH3AUTH PATH4RECONCILENo live accepted-resume or human reauthentication-time result.
OBSERVED AND SYNTHETIC SCOPES SEPARATE. No live accepted-resume or human reauthentication-time result.

View the full infographic → · View this article

WAIT_AUTH and WAIT_RESOURCE are different operating conditions. The first means credentials or authority need attention; the second means a provider or resource is temporarily unavailable. Treating both as a generic retry can cause loops, repeated failures or lost job state.

What the observed diagnostic established

A redacted OpenCode diagnosis identified four authentication-invalidated records across two sessions and 383.69 seconds between the first logged failure and auth-store refresh. No shared backend restart was observed. Later stream events appeared in one session but not the other, and an accepted job outcome was not proven. The plan-change relationship was user-reported; causality remains unknown.

Keep the recovery path separate

  1. Persist the task checkpoint and record the interrupted stage.
  2. Mark the auth wait explicitly; do not retry the same unauthorised call in a tight loop.
  3. Request a human only when reauthentication or MFA actually requires one.
  4. After authentication refresh, reconcile the prior request and verifier state.
  5. Resume only the unverified portion from a durable checkpoint.

Do not store access tokens, refresh tokens, session IDs or secrets in the public work ledger. Record a safe event type, timestamp, owning job ID and outcome instead.

Simulation is not production

The KD11 V20 reliability harness simulated 1,000 WAIT_AUTH lanes, alongside a separate set of 1,000 WAIT_RESOURCE lanes. It reported 2,000 synthetic resumes with zero provider calls, zero provider tokens and zero production jobs. This can exercise state transitions; it does not establish the duration or success rate of live reauthentication.

Human reauthentication minutes, account-wide service usage and verified resumed jobs remain UNKNOWN. See the operating rules builder for checkpoint and human-gate safeguards. Keep provider usage and task acceptance as separate evidence.

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

More posts