@bman654/clodex 2.11.0 → 2.11.2

package/README.md

@@ -245,8 +245,9 @@ A context window is a cost dial as much as a capacity number. OpenAI prices GPT-
 and later prompts above **272,000 input tokens at 2x input and 1.5x output for the
 full request**, which is why the Codex catalog reports a 272,000 window rather than
 the model's ceiling. Newer families inherit the same boundary, so a model released
-after this was written is covered without a clodex update. Clodex follows that: the default `standard` stop stays under the
-line, and a larger window is something you ask for.
+after this was written is covered without a clodex update. Clodex follows that: the
+default `standard` stop stays under the line, and a larger window is something you
+ask for.
 
 ```sh
 clodex models --context sol=max --save     # this model's default, with a cost warning
@@ -254,19 +255,21 @@ clodex claude --context sol=max            # this launch only, nothing saved
 clodex models --context sol=default --save # back to the provider's tuned window
 ```
 
-Each stop is reported with the numbers behind it: the raw window, the headroom
-percentage the Codex catalog uses, the effective window a client should fill, and the
-account ceiling a larger stop can reach. A stop above the ceiling is clamped and says
-so. When a request's own reported token count crosses the boundary, clodex warns once
-per model for the life of the process, because the client's token count and the
-provider's differ after translation and only the provider's settles it.
+Each stop is reported with the numbers behind it: the raw window, the effective
+window a client should fill, and the account ceiling a larger stop can reach. A stop
+above the ceiling is clamped and says so. When a request's own reported token count
+crosses the boundary, clodex warns once per model for the life of the process,
+because the client's token count and the provider's differ after translation and only
+the provider's settles it.
 
 Two things worth knowing about the numbers:
 
-- **ChatGPT/Codex OAuth models carry a 95% headroom convention**, matching the Codex
-  client. Their reported window is 5% below the raw catalog value: `gpt-5.6-sol`
-  reports 258,400 rather than 272,000. This applies to that provider only; API-key
-  and OpenCode Go models keep their full window.
+- **Clodex reports the window the provider actually gives, and holds nothing back.**
+  Deciding how much of a window to leave free is the client's job — Claude Code
+  already reserves a fixed amount below whatever window it is told, and shrinking the
+  number first only costs usable context. A provider that declares a share of its own
+  is still honoured; clodex just never invents one. Use `--context` if you want a
+  smaller window than the provider offers.
 - **The account ceiling moves.** It is server-side and per-account, and it has
   changed by more than 2x within a single day in the past. `max` reads whatever the
   catalog reports now and clamps to it, so a stale ceiling shrinks the stop rather
@@ -359,7 +362,12 @@ clodex --version    # version
   avoid near-immediate termination; the 1h/6h ceilings allow deliberately long
   calls without leaving stalls attached indefinitely. At either deadline,
   clodex aborts the SDK call; cancellation is cooperative, so a provider
-  transport that ignores the abort signal can settle later. These are
+  transport that ignores the abort signal can settle later. clodex also asks
+  the provider to stop as soon as the client that made the request goes away —
+  a Ctrl-C, a killed agent, or a closed browser — instead of waiting for a
+  deadline, whether the answer had started arriving or not. The same
+  cooperative limit applies: clodex stops relaying and requests cancellation,
+  but cannot guarantee the provider stops generating. These are
   server-side limits, and callers may stop sooner. Claude Code currently
   defaults to about 180s of downstream byte silence in proxy mode and 300s in
   endpoint mode, with
@@ -376,11 +384,16 @@ clodex --version    # version
   … backoff, so a shorter idle timeout automatically lowers both. The ceiling
   is `5` at the default timeout and can rise to `10` at the maximum. Larger
   integers clamp with a one-time warning that names the active idle timeout.
-  On a genuinely unavailable provider, five retries can add roughly 62s of
-  fallback backoff instead of the SDK default's roughly 6s; the longer wait is
-  deliberate so transient failures have more time to recover. Provider
-  `retry-after` hints and time spent in failed attempts can mean fewer retries
-  start before a streaming idle deadline; the shared abort signal still
+  Without a retry hint, five retries can add roughly 62s of fallback
+  backoff instead of the SDK default's roughly 6s, giving a transiently
+  unavailable provider more time to recover. When OpenAI explicitly states an
+  acceptable delay for a WebSocket throttle, clodex gives that value to the
+  SDK instead of its fallback schedule. Clodex's existing 5s default remains a
+  client-facing hint for upgrade 403s and WebSocket connection-limit errors
+  that state no delay; it does not replace the SDK's fallback. Other hintless
+  429s also retain the fallback schedule. Provider `retry-after` hints and time
+  spent in failed attempts can mean fewer retries start before a streaming idle
+  deadline; the shared abort signal still
   interrupts backoff when that deadline fires. If a deadline interrupts a
   retry delay, clodex preserves the provider failure that prompted the retry;
   if a currently active call is silent, clodex reports the timeout instead.
@@ -404,10 +417,17 @@ clodex --version    # version
   burst of parallel work less likely to trip OpenAI's own rate limit. (In the
   traffic we sampled, the rejections clustered in the busiest minutes; that the
   rate is what triggers them is a reasonable reading of that, not something we
-  can prove.) A follow-up turn that can reuse the connection it already has is
-  never delayed by this;
+  can prove.) A follow-up turn that already has a connection it can reuse when
+  it arrives is never delayed by this;
   what goes through the limiter is work that needs a *new* connection — a first
-  turn, a conversation that branched, or several agents running at once. The
+  turn, a conversation that branched, or several agents running at once. If a
+  turn that is waiting its place in the queue finds, on being let through, that
+  a connection has freed up and is carrying exactly the conversation it is
+  continuing, it picks that one up instead of opening another. That is
+  uncommon — it needs another turn to finish inside the few seconds this one
+  spends waiting AND to have been on the same conversation history — so treat
+  it as an edge taken when it appears, not as agents routinely sharing
+  connections. The
   default is 60 new connections a minute, with an allowance of 10 opened back
   to back after a quiet spell.
   **This is a real throughput ceiling, not a brief pause.** One new connection