🤖 We're reviewing this PR with Aisle

We're running a security check on the changes in this PR now. This usually takes a few minutes. ⌛
We'll post the results here as soon as they're ready.

Progress:

• Analysis
• Triage
• Finalization

Latest run failed. Keeping previous successful results. Trace ID: 019ccb3a3fb8e619b4e79cf7441d1f2b.

_{Last updated on: 2026-03-08T02:17:04Z}

Greptile Summary

This PR adds "tokens per day" as a recognized rate-limit error pattern across four locations (failover-matches.ts, errors.ts, timer.ts, manager-embedding-ops.ts) to fix issue #38822, where AWS Bedrock's daily token-quota message was not being identified as a retryable rate-limit error.

Changes:

• failover-matches.ts — appends "tokens per day" to the rateLimit string-pattern list, consistent with the existing "tokens per minute" entry
• errors.ts — extends RATE_LIMIT_HINT_RE with tokens per day, acting as a defence-in-depth guard in isLikelyContextOverflowError (the primary gate already runs via isRateLimitErrorMessage beforehand)
• timer.ts — adds tokens per day to TRANSIENT_PATTERNS.rate_limit so one-shot cron jobs are retried instead of being permanently disabled
• manager-embedding-ops.ts — adds tokens per day to isRetryableEmbeddingError so embedding batches are retried on the same error class

Test coverage is thorough: unit tests confirm correct classification and exclusion from context-overflow detection, plus an important guard test that ensures "Context window exceeded: too many tokens per request" is not reclassified as rate-limit. Full integration regression tests cover both the cron retry lifecycle and the embedding batch retry path.

Confidence Score: 5/5

• This PR is safe to merge — the change is narrowly scoped, well-tested, and carries no risk of false positives for context-overflow or other error classes.
• All four pattern sites are updated consistently. The new "tokens per day" substring is unambiguous (AWS Bedrock uses it exclusively for daily quota errors). Existing tests for TPM and context-overflow paths are unaffected, and a dedicated guard test confirms "too many tokens per request" (a context overflow phrasing) remains correctly classified. Integration tests validate the full retry lifecycle for both cron jobs and embedding batches.
• No files require special attention.

_{Last reviewed commit: 132a457}

Addressed the review feedback:

Narrowed "too many tokens" to "too many tokens per" across all 4 files (errors.ts, failover-matches.ts, timer.ts, manager-embedding-ops.ts).

The original "too many tokens" pattern was too broad -- it would also match context-window-exceeded messages like "too many tokens in your request", causing isLikelyContextOverflowError to misclassify them as rate-limit errors (since RATE_LIMIT_HINT_RE is checked before CONTEXT_OVERFLOW_HINT_RE). This would skip compaction/overflow handling and could cause infinite retry loops.

The narrowed "too many tokens per" pattern specifically targets rate-limit messages like "too many tokens per day" / "too many tokens per minute" without false-positiving on context-window errors. The "tokens per day" pattern remains unchanged as it is already specific enough.

Re: the Greptile comments on chat.ts (unused idx, empty autocomplete container, arrow-key nav stub) -- those changes are not part of this PR's commits, so they're out of scope here.

Closing this PR because it looks dirty (too many unrelated or unexpected changes). This usually happens when a branch picks up unrelated commits or a merge went sideways. Please recreate the PR from a clean branch.

@greptileai review

@codex review

Codex Review: Didn't find any major issues. You're on a roll.

Merged via squash.

• Prepared head SHA: 132a45728694053c0e3220e7d861508524f17244
• Merge commit: 8a20f5146047d66c2d384c6a5d5fb646fbcc8249

Thanks @gambletan!