[samirhvbr]

A subscription usage-limit rejection, such as a provider's exhausted hourly or weekly allowance reported as HTTP 429 with usage_limit_reached, cannot recover through ordinary transient retries. Retrying it in both the SDK and Strix turn loop delays a resumable stop and repeatedly hits the exhausted quota.

Classify usage-limit errors as terminal in both retry layers while retaining retries for ordinary transient 429 throttles. OpenAI RateLimitError follows the existing resumable stop path; a non-OpenAI exception carrying the same usage-limit marker now follows that path too, preserving the scan for resume after the limit resets.

The branch includes upstream 6b7ae2eb. The shared runner test fixture now supplies telemetry.run_record_timings=False, which the current runner requires before entering the agent loop. That missing test setting was inherited from upstream; it was not a retry-logic failure. The added exception handler also uses the already validated root ID without introducing redundant None-check diagnostics.

Validation on macOS/Apple Silicon, Python 3.12.14, frozen dependencies and isolated HOME/environment:

• 108 passed across transient-retry, SDK retry, runner rate-limit, execution and request-log tests.
• Coverage includes ordinary 429 retry behavior, terminal usage limits, and resumable stops for OpenAI and non-OpenAI exceptions.
• Repository-wide Ruff lint/format, Mypy and Bandit passed; git diff --check passed.
• Pyright reports 941 errors on both this branch and unchanged upstream, with no new diagnostic signatures after normalizing checkout paths.

Exceptions and model behavior were simulated. No real provider request, exhausted account, live scan or full repository test suite was exercised. Remote CI still requires maintainer approval.

Prepared with AI assistance.

[greptile-apps]

Greptile Summary

This PR adds text-based detection of provider usage-limit errors and excludes matching failures from both model retry layers so exhausted subscription windows fail quickly.

• Adds usage-limit markers and a shared classifier.
• Composes the classifier into the SDK retry policy.
• Excludes matching failures from turn replay.
• Adds regression coverage for usage-limit and ordinary 429 behavior.

Confidence Score: 4/5

The PR needs adjustment before merging because usage-limit failures from LiteLLM-routed providers can now fail the scan instead of producing the promised resumable stop.

Retry suppression is provider-agnostic, while terminal rate-limit recovery is restricted to OpenAI's exception class, leaving supported non-OpenAI routes on the generic failure path.

Files Needing Attention: strix/core/execution.py, strix/config/models.py, and strix/core/runner.py

Important Files Changed

Filename	Overview
strix/config/codex.py	Adds the shared text-marker predicate used to identify usage-limit failures.
strix/config/models.py	Prevents SDK retries for matching errors, but applies the classification across all provider routes.
strix/core/execution.py	Suppresses turn replay globally, exposing non-OpenAI provider exceptions to a runner that cannot convert them into resumable stops.
tests/test_execution_transient_retry.py	Covers OpenAI usage-limit and ordinary-rate-limit classification but not a LiteLLM-routed exception.
tests/test_model_retry.py	Verifies the composed retry policy declines matching text while retaining ordinary retry behavior.

Prompt To Fix All With AI

### Issue 1
strix/core/execution.py:135-136
**Non-OpenAI limits fail**

When a LiteLLM-routed provider raises a marker-bearing usage-limit error, this classification suppresses both retry layers, but `run_strix_scan` only handles `openai.RateLimitError` as resumable. The provider exception therefore reaches the generic failure path, marking the root failed and re-raising instead of showing the resume hint.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "fix(retry): treat provider usage-limit e..." | Re-trigger Greptile}

[greptile-apps]

Non-OpenAI limits fail

When a LiteLLM-routed provider raises a marker-bearing usage-limit error, this classification suppresses both retry layers, but run_strix_scan only handles openai.RateLimitError as resumable. The provider exception therefore reaches the generic failure path, marking the root failed and re-raising instead of showing the resume hint.

Knowledge Base Used:

• Scan execution lifecycle
• Configuration and provider settings

Prompt To Fix With AI

This is a comment left during a code review.
Path: strix/core/execution.py
Line: 135-136

Comment:
**Non-OpenAI limits fail**

When a LiteLLM-routed provider raises a marker-bearing usage-limit error, this classification suppresses both retry layers, but `run_strix_scan` only handles `openai.RateLimitError` as resumable. The provider exception therefore reaches the generic failure path, marking the root failed and re-raising instead of showing the resume hint.

**Knowledge Base Used:**
- [Scan execution lifecycle](https://app.greptile.com/strix-org-3/-/custom-context/knowledge-base/usestrix/strix/-/docs/scan-execution.md)
- [Configuration and provider settings](https://app.greptile.com/strix-org-3/-/custom-context/knowledge-base/usestrix/strix/-/docs/configuration-and-provider-settings.md)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[Copilot]

Pull request overview

This PR updates Strix’s retry behavior to treat provider “usage-limit reached” (plan/subscription window exhausted) errors as terminal rather than transient, preventing repeated retries that cannot succeed until the provider’s window resets.

Changes:

• Add codex.is_usage_limit_error(exc) predicate based on provider error text markers.
• Exclude usage-limit errors from Strix’s execution replay retry (execution._is_transient_model_error).
• Exclude usage-limit errors from the SDK-level model retry policy by composing the existing retry policy with an additional “not usage limit” guard.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
strix/config/codex.py	Adds is_usage_limit_error and marker definitions for detecting subscription usage-limit rejections.
strix/core/execution.py	Treats usage-limit errors as non-transient to stop Strix turn replay retries.
strix/config/models.py	Wraps the default SDK retry policy with an additional predicate to prevent retrying usage-limit errors.
tests/test_model_retry.py	Adds regression test ensuring usage-limit errors are not retried by the SDK retry policy.
tests/test_execution_transient_retry.py	Adds regression tests ensuring usage-limit errors are terminal in Strix replay logic and ordinary 429s remain transient.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.