feat(client): configurable model-call retries, deeper by default

[lawrencechen98]

Why

Navigator model calls go through the bundled OpenAI client, which retries connection errors, timeouts and 429/5xx with exponential backoff. Two things were wrong for agent workloads:

• the depth was the vendor default of 2 (under ~2s of total backoff), and
• max_retries was not reachable from the SDK surface at all — the chat namespace's docstring even said so.

A long-horizon agent run issues hundreds of sequential model calls, so a single unretried upstream blip ends the whole run.

Measured on 2026-08-31: three ~2-minute bursts of gateway {'type': 'upstream_error'} 5xx cost an OSWorld-V2 eval 20 of its 108 tasks, every one dying on its first attempt.

What

• config.DEFAULT_MAX_RETRIES = 4, documented with the reasoning above.
• max_retries on YutoriClient and AsyncYutoriClient, threaded into the chat namespace's OpenAI client.
• Docstrings on both chat namespaces corrected — they claimed the depth "is not configurable through the SDK surface".
• Tests pin the default, an override, and max_retries=0.

Retried requests are idempotent, so the ceiling is caller patience, not correctness; unattended batch work can raise it further.

Test

715 passed, 3 skipped — full suite. ruff check + format clean on the touched files.

---

Note

Low Risk
Retry behavior changes default resilience for Navigator chat only; retried completions are documented as idempotent. N2 exposes a read-only request builder without changing loop semantics.

Overview
Navigator client.chat model calls now use a SDK default of 4 retries (via DEFAULT_MAX_RETRIES) instead of the bundled OpenAI client’s 2, with exponential backoff on transient failures. max_retries is exposed on YutoriClient and AsyncYutoriClient and passed into the lazy chat namespace; callers can raise it for long batch runs or set 0 to disable retries. Chat namespace docstrings no longer claim retry depth is fixed.

N2ComputerAgent.completion_request() is added so harnesses can obtain the same kwargs the loop would send (windowed messages, sampling, prev_request_id) plus optional extra chat messages—e.g. a step-cap “stop and summarize”—without advancing the loop or mutating trajectory. The internal _predict_step path now builds requests through completion_request(items=...).

Tests cover default/override/disable retries and the public completion_request surface.

^{Reviewed by Cursor Bugbot for commit 7a5e49b. Bugbot is set up for automated code reviews on this repo. Configure here.}