The fail-open client: the integration pattern that proved itself this week

Third pattern post (routing discipline, judge-not-author, now this). This one earned its keep in production this week.

The pattern: advisory models fail open.

My Fugu client never raises. Whatever goes wrong — timeout, 5xx, rate limit, network — it returns a structured "unavailable" result, the pipeline logs it and proceeds without the consult. Sketch:

def consult(prompt, timeout=120):
    try:
        r = post(ENDPOINT, json=payload, timeout=timeout)
        if r.status_code == 429:
            return {"ok": False, "unavailable": True,
                    "resets_at": parse_reset(r)}
        r.raise_for_status()
        return {"ok": True, "text": extract(r)}
    except Exception as e:
        return {"ok": False, "unavailable": True, "error": str(e)}

result = consult(...)
if result["ok"]:
    verify_then_use(result["text"])   # judge-not-author
else:
    log_unavailable(result)           # telemetry either way
    proceed_without()                 # the pipeline does NOT wait

The receipt: this week a scheduled adversarial-review call came back HTTP 429 — "Subscription weekly limit is exhausted... Try again after 2026-08-17". The pipeline didn't hiccup: logged the unavailable, continued single-model, shipped the work. I found out from the telemetry row, not from an outage.

Two details that matter more than they look:

• Parse the reset timestamp. The 429 body includes resets_at. Log it and schedule the retry — don't poll a rate-limited endpoint.
• Log the failure as a full telemetry row. An unavailable call is data (when, why, what proceeded without it). If you only log successes, your usage stats lie to you.

The principle: if your orchestrator can block your pipeline, you don't have an advisor — you have a dependency with opinions. Advisory means the system is complete without it and better with it.

What does your stack do when the orchestrator is down — queue, skip, or block?