Skip to content

[Feat] Confidence-gated deferral: hand low-confidence browser steps to the chat model and measure the trade-off #94

Open

Description

@Birfy

Why

The README's pitch is that a System 1 decision model answers each step with probabilities, so "calling code can act above a threshold and escalate below it". In the browser front today nothing does that: BrowserDecisionModel (s1a/browser/decision_model.py) always acts on the decision model's top choice, and the wrapped chat model (fallback) is only used for non-browser turns, typed values and the bounded-recovery plan. The per-step confidence is recorded but never used.

Recent work shows the gate is where most of the cost/quality trade-off sits:

#89 lists exactly this as its follow-up ("Adding a confidence gate or System-2 fallback ... once the number means one thing"), and #91 makes confidence = max_k p_k on every backend, so the number is now comparable across Jev, Laya, CLM and Cua.

Proposed scope (one PR, off by default)

  1. A browser-front policy setting, e.g. --defer-below P / S1A_DEFER_BELOW (unset = today's behaviour). When the settled step's confidence is below P, the step is decided by the chat model already wired as fallback, given the same candidates the decision model saw, and must return one of them (same validation as today).
  2. Step records gain deferred: true|false, the decision model's choice and confidence, and the chat model's choice, so every deferral can be audited and the "would it have been right" question answered from the trace.
  3. An offline calibration helper over saved runs: for a target deferral rate (e.g. 10%, 15%, 25% of steps), report the threshold that gives it on that backend. No live calls.
  4. One live comparison on an existing task (e.g. the WebVoyager Allrecipes task in the README, or the deterministic local search scenario from [Tests] Add deterministic local browser search scenario #63): decision model only, chat model only, and deferral at one calibrated rate; success, wall time, cost and the deferral rate, with the runs committed under docs/results/.

Acceptance criteria

Out of scope

  • Deferral in the desktop, games and robotics fronts (follow-ups once the browser result is in).
  • Learned or conformal calibration (TSDS-style guarantees); a plain empirical threshold is enough for a first measurement.

References

Activity

  1. githubergsx commented on Oct 26, 2026

    @githubergsx

    Hi @Birfy, I’d like to take this issue.

    I plan to keep the feature opt-in and scoped to the browser front: add a --defer-below threshold, defer only low-confidence decision steps to the existing chat fallback, and constrain the fallback to the current action space so it cannot produce an arbitrary browser action.

    The PR will include offline tests for threshold behavior, invalid fallback choices, fallback failures, and unchanged behavior when the setting is unset. I will also add auditable tick fields for the original decision, confidence, fallback choice, latency, and usage, plus an offline calibration helper over saved run artifacts.

    For evidence, I will compare decision-only, chat-only, and one empirically calibrated deferral rate on the same bounded browser task, reporting success, wall time, cost, and actual deferral rate. I do not plan to make general calibration or quality claims beyond that measured setup.

    If this scope sounds right, I’ll proceed with a focused PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions