[Feat] Make the decision deadline configurable for slower local System One servers

[chaimaerachdi]

Why

JevModel cuts every decision at 5 s (DECISIONS_TIMEOUT_S), a deadline sized for Jev, which answers in about
0.3 s. A local System One server reached through TYPESAFE_API_URL can be slower. On Google Flights, OneJev-27B
(OmniJev's new 27B model, which speaks the same API) on an A100 takes about 3.7 s a decision and more on the calendar
page, which offers 66 more elements. Every run stopped at the eighth step, right after the calendar opened.

How

• s1a/decision_models/wire.py: decisions_timeout_from_env() reads S1A_DECISION_TIMEOUT_S; unset, it returns
  DECISIONS_TIMEOUT_S (5 s). A value that is not a finite, positive number (nan, inf and 1e9999 included) is
  MODEL_SERVICE_CONFIG_ERROR, naming the variable.
• s1a/decision_models/jev.py: JevModel.from_env(timeout_s=None) uses it; an explicit timeout_s still wins.

What

• New setting S1A_DECISION_TIMEOUT_S (docs/configuration.md, .env.example, CHANGELOG.md).
• Nothing changes when it is unset: Jev keeps 5 s.

Measured (Google Flights, Zurich to London, one way; A100 80 GB; headless Chromium)

Success is judged by a vision model (Gemini 2.5 Flash) on the final screenshot. Time is split with the repo's
profiler (--profile-out), as in docs/benchmarks.md.

Model	Deadline	Success	Model time per task	Per decision	Page	Browser
Jev 1.13 (OpenRouter)	5 s	5 / 5	3.3 s	0.29 s	12.3 s	9.6 s
OneJev-27B (local, qev serve)	5 s	0 / 5, all stopped at step 8	-	3.0 s	-	-
OneJev-27B (local, qev serve)	30 s	7 / 7, the same 11 actions as Jev in every run	61.2 s	3.7 s	11.4 s	9.7 s

Times are medians over the runs. At 30 s, ten runs were started and three were interrupted by hand before the end;
those three are not counted.

Verification

• uv run ruff format --check . && uv run ruff check .: clean.
• uv run ty check: 1 diagnostic in s1a/decision_models/cua.py, the same on main.
• uv run pytest -q --ignore=tests/test_browser_policy.py: 394 passed, 16 failed; main on this Windows machine
  fails the same 16 (environment), so none is new. 4 new tests in tests/test_decision_models_jev.py
  (TestDecisionTimeout): default 5 s, the variable, an explicit value winning, invalid values (abc, 0, -3, nan, inf, -inf, 1e9999).

[IRONICBo]

float() accepts nan, inf, and overflow such as 1e9999; neither nan nor positive infinity satisfies value <= 0, so they pass this guard. nan then makes the computed deadline and remaining timeout nan, while inf removes the intended bound. Please also reject not math.isfinite(value) and extend the config-error regression with nan, inf, and 1e9999.

[chaimaerachdi]

thank you @IRONICBo ; fixed in 847db86: the guard now rejects non-finite values (not math.isfinite(value) or value <= 0), and the config-error test covers nan, inf, -inf and 1e9999.

[MrDongsls]

Non-blocking:

• docs/browser-front.md still documents DECISIONS_TIMEOUT_S as a fixed 5-second value, while this PR introduces S1A_DECISION_TIMEOUT_S. The setting is already documented in docs/configuration.md, so this does not affect runtime behavior, but updating the browser-front reference would keep the documentation consistent.

FYI, out of scope for this PR: an explicit timeout_s passed to JevModel.from_env() can still bypass the new environment-value validation with float("nan") or float("inf"). The environment-variable path introduced here correctly rejects them; this can be addressed separately if needed.

[hsliuustc0106]

@chaimaerachdi could you add a Demo / evidence section using the self-review guidance now merged in #39? The measurements in the description are helpful; a short recording, screenshots with logs, or a reproducible terminal trace would make the deadline change easier to verify.

On the same task and local System One server, please show:

• The default 5 s per-decision deadline timing out, then the configured deadline (e.g. S1A_DECISION_TIMEOUT_S=30) allowing the task to finish, with the input, actions and observable final result
• A response that actually exceeds the configured deadline failing cleanly without hanging, with retries staying within the total per-decision budget

Please include the invocation/config, model and server versions, hardware, exact baseline/head commits, actual elapsed times and outcomes, and links to the raw traces. For the reported Flights comparison, retain the three interrupted runs in the run record alongside the seven completed runs. Label any injected-delay fixture separately from real-server evidence.

Existing artifacts are fine; no new A100 run or video is required. If a real-server run is unavailable, note the gap. Please redact secrets/private data and say whether any attached media may be reused in public project updates, with any attribution requirements.

[chaimaerachdi]

Thanks for the review. Updated docs/browser-front.md in de5f5d2 to mention S1A_DECISION_TIMEOUT_S. The explicit timeout_s validation can go in a separate PR, as suggested.

[hsliuustc0106]

@chaimaerachdi Please try this deadline change with system1-omni's supported Open-Jev-27B-v1.1 worker, and attach a short video of the Flights agent.

The reported local inference uses qev serve; I don't see a system1-omni run in the evidence. The existing HTTP URL/model overrides can target the Rust frontend's /v1/systemone. Please record the checkpoint and serving implementation explicitly, including their differences from the reported OneJev configuration.

The video should show the same task with the default and configured deadlines, the agent's actions and the actual final outcome. Link the raw traces and exact agents/engine commits, command and hardware; retain failures and interrupted runs in the evidence.

[hsliuustc0106]

@chaimaerachdi We're prioritizing the new backends and agent improvements for v0.2.0. This deadline change supports the local/served backend work.

Please resolve the current merge conflicts, rerun the required checks, and respond to the outstanding System1-Omni Open-Jev/default-versus-configured-deadline evidence request. If a real-server recording is unavailable, state the gap and the precise blocker; keep injected-delay fixtures distinct from real-server evidence and retain the interrupted runs. Please reply with the remaining work and expected completion time.

[chaimaerachdi]

Thanks for merging. The real-server evidence you asked for, through system1-omni, is in the follow-up PR (commit 34cc19b, docs/results/decision-timeout/2026-10-07-a40/).

Video (attached): the same Flights task, three runs one after the other, only the deadline changing, real time, no cuts. Path: s1a main at 22e685b (this merge) -> system1-omni's Rust frontend omni-jev (99865743) -> Open-Jev's reference server (3308a15) with Open-Jev-9B, one NVIDIA A40 46 GB. No injected delay; the unit tests stay the separate injected-value evidence.

• Default 5 s: the first decision is not answered within 5 s; the run stops cleanly at 13.5 s (model call failed, no hang).
• S1A_DECISION_TIMEOUT_S=30: 7 decisions of 7.1 to 18.0 s, none cut, the run finishes at 104 s. The task itself is not solved: the agent typed Zurich and London, then the chat model read a price from the round-trip calendar without a one-way search.
• S1A_DECISION_TIMEOUT_S=1, a deadline the server always exceeds: clean failure about 1 s after the first decision is asked, no hang.

Precise blocker for Open-Jev-27B-v1.1 through system1-omni's native worker: I built it for sm_86 and exported the checkpoint on this machine (37 s, peak 59 GiB RAM, against the 110 GB in the recipe), but the 48 GiB export does not fit the A40: the worker stops at load with "cudaMalloc: out of memory" (log in the same folder). It needs a single GPU above 48 GB (A100 80 GB, H100, H200). Open-Jev-9B is a different checkpoint from both Open-Jev-27B-v1.1 and the OneJev-27B / qev serve runs of the description.

The OneJev-27B records of the description, including the three interrupted runs, are not in the repo yet; I'll add them to the follow-up PR. The video may be reused in project updates with a link to that folder.

PR36_deadline_system1-omni_A40_2026-10-07.mp4

[chaimaerachdi]

Update: the same three runs through system1-omni's own native Open-Jev worker (4a79980, Open-Jev-9B) on the A40, video attached, records in docs/results/decision-timeout/2026-10-08-a40-native/ (commit 389f346).

• Default 5 s: the first decision (8.7 s) is cut; clean stop at 12.3 s, no hang.
• S1A_DECISION_TIMEOUT_S=30: both decisions complete (8.7 s and 6.8 s); the 9B model then answers BLOCKED, so the task is not solved.
• S1A_DECISION_TIMEOUT_S=1: clean failure about 1 s after the first decision is asked, no hang.

4. Ouvre ton Bureau dans l'explorateur Windows et trouve le fichier PR36_deadline_system1-omni_native_A40_2026-10-08.mp4.

PR36_deadline_system1-omni_native_A40_2026-10-08.mp4

[chaimaerachdi]

As promised: every OneJev-27B run behind this PR's table is now in #56, the three interrupted 30 s runs included (10 started, 7 completed and counted, 3 interrupted), each with its log, profile and final screenshot.