Codex, dieses Retry-Backoff-Design ist ja völlig absurd: Nach einem 403 wirkt mehr Retries nur noch wie Botting

Kürzlich bin ich, als ich mit Codex CLI einen nicht besonders stabilen Upstream angebunden habe, auf ein ziemlich absurdes, aber sehr praktisches Problem gestoßen.

Codex hat Streaming-Reconnects inzwischen als hart kodiertes exponentielles Backoff umgesetzt. Die ersten paar Male wirkt das noch normal, aber später bläht es sich extrem auf:

  • Beim 1. Mal etwa 0.2 Sekunden
  • Beim 5. Mal etwa 3.2 Sekunden
  • Beim 10. Mal schon über 1 Minute
  • Danach kann es sogar auf Versuche alle zehn bis mehrere Dutzend Minuten anwachsen

Das Problem ist, dass dieses Design stillschweigend annimmt: „Je länger es fehlschlägt, desto langsamer sollte man es erneut versuchen.“ In der Realität sind viele Upstreams aber nicht so:

  • Das Gateway spinnt gelegentlich
  • Backend-Routing ist instabil
  • Manche OpenAI-kompatiblen Relays liefern kurzzeitig 403 / der Quotenstatus ist noch nicht aktualisiert
  • In der Praxis reicht es, ein paar Mal mehr zu probieren, und es erholt sich schnell

Das heißt, was man wirklich braucht, ist:

  • dass Nutzer die Häufigkeit der Neuversuche selbst festlegen
  • mindestens feste Intervalle erlauben, z. B. alle 500ms einmal
  • statt von einem fest verdrahteten exponentiellen Backoff gegängelt zu werden

Noch absurder ist: Codex gibt dem Nutzer stream_max_retries, aber keine Konfigurationsmöglichkeit für Wiederholungsintervall und Backoff-Strategie. Das führt dazu:
Du kannst die Anzahl auf 100 setzen, aber nach dem 10. Versuch wird jede Wartezeit unvernünftig lang – völlig entgegen dem Szenario „ein paar Mal mehr probieren, dann klappt’s“.

Ich habe das Problem bereits upstream gemeldet:

Meiner Ansicht nach ist das im Kern nicht nur eine schlechte Parameterwahl, sondern ein Design, das zu sehr selbst entscheidet und dem Nutzer keine freie Wahl lässt.

Wenn man in TOML explizit so eine Konfiguration unterstützen könnte, würde man die Entscheidungshoheit wenigstens an den Nutzer zurückgeben:

[model_providers.custom]
stream_max_retries = 100
stream_retry_delay_ms = 500
stream_retry_backoff = "fixed"

Diese Anforderung ist tatsächlich sehr verbreitet:
„Dieser Upstream zickt oft rum, aber ein paar schnelle Versuche hintereinander reichen meist, dann läuft es wieder – bitte zieh mir das nicht automatisch auf einmal alle zig Minuten auseinander.“