@bman654/clodex 2.11.1 → 2.11.3

package/README.md

@@ -362,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
@@ -379,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.
@@ -407,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