Skip to content

fix(litellm): detect GPT-5 family when model has openai/ or azure/ prefix#2401

Merged
naorpeled merged 5 commits into
The-PR-Agent:mainfrom
sizickp:fix/gpt-5-prefix-detection
Jul 3, 2026
Merged

fix(litellm): detect GPT-5 family when model has openai/ or azure/ prefix#2401
naorpeled merged 5 commits into
The-PR-Agent:mainfrom
sizickp:fix/gpt-5-prefix-detection

Conversation

@sizickp

@sizickp sizickp commented May 18, 2026

Copy link
Copy Markdown
Contributor

Summary

GPT-5 codex models only accept temperature=1. The LiteLLM handler swaps temperature for reasoning_effort only when the model string starts with gpt-5, but users frequently put the full provider-qualified name in [config].model (e.g. openai/gpt-5.1-codex-max). That prefix makes model.startswith('gpt-5') return False, so the handler still sends temperature=0.2 and litellm rejects the call:

litellm.UnsupportedParamsError: gpt-5 models (including gpt-5-codex) don't support temperature=0.2.
Only temperature=1 is supported. ...
Failed to generate prediction with openai/gpt-5.1-codex-max

The primary model always errors, and PR-Agent silently falls back to the secondary model on every invocation — degrading answer quality vs. the configured model, doubling per-call latency, and burning input tokens on a request that can never succeed.

Fix

In pr_agent/algo/ai_handlers/litellm_ai_handler.py::chat_completion, normalize the model name by stripping the openai/ / azure/ prefix before the GPT-5 detection, then rebuild the routed name with the original provider prefix (so Azure routing is preserved when self.azure is set).

This is a minimal, surgical change — no behavior changes for unprefixed names, no widening of the heuristic; just the prefix-aware detection.

Repro

configuration.toml:

[config]
model = "openai/gpt-5.1-codex-max"
fallback_models = ["gpt-5.4-mini"]

Before: every call logs the warning above and falls back. After: the GPT-5 branch runs, reasoning_effort is set, temperature is dropped, and the primary model is used.

Test plan

  • Added test_gpt5_with_openai_prefix_triggers_reasoning_effort covering openai/gpt-5, openai/gpt-5.1-codex, openai/gpt-5.1-codex-max, openai/gpt-5.4-mini. Asserts reasoning_effort is set, temperature is not in kwargs, and the model name is not double-prefixed (openai/openai/...).
  • Added test_gpt5_with_openai_prefix_strips_thinking_suffix for openai/gpt-5_thinking — verifies suffix is removed and provider prefix kept exactly once.
  • All existing test_litellm_* suites still pass (68 tests).

GPT-5 codex models only accept `temperature=1`. The handler converted
`temperature` into `reasoning_effort` only when the model string started
with `gpt-5`, but users frequently set the full provider-qualified name
in their config (e.g. `openai/gpt-5.1-codex-max`). That prefix made the
`startswith('gpt-5')` check fail, so `temperature=0.2` was sent and
litellm rejected the request with `UnsupportedParamsError`. The primary
model then always fell back to the secondary one — silently downgrading
quality and doubling per-call latency/cost.

Normalize the model name by stripping the `openai/` / `azure/` prefix
before the GPT-5 check, and rebuild the routed name with the original
provider so Azure routing is preserved.

Adds regression tests for `openai/gpt-5*` (including `codex-max`) and
for the `_thinking` suffix together with a prefix.
@github-actions github-actions Bot added the bug label May 18, 2026
@qodo-free-for-open-source-projects

Copy link
Copy Markdown
Contributor

Review Summary by Qodo

Fix GPT-5 detection with provider-prefixed model names

🐞 Bug fix

Grey Divider

Walkthroughs

Description
• Strip provider prefix before GPT-5 detection to handle prefixed model names
• Preserve original provider prefix in routed model name for Azure compatibility
• Add regression tests for openai/gpt-5* variants and _thinking suffix handling
Diagram
flowchart LR
  A["Model name with prefix<br/>openai/gpt-5.1-codex-max"] -->|removeprefix| B["Normalized base<br/>gpt-5.1-codex-max"]
  B -->|startswith check| C["GPT-5 path triggered"]
  C -->|set reasoning_effort| D["Drop temperature"]
  D -->|rebuild with prefix| E["Route to openai/gpt-5.1-codex-max"]
Loading

Grey Divider

File Changes

1. pr_agent/algo/ai_handlers/litellm_ai_handler.py 🐞 Bug fix +9/-2

Normalize model name for GPT-5 prefix detection

• Strip openai/ and azure/ prefixes from model name before GPT-5 detection
• Rebuild model name with original provider prefix to preserve Azure routing
• Remove _thinking suffix from normalized base model, not the prefixed version
• Add detailed comments explaining the prefix-aware detection logic

pr_agent/algo/ai_handlers/litellm_ai_handler.py


2. tests/unittest/test_litellm_reasoning_effort.py 🧪 Tests +59/-0

Add regression tests for prefixed GPT-5 models

• Add test_gpt5_with_openai_prefix_triggers_reasoning_effort covering four prefixed GPT-5 variants
• Verify reasoning_effort is set and temperature is not in kwargs for prefixed models
• Assert model name is not double-prefixed when passed to litellm
• Add test_gpt5_with_openai_prefix_strips_thinking_suffix for openai/gpt-5_thinking edge case

tests/unittest/test_litellm_reasoning_effort.py


Grey Divider

Qodo Logo

@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented May 18, 2026

Copy link
Copy Markdown
Contributor

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

Grey Divider


Action required

1. patch() line exceeds 120 ✓ Resolved 📘 Rule violation ⚙ Maintainability
Description
Several newly added with patch(...) lines in the unit tests exceed the repository's 120-character
line limit, which is enforced by the project's Ruff configuration. This can cause lint/CI failures
and reduces readability.
Code

tests/unittest/test_litellm_reasoning_effort.py[707]

+            with patch('pr_agent.algo.ai_handlers.litellm_ai_handler.acompletion', new_callable=AsyncMock) as mock_completion:
Evidence
PR Compliance ID 9 requires respecting the 120-character line length. The newly added `with
patch(...)` statements are written on single lines that exceed this limit.

AGENTS.md: AGENTS.md: AGENTS.md: AGENTS.md: AGENTS.md: AGENTS.md: AGENTS.md: AGENTS.md
tests/unittest/test_litellm_reasoning_effort.py[707-707]
tests/unittest/test_litellm_reasoning_effort.py[731-731]
tests/unittest/test_litellm_reasoning_effort.py[751-751]
tests/unittest/test_litellm_reasoning_effort.py[782-782]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
New test code introduces lines longer than 120 characters (notably `with patch('pr_agent.algo.ai_handlers.litellm_ai_handler.acompletion', ...)`), violating the repo's 120-character line-length convention.
## Issue Context
`pyproject.toml` configures Ruff with `line-length = 120`, so these lines are likely to fail linting.
## Fix Focus Areas
- tests/unittest/test_litellm_reasoning_effort.py[707-707]
- tests/unittest/test_litellm_reasoning_effort.py[731-731]
- tests/unittest/test_litellm_reasoning_effort.py[751-751]
- tests/unittest/test_litellm_reasoning_effort.py[782-782]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Azure+prefix skips GPT-5 ✓ Resolved 🐞 Bug ≡ Correctness
Description
In Azure mode, chat_completion() prepends azure/ before computing model_base, and the new
removeprefix() chain only removes a single leading provider prefix. If the configured model is
already provider-qualified (e.g. openai/gpt-5* or azure/gpt-5*), model_base can still start
with openai/ or azure/, so the GPT-5 branch is skipped and temperature is sent (triggering the
same LiteLLM UnsupportedParamsError this PR aims to fix).
Code

pr_agent/algo/ai_handlers/litellm_ai_handler.py[R438-440]

+                model_base = model.removeprefix('openai/').removeprefix('azure/')
+                if model_base.startswith('gpt-5'):
           # Use configured reasoning_effort or default to MEDIUM
Evidence
chat_completion() prepends azure/ before the new GPT-5 normalization; the new normalization
removes only one leading prefix, so any provider-qualified model string in Azure mode can still have
a provider segment at the start of model_base and fail GPT-5 detection. Models are sourced from
config/fallbacks without restrictions, so provider-qualified strings are feasible inputs.

pr_agent/algo/ai_handlers/litellm_ai_handler.py[409-413]
pr_agent/algo/ai_handlers/litellm_ai_handler.py[433-461]
pr_agent/algo/pr_processing.py[341-354]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
In `LiteLLMAIHandler.chat_completion()`, GPT-5 detection relies on `model_base` computed via `removeprefix('openai/').removeprefix('azure/')`. When `self.azure` is enabled, the function prepends `azure/` to the model first; if the incoming model already has a provider prefix, the resulting string can contain multiple provider segments (e.g. `azure/openai/gpt-5...` or `azure/azure/gpt-5...`). The current normalization removes at most one leading prefix, so `model_base` may still begin with a provider segment and fail `startswith('gpt-5')`, causing `temperature` to be passed to GPT-5.
### Issue Context
Models come directly from user configuration/fallback lists and can be provider-qualified strings.
### Fix Focus Areas
- pr_agent/algo/ai_handlers/litellm_ai_handler.py[409-413]
- pr_agent/algo/ai_handlers/litellm_ai_handler.py[433-461]
- pr_agent/algo/pr_processing.py[341-354]
### Suggested fix
Refactor provider handling so you do not build composite provider prefixes:
1) Determine/normalize the provider prefix separately from the model name (don’t mutate `model` with `'azure/' + model` before parsing).
2) Strip provider prefixes in a loop (or parse once) until the remaining model name is the real base (`gpt-5...`).
3) Then rebuild the final routed model string once (provider + base model), ensuring exactly one provider prefix.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Provider prefix overridden ✓ Resolved 🐞 Bug ≡ Correctness
Description
For GPT-5 models, the new reroute code rebuilds model using `provider_prefix = 'azure/' if
self.azure else 'openai/' after stripping any leading openai/ or azure/` from the input. This
can silently change an explicitly provided provider-qualified model like azure/gpt-5... into
openai/gpt-5... when self.azure is false, routing the request to the wrong provider.
Code

pr_agent/algo/ai_handlers/litellm_ai_handler.py[R458-460]

+                    # Preserve azure/ routing if it was applied above; otherwise route via openai/
+                    provider_prefix = 'azure/' if self.azure else 'openai/'
+                    model = provider_prefix + model_base.replace('_thinking', '')  # remove _thinking suffix
Evidence
The GPT-5 reroute path always reconstructs the model using a prefix derived only from self.azure,
after explicitly removing any openai/ or azure/ prefix from the input. Since model values come
from config/fallback lists, an explicitly provider-qualified model string can be rewritten to a
different provider.

pr_agent/algo/ai_handlers/litellm_ai_handler.py[438-460]
pr_agent/algo/pr_processing.py[341-354]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
When the GPT-5 branch runs, the code strips a leading provider prefix into `model_base` and then forces the rebuilt provider prefix based on `self.azure`. If the user explicitly passed a provider-qualified model (e.g. `azure/gpt-5...`) while `self.azure` is false, the handler rewrites it to `openai/gpt-5...`.
### Issue Context
The system pulls model strings directly from user config + fallback models; these values may include provider prefixes.
### Fix Focus Areas
- pr_agent/algo/ai_handlers/litellm_ai_handler.py[438-460]
- pr_agent/algo/pr_processing.py[341-354]
### Suggested fix
Preserve the explicit provider prefix when present:
- Parse the incoming `model` into `(explicit_provider_prefix, model_name)` if it starts with `openai/` or `azure/`.
- Choose the provider prefix as:
- `azure/` if `self.azure` is true (Azure mode), else
- `explicit_provider_prefix` if present, else
- default `openai/`.
- Rebuild `model` from that chosen prefix + stripped base model (and apply `_thinking` removal on the base model).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

4. Prefixed model capability bypass 🐞 Bug ≡ Correctness ⭐ New
Description
After the new GPT-5 normalization, chat_completion() still uses the full routed model string (often
prefixed with "openai/" or auto-prepended "azure/") when checking capability lists like
no_support_temperature_models, user_message_only_models, and support_reasoning_models. Because those
lists largely contain base names (e.g., "o1-mini", "o3-mini"), provider-qualified configs like
"openai/o1-mini" or Azure-mode "azure/o3-mini" can incorrectly add temperature or omit
reasoning_effort/user-only handling.
Code

pr_agent/algo/ai_handlers/litellm_ai_handler.py[R451-459]

+                # Detect GPT-5 family regardless of provider prefix(es) on the model name.
+                # Users sometimes put a provider prefix in config (e.g. "openai/gpt-5.1-codex-max"),
+                # and Azure mode auto-prepends "azure/", which together can produce stacked prefixes
+                # like "azure/openai/gpt-5...". Without normalization the GPT-5 path is skipped and
+                # litellm rejects the request with UnsupportedParamsError for temperature=0.2.
+                model_base = model
+                while model_base.startswith(('openai/', 'azure/')):
+                    model_base = model_base.removeprefix('openai/').removeprefix('azure/')
+                if model_base.startswith('gpt-5'):
Evidence
The handler accepts and even auto-adds provider prefixes to model, but later capability checks use
model directly; meanwhile the capability lists contain mostly unprefixed base model names, so
provider-qualified names won’t match and the wrong kwargs can be constructed.

pr_agent/algo/ai_handlers/litellm_ai_handler.py[427-429]
pr_agent/algo/ai_handlers/litellm_ai_handler.py[492-537]
pr_agent/algo/init.py[301-326]
pr_agent/algo/init.py[356-363]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`chat_completion()` normalizes `model_base` only for the GPT-5 detection branch, but later capability checks (`user_message_only_models`, `no_support_temperature_models`, `support_reasoning_models`) still compare against `model` which may include provider prefixes (and in Azure mode always includes `azure/`). Since the capability lists are mostly stored as unprefixed base names (e.g., `o1-mini`, `o3-mini`), provider-qualified model names can bypass these checks and cause unsupported params to be sent or supported params to be omitted.

### Issue Context
- Users frequently configure provider-qualified models (e.g., `openai/...`), and Azure mode prepends `azure/`.
- Capability lists in `pr_agent/algo/__init__.py` include many base model names without provider prefixes.

### Fix Focus Areas
- pr_agent/algo/ai_handlers/litellm_ai_handler.py[421-537]
- pr_agent/algo/__init__.py[301-363]

### Implementation sketch
1. Keep passing the routed `model` (with provider prefix) to LiteLLM.
2. Derive a `model_for_caps` (e.g., by stripping repeated leading `openai/` and `azure/` the same way as `model_base`).
3. Update capability checks to consider both forms:
  - `if model in LIST or model_for_caps in LIST:`
  This preserves entries that intentionally include provider prefixes (e.g., `deepseek/deepseek-reasoner`) while fixing `openai/o1-mini` / `azure/o3-mini`.
4. Add/adjust unit tests for at least one non-GPT-5 model in these lists using a provider prefix (e.g., `openai/o1-mini` should not add `temperature`; `openai/o3-mini` should add `reasoning_effort`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


5. Tests don’t control env state ✓ Resolved 📘 Rule violation ☼ Reliability
Description
The newly added unit tests instantiate LiteLLMAIHandler() without explicitly setting/deleting
environment variables that its constructor reads, which can make the tests flaky in environments
where variables like AWS_USE_IMDS or OPENAI_API_KEY are set. This violates the requirement to
explicitly control env/process-global state in tests.
Code

tests/unittest/test_litellm_reasoning_effort.py[R713-718]

+                handler = LiteLLMAIHandler()
+                await handler.chat_completion(
+                    model=model,
+                    system="test system",
+                    user="test user"
+                )
Evidence
PR Compliance ID 17 requires tests to explicitly set/delete environment variables and global state
they depend on. The added tests instantiate LiteLLMAIHandler() (new lines) while the handler
constructor branches on environment variables, so the tests should proactively set/delenv relevant
variables (or assert preconditions) to avoid hidden coupling to the runner environment.

tests/unittest/test_litellm_reasoning_effort.py[713-718]
pr_agent/algo/ai_handlers/litellm_ai_handler.py[51-59]
Best Practice: Learned patterns

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
New tests create `LiteLLMAIHandler()` but do not explicitly control environment variables/process-global state that the handler reads during `__init__`, which can cause flaky behavior depending on the runner environment.
## Issue Context
`LiteLLMAIHandler.__init__()` reads env vars (e.g., `OPENAI_API_KEY`, `AWS_USE_IMDS`) and may execute different initialization paths based on them.
## Fix Focus Areas
- tests/unittest/test_litellm_reasoning_effort.py[688-812]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


6. Azure cases untested ✓ Resolved 🐞 Bug ⚙ Maintainability
Description
The added unit tests cover only openai/gpt-5* inputs with self.azure false and do not exercise
azure/gpt-5* inputs or Azure-mode behaviors that interact with the new prefix stripping/rerouting.
This leaves the provider-routing and Azure-prefix edge cases unprotected and likely to regress.
Code

tests/unittest/test_litellm_reasoning_effort.py[R699-704]

+        prefixed_models = [
+            "openai/gpt-5",
+            "openai/gpt-5.1-codex",
+            "openai/gpt-5.1-codex-max",
+            "openai/gpt-5.4-mini",
+        ]
Evidence
Group 8 introduces provider-prefix handling tests but only lists openai/... models; there are no
corresponding azure/... tests despite code explicitly handling/removing an azure/ prefix.

tests/unittest/test_litellm_reasoning_effort.py[686-744]
pr_agent/algo/ai_handlers/litellm_ai_handler.py[438-460]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Current tests validate `openai/gpt-5*` prefixed inputs but do not cover `azure/gpt-5*` or Azure-mode (`self.azure==True`) interactions with the new prefix normalization and reroute logic.
### Issue Context
Prefix handling logic now strips/rebuilds provider prefixes for GPT-5; without tests for `azure/` and Azure mode, bugs in provider routing/detection can slip through.
### Fix Focus Areas
- tests/unittest/test_litellm_reasoning_effort.py[686-744]
### Suggested fix
Add tests for:
- `model="azure/gpt-5"` with `self.azure` false: assert the provider prefix is preserved (or assert the intended behavior explicitly).
- Azure mode (`OPENAI.API_TYPE=azure` or `AZURE_AD.*` set) with provider-qualified model strings: assert GPT-5 detection still triggers and `temperature` is removed.
- Ensure no double-prefixing occurs in the final `call_kwargs['model']`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

  • Author self-review: I have reviewed the code review findings, and addressed the relevant ones.

Previous review results

Review updated until commit 6906cb9

Results up to commit 79513ba


🐞 Bugs (0) 📘 Rule violations (0)


Action required
1. patch() line exceeds 120 ✓ Resolved 📘 Rule violation ⚙ Maintainability
Description
Several newly added with patch(...) lines in the unit tests exceed the repository's 120-character
line limit, which is enforced by the project's Ruff configuration. This can cause lint/CI failures
and reduces readability.
Code

tests/unittest/test_litellm_reasoning_effort.py[707]

+            with patch('pr_agent.algo.ai_handlers.litellm_ai_handler.acompletion', new_callable=AsyncMock) as mock_completion:
Evidence
PR Compliance ID 9 requires respecting the 120-character line length. The newly added `with
patch(...)` statements are written on single lines that exceed this limit.

AGENTS.md
tests/unittest/test_litellm_reasoning_effort.py[707-707]
tests/unittest/test_litellm_reasoning_effort.py[731-731]
tests/unittest/test_litellm_reasoning_effort.py[751-751]
tests/unittest/test_litellm_reasoning_effort.py[782-782]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
New test code introduces lines longer than 120 characters (notably `with patch('pr_agent.algo.ai_handlers.litellm_ai_handler.acompletion', ...)`), violating the repo's 120-character line-length convention.
## Issue Context
`pyproject.toml` configures Ruff with `line-length = 120`, so these lines are likely to fail linting.
## Fix Focus Areas
- tests/unittest/test_litellm_reasoning_effort.py[707-707]
- tests/unittest/test_litellm_reasoning_effort.py[731-731]
- tests/unittest/test_litellm_reasoning_effort.py[751-751]
- tests/unittest/test_litellm_reasoning_effort.py[782-782]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Azure+prefix skips GPT-5 ✓ Resolved 🐞 Bug ≡ Correctness
Description
In Azure mode, chat_completion() prepends azure/ before computing model_base, and the new
removeprefix() chain only removes a single leading provider prefix. If the configured model is
already provider-qualified (e.g. openai/gpt-5* or azure/gpt-5*), model_base can still start
with openai/ or azure/, so the GPT-5 branch is skipped and temperature is sent (triggering the
same LiteLLM UnsupportedParamsError this PR aims to fix).
Code

pr_agent/algo/ai_handlers/litellm_ai_handler.py[R438-440]

+                model_base = model.removeprefix('openai/').removeprefix('azure/')
+                if model_base.startswith('gpt-5'):
              # Use configured reasoning_effort or default to MEDIUM
Evidence
chat_completion() prepends azure/ before the new GPT-5 normalization; the new normalization
removes only one leading prefix, so any provider-qualified model string in Azure mode can still have
a provider segment at the start of model_base and fail GPT-5 detection. Models are sourced from
config/fallbacks without restrictions, so provider-qualified strings are feasible inputs.

pr_agent/algo/ai_handlers/litellm_ai_handler.py[409-413]
pr_agent/algo/ai_handlers/litellm_ai_handler.py[433-461]
pr_agent/algo/pr_processing.py[341-354]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
In `LiteLLMAIHandler.chat_completion()`, GPT-5 detection relies on `model_base` computed via `removeprefix('openai/').removeprefix('azure/')`. When `self.azure` is enabled, the function prepends `azure/` to the model first; if the incoming model already has a provider prefix, the resulting string can contain multiple provider segments (e.g. `azure/openai/gpt-5...` or `azure/azure/gpt-5...`). The current normalization removes at most one leading prefix, so `model_base` may still begin with a provider segment and fail `startswith('gpt-5')`, causing `temperature` to be passed to GPT-5.
### Issue Context
Models come directly from user configuration/fallback lists and can be provider-qualified strings.
### Fix Focus Areas
- pr_agent/algo/ai_handlers/litellm_ai_handler.py[409-413]
- pr_agent/algo/ai_handlers/litellm_ai_handler.py[433-461]
- pr_agent/algo/pr_processing.py[341-354]
### Suggested fix
Refactor provider handling so you do not build composite provider prefixes:
1) Determine/normalize the provider prefix separately from the model name (don’t mutate `model` with `'azure/' + model` before parsing).
2) Strip provider prefixes in a loop (or parse once) until the remaining model name is the real base (`gpt-5...`).
3) Then rebuild the final routed model string once (provider + base model), ensuring exactly one provider prefix.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Provider prefix overridden ✓ Resolved 🐞 Bug ≡ Correctness
Description
For GPT-5 models, the new reroute code rebuilds model using `provider_prefix = 'azure/' if
self.azure else 'openai/' after stripping any leading openai/ or azure/` from the input. This
can silently change an explicitly provided provider-qualified model like azure/gpt-5... into
openai/gpt-5... when self.azure is false, routing the request to the wrong provider.
Code

pr_agent/algo/ai_handlers/litellm_ai_handler.py[R458-460]

+                    # Preserve azure/ routing if it was applied above; otherwise route via openai/
+                    provider_prefix = 'azure/' if self.azure else 'openai/'
+                    model = provider_prefix + model_base.replace('_thinking', '')  # remove _thinking suffix
Evidence
The GPT-5 reroute path always reconstructs the model using a prefix derived only from self.azure,
after explicitly removing any openai/ or azure/ prefix from the input. Since model values come
from config/fallback lists, an explicitly provider-qualified model string can be rewritten to a
different provider.

pr_agent/algo/ai_handlers/litellm_ai_handler.py[438-460]
pr_agent/algo/pr_processing.py[341-354]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
When the GPT-5 branch runs, the code strips a leading provider prefix into `model_base` and then forces the rebuilt provider prefix based on `self.azure`. If the user explicitly passed a provider-qualified model (e.g. `azure/gpt-5...`) while `self.azure` is false, the handler rewrites it to `openai/gpt-5...`.
### Issue Context
The system pulls model strings directly from user config + fallback models; these values may include provider prefixes.
### Fix Focus Areas
- pr_agent/algo/ai_handlers/litellm_ai_handler.py[438-460]
- pr_agent/algo/pr_processing.py[341-354]
### Suggested fix
Preserve the explicit provider prefix when present:
- Parse the incoming `model` into `(explicit_provider_prefix, model_name)` if it starts with `openai/` or `azure/`.
- Choose the provider prefix as:
- `azure/` if `self.azure` is true (Azure mode), else
- `explicit_provider_prefix` if present, else
- default `openai/`.
- Rebuild `model` from that chosen prefix + stripped base model (and apply `_thinking` removal on the base model).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended
4. Tests don’t control env state ✓ Resolved 📘 Rule violation ☼ Reliability
Description
The newly added unit tests instantiate LiteLLMAIHandler() without explicitly setting/deleting
environment variables that its constructor reads, which can make the tests flaky in environments
where variables like AWS_USE_IMDS or OPENAI_API_KEY are set. This violates the requirement to
explicitly control env/process-global state in tests.
Code

tests/unittest/test_litellm_reasoning_effort.py[R713-718]

+                handler = LiteLLMAIHandler()
+                await handler.chat_completion(
+                    model=model,
+                    system="test system",
+                    user="test user"
+                )
Evidence
PR Compliance ID 17 requires tests to explicitly set/delete environment variables and global state
they depend on. The added tests instantiate LiteLLMAIHandler() (new lines) while the handler
constructor branches on environment variables, so the tests should proactively set/delenv relevant
variables (or assert preconditions) to avoid hidden coupling to the runner environment.

tests/unittest/test_litellm_reasoning_effort.py[713-718]
pr_agent/algo/ai_handlers/litellm_ai_handler.py[51-59]
Best Practice: Learned patterns

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
New tests create `LiteLLMAIHandler()` but do not explicitly control environment variables/process-global state that the handler reads during `__init__`, which can cause flaky behavior depending on the runner environment.
## Issue Context
`LiteLLMAIHandler.__init__()` reads env vars (e.g., `OPENAI_API_KEY`, `AWS_USE_IMDS`) and may execute different initialization paths based on them.
## Fix Focus Areas
- tests/unittest/test_litellm_reasoning_effort.py[688-812]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


5. Azure cases untested ✓ Resolved 🐞 Bug ⚙ Maintainability
Description
The added unit tests cover only openai/gpt-5* inputs with self.azure false and do not exercise
azure/gpt-5* inputs or Azure-mode behaviors that interact with the new prefix stripping/rerouting.
This leaves the provider-routing and Azure-prefix edge cases unprotected and likely to regress.
Code

tests/unittest/test_litellm_reasoning_effort.py[R699-704]

+        prefixed_models = [
+            "openai/gpt-5",
+            "openai/gpt-5.1-codex",
+            "openai/gpt-5.1-codex-max",
+            "openai/gpt-5.4-mini",
+        ]
Evidence
Group 8 introduces provider-prefix handling tests but only lists openai/... models; there are no
corresponding azure/... tests despite code explicitly handling/removing an azure/ prefix.

tests/unittest/test_litellm_reasoning_effort.py[686-744]
pr_agent/algo/ai_handlers/litellm_ai_handler.py[438-460]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Current tests validate `openai/gpt-5*` prefixed inputs but do not cover `azure/gpt-5*` or Azure-mode (`self.azure==True`) interactions with the new prefix normalization and reroute logic.
### Issue Context
Prefix handling logic now strips/rebuilds provider prefixes for GPT-5; without tests for `azure/` and Azure mode, bugs in provider routing/detection can slip through.
### Fix Focus Areas
- tests/unittest/test_litellm_reasoning_effort.py[686-744]
### Suggested fix
Add tests for:
- `model="azure/gpt-5"` with `self.azure` false: assert the provider prefix is preserved (or assert the intended behavior explicitly).
- Azure mode (`OPENAI.API_TYPE=azure` or `AZURE_AD.*` set) with provider-qualified model strings: assert GPT-5 detection still triggers and `temperature` is removed.
- Ensure no double-prefixing occurs in the final `call_kwargs['model']`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Results up to commit N/A


🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)


Action required
1. patch() line exceeds 120 ✓ Resolved 📘 Rule violation ⚙ Maintainability
Description
Several newly added with patch(...) lines in the unit tests exceed the repository's 120-character
line limit, which is enforced by the project's Ruff configuration. This can cause lint/CI failures
and reduces readability.
Code

tests/unittest/test_litellm_reasoning_effort.py[707]

+            with patch('pr_agent.algo.ai_handlers.litellm_ai_handler.acompletion', new_callable=AsyncMock) as mock_completion:
Evidence
PR Compliance ID 9 requires respecting the 120-character line length. The newly added `with
patch(...)` statements are written on single lines that exceed this limit.

AGENTS.md
tests/unittest/test_litellm_reasoning_effort.py[707-707]
tests/unittest/test_litellm_reasoning_effort.py[731-731]
tests/unittest/test_litellm_reasoning_effort.py[751-751]
tests/unittest/test_litellm_reasoning_effort.py[782-782]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
New test code introduces lines longer than 120 characters (notably `with patch('pr_agent.algo.ai_handlers.litellm_ai_handler.acompletion', ...)`), violating the repo's 120-character line-length convention.
## Issue Context
`pyproject.toml` configures Ruff with `line-length = 120`, so these lines are likely to fail linting.
## Fix Focus Areas
- tests/unittest/test_litellm_reasoning_effort.py[707-707]
- tests/unittest/test_litellm_reasoning_effort.py[731-731]
- tests/unittest/test_litellm_reasoning_effort.py[751-751]
- tests/unittest/test_litellm_reasoning_effort.py[782-782]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Azure+prefix skips GPT-5 ✓ Resolved 🐞 Bug ≡ Correctness
Description
In Azure mode, chat_completion() prepends azure/ before computing model_base, and the new
removeprefix() chain only removes a single leading provider prefix. If the configured model is
already provider-qualified (e.g. openai/gpt-5* or azure/gpt-5*), model_base can still start
with openai/ or azure/, so the GPT-5 branch is skipped and temperature is sent (triggering the
same LiteLLM UnsupportedParamsError this PR aims to fix).
Code

pr_agent/algo/ai_handlers/litellm_ai_handler.py[R438-440]

+                model_base = model.removeprefix('openai/').removeprefix('azure/')
+                if model_base.startswith('gpt-5'):
               # Use configured reasoning_effort or default to MEDIUM
Evidence
chat_completion() prepends azure/ before the new GPT-5 normalization; the new normalization
removes only one leading prefix, so any provider-qualified model string in Azure mode can still have
a provider segment at the start of model_base and fail GPT-5 detection. Models are sourced from
config/fallbacks without restrictions, so provider-qualified strings are feasible inputs.

pr_agent/algo/ai_handlers/litellm_ai_handler.py[409-413]
pr_agent/algo/ai_handlers/litellm_ai_handler.py[433-461]
pr_agent/algo/pr_processing.py[341-354]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
In `LiteLLMAIHandler.chat_completion()`, GPT-5 detection relies on `model_base` computed via `removeprefix('openai/').removeprefix('azure/')`. When `self.azure` is enabled, the function prepends `azure/` to the model first; if the incoming model already has a provider prefix, the resulting string can contain multiple provider segments (e.g. `azure/openai/gpt-5...` or `azure/azure/gpt-5...`). The current normalization removes at most one leading prefix, so `model_base` may still begin with a provider segment and fail `startswith('gpt-5')`, causing `temperature` to be passed to GPT-5.
### Issue Context
Models come directly from user configuration/fallback lists and can be provider-qualified strings.
### Fix Focus Areas
- pr_agent/algo/ai_handlers/litellm_ai_handler.py[409-413]
- pr_agent/algo/ai_handlers/litellm_ai_handler.py[433-461]
- pr_agent/algo/pr_processing.py[341-354]
### Suggested fix
Refactor provider handling so you do not build composite provider prefixes:
1) Determine/normalize the provider prefix separately from the model name (don’t mutate `model` with `'azure/' + model` before parsing).
2) Strip provider prefixes in a loop (or parse once) until the remaining model name is the real base (`gpt-5...`).
3) Then rebuild the final routed model string once (provider + base model), ensuring exactly one provider prefix.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Provider prefix overridden ✓ Resolved 🐞 Bug ≡ Correctness
Description
For GPT-5 models, the new reroute code rebuilds model using `provider_prefix = 'azure/' if
self.azure else 'openai/' after stripping any leading openai/ or azure/` from the input. This
can silently change an explicitly provided provider-qualified model like azure/gpt-5... into
openai/gpt-5... when self.azure is false, routing the request to the wrong provider.
Code

pr_agent/algo/ai_handlers/litellm_ai_handler.py[R458-460]

+                    # Preserve azure/ routing if it was applied above; otherwise route via openai/
+                    provider_prefix = 'azure/' if self.azure else 'openai/'
+                    model = provider_prefix + model_base.replace('_thinking', '')  # remove _thinking suffix
Evidence
The GPT-5 reroute path always reconstructs the model using a prefix derived only from self.azure,
after explicitly removing any openai/ or azure/ prefix from the input. Since model values come
from config/fallback lists, an explicitly provider-qualified model string can be rewritten to a
different provider.

pr_agent/algo/ai_handlers/litellm_ai_handler.py[438-460]
pr_agent/algo/pr_processing.py[341-354]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
When the GPT-5 branch runs, the code strips a leading provider prefix into `model_base` and then forces the rebuilt provider prefix based on `self.azure`. If the user explicitly passed a provider-qualified model (e.g. `azure/gpt-5...`) while `self.azure` is false, the handler rewrites it to `openai/gpt-5...`.
### Issue Context
The system pulls model strings directly from user config + fallback models; these values may include provider prefixes.
### Fix Focus Areas
- pr_agent/algo/ai_handlers/litellm_ai_handler.py[438-460]
- pr_agent/algo/pr_processing.py[341-354]
### Suggested fix
Preserve the explicit provider prefix when present:
- Parse the incoming `model` into `(explicit_provider_prefix, model_name)` if it starts with `openai/` or `azure/`.
- Choose the provider prefix as:
- `azure/` if `self.azure` is true (Azure mode), else
- `explicit_provider_prefix` if present, else
- default `openai/`.
- Rebuild `model` from that chosen prefix + stripped base model (and apply `_thinking` removal on the base model).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended
4. Tests don’t control env state ✓ Resolved 📘 Rule violation ☼ Reliability
Description
The newly added unit tests instantiate LiteLLMAIHandler() without explicitly setting/deleting
environment variables that its constructor reads, which can make the tests flaky in environments
where variables like AWS_USE_IMDS or OPENAI_API_KEY are set. This violates the requirement to
explicitly control env/process-global state in tests.
Code

tests/unittest/test_litellm_reasoning_effort.py[R713-718]

+                handler = LiteLLMAIHandler()
+                await handler.chat_completion(
+                    model=model,
+                    system="test system",
+                    user="test user"
+                )
Evidence
PR Compliance ID 17 requires tests to explicitly set/delete environment variables and global state
they depend on. The added tests instantiate LiteLLMAIHandler() (new lines) while the handler
constructor branches on environment variables, so the tests should proactively set/delenv relevant
variables (or assert preconditions) to avoid hidden coupling to the runner environment.

tests/unittest/test_litellm_reasoning_effort.py[713-718]
pr_agent/algo/ai_handlers/litellm_ai_handler.py[51-59]
Best Practice: Learned patterns

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
New tests create `LiteLLMAIHandler()` but do not explicitly control environment variables/process-global state that the handler reads during `__init__`, which can cause flaky behavior depending on the runner environment.
## Issue Context
`LiteLLMAIHandler.__init__()` reads env vars (e.g., `OPENAI_API_KEY`, `AWS_USE_IMDS`) and may execute different initialization paths based on them.
## Fix Focus Areas
- tests/unittest/test_litellm_reasoning_effort.py[688-812]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


5. Azure cases untested ✓ Resolved 🐞 Bug ⚙ Maintainability
Description
The added unit tests cover only openai/gpt-5* inputs with self.azure false and do not exercise
azure/gpt-5* inputs or Azure-mode behaviors that interact with the new prefix stripping/rerouting.
This leaves the provider-routing and Azure-prefix edge cases unprotected and likely to regress.
Code

tests/unittest/test_litellm_reasoning_effort.py[R699-704]

+        prefixed_models = [
+            "openai/gpt-5",
+            "openai/gpt-5.1-codex",
+            "openai/gpt-5.1-codex-max",
+            "openai/gpt-5.4-mini",
+        ]
Evidence
Group 8 introduces provider-prefix handling tests but only lists openai/... models; there are no
corresponding azure/... tests despite code explicitly handling/removing an azure/ prefix.

tests/unittest/test_litellm_reasoning_effort.py[686-744]
pr_agent/algo/ai_handlers/litellm_ai_handler.py[438-460]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Current tests validate `openai/gpt-5*` prefixed inputs but do not cover `azure/gpt-5*` or Azure-mode (`self.azure==True`) interactions with the new prefix normalization and reroute logic.
### Issue Context
Prefix handling logic now strips/rebuilds provider prefixes for GPT-5; without tests for `azure/` and Azure mode, bugs in provider routing/detection can slip through.
### Fix Focus Areas
- tests/unittest/test_litellm_reasoning_effort.py[686-744]
### Suggested fix
Add tests for:
- `model="azure/gpt-5"` with `self.azure` false: assert the provider prefix is preserved (or assert the intended behavior explicitly).
- Azure mode (`OPENAI.API_TYPE=azure` or `AZURE_AD.*` set) with provider-qualified model strings: assert GPT-5 detection still triggers and `temperature` is removed.
- Ensure no double-prefixing occurs in the final `call_kwargs['model']`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Qodo Logo

Comment on lines 438 to 440
model_base = model.removeprefix('openai/').removeprefix('azure/')
if model_base.startswith('gpt-5'):
# Use configured reasoning_effort or default to MEDIUM

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. Azure+prefix skips gpt-5 🐞 Bug ≡ Correctness

In Azure mode, chat_completion() prepends azure/ before computing model_base, and the new
removeprefix() chain only removes a single leading provider prefix. If the configured model is
already provider-qualified (e.g. openai/gpt-5* or azure/gpt-5*), model_base can still start
with openai/ or azure/, so the GPT-5 branch is skipped and temperature is sent (triggering the
same LiteLLM UnsupportedParamsError this PR aims to fix).
Agent Prompt
### Issue description
In `LiteLLMAIHandler.chat_completion()`, GPT-5 detection relies on `model_base` computed via `removeprefix('openai/').removeprefix('azure/')`. When `self.azure` is enabled, the function prepends `azure/` to the model first; if the incoming model already has a provider prefix, the resulting string can contain multiple provider segments (e.g. `azure/openai/gpt-5...` or `azure/azure/gpt-5...`). The current normalization removes at most one leading prefix, so `model_base` may still begin with a provider segment and fail `startswith('gpt-5')`, causing `temperature` to be passed to GPT-5.

### Issue Context
Models come directly from user configuration/fallback lists and can be provider-qualified strings.

### Fix Focus Areas
- pr_agent/algo/ai_handlers/litellm_ai_handler.py[409-413]
- pr_agent/algo/ai_handlers/litellm_ai_handler.py[433-461]
- pr_agent/algo/pr_processing.py[341-354]

### Suggested fix
Refactor provider handling so you do not build composite provider prefixes:
1) Determine/normalize the provider prefix separately from the model name (don’t mutate `model` with `'azure/' + model` before parsing).
2) Strip provider prefixes in a loop (or parse once) until the remaining model name is the real base (`gpt-5...`).
3) Then rebuild the final routed model string once (provider + base model), ensuring exactly one provider prefix.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment thread pr_agent/algo/ai_handlers/litellm_ai_handler.py Outdated
@sizickp sizickp force-pushed the fix/gpt-5-prefix-detection branch from b7fe4eb to 0d9006b Compare May 18, 2026 10:38
@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented May 18, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit 0d9006b

Comment thread tests/unittest/test_litellm_reasoning_effort.py Outdated
@sizickp sizickp force-pushed the fix/gpt-5-prefix-detection branch from 0d9006b to 8c4377f Compare May 18, 2026 10:54
@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented May 18, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit 8c4377f

Sergey Petrov added 2 commits May 18, 2026 14:44
…efixes

Address two routing issues raised by the Qodo review on the initial fix:

1. Stacked prefixes (Azure mode + provider-qualified config). With
   self.azure prepending "azure/" to a model that already had an
   "openai/" or "azure/" prefix in config, the single removeprefix()
   call left a residual provider segment, GPT-5 detection failed, and
   temperature was still sent (the original bug this PR fixes).
2. Explicit "azure/" rewritten to "openai/" when self.azure was false.
   The previous rebuild used "azure/ if self.azure else openai/",
   which ignored an explicit "azure/" the user had written in config
   and silently rerouted the request to OpenAI.

Strip provider prefixes in a loop so any number of stacked segments is
removed, and choose the rebuilt prefix by priority: Azure mode >
explicit prefix in user config > "openai/" default. Capture the user's
original model string before the azure auto-prepend so the explicit
prefix is still visible at rebuild time.

Tests added for:
- explicit "azure/" preserved when self.azure is false
- Azure mode with bare / openai/- / azure/- prefixed configs all
  producing exactly one "azure/" prefix
Four `with patch(...)` statements in the GPT-5 provider-prefix tests
exceeded the repo's 120-character line limit (ruff line-length=120 in
pyproject.toml). Wrap them onto multiple lines so the test file does
not regress lint compliance for the newly added cases.
@sizickp sizickp force-pushed the fix/gpt-5-prefix-detection branch from 8c4377f to 66026ff Compare May 18, 2026 11:44
@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented May 18, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit 66026ff

Address Qodo review feedback: the added Group 8 tests instantiate
LiteLLMAIHandler() directly, and its __init__ branches on environment
variables such as AWS_USE_IMDS, OPENAI_API_KEY, and the AWS_* set. With
those vars potentially leaking from the runner environment, the tests
could behave differently across machines or CI runners (e.g. attempt
boto3 import when AWS_USE_IMDS is set).

Explicitly delete the relevant env vars via monkeypatch.delenv() at the
start of each new test, so the constructor takes a deterministic path
regardless of where the suite runs.
@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented May 18, 2026

Copy link
Copy Markdown
Contributor

Persistent review updated to latest commit 79513ba

@CzechExplorer

This comment was marked as spam.

@CzechExplorer

This comment was marked as spam.

@naorpeled

Copy link
Copy Markdown
Member

The fix is correct, but it's local to the GPT-5 branch — the same prefix-detection bug it fixes still bites non–GPT-5 models through the capability gates right below, and Azure mode makes it worse.

Same bug, other gates

chat_completion resolves capabilities via exact-match membership against lists of bare model names:

if model in self.user_message_only_models ...            # ~L457
if model not in self.no_support_temperature_models ...    # ~L473  ← adds temperature
if model in self.support_reasoning_models ...             # ~L483
if model in self.claude_extended_thinking_models ...      # ~L500

But pr_agent/algo/__init__.py lists the OpenAI reasoning models bare only (o1, o3, o3-mini, o4-mini) — no openai/ or azure/ variants. So with a provider prefix in [config].model:

  • model = "openai/o3""openai/o3" not in NO_SUPPORT_TEMPERATURE_MODELS is Truetemperature=0.2 is sent → litellm rejects it (o-series reasoning models don't accept temperature). That's the exact same failure class as the GPT-5 bug this PR fixes, just on a non-GPT model — and this PR doesn't address it. The same model also misses support_reasoning_models, so it silently loses reasoning_effort.

The tell that the matching is prefix-fragile: NO_SUPPORT_TEMPERATURE_MODELS already has to enumerate every Claude prefix permutation by hand (claude-opus-4-8, anthropic/claude-opus-4-8, vertex_ai/..., several bedrock/...).

Azure amplifies it

In Azure mode the handler unconditionally prepends azure/ to every model (model = 'azure/' + model), and there are zero azure/-prefixed entries in any of those four lists. So on Azure, an o3/o4-mini/opus model becomes azure/..., misses all the capability sets, and gets the wrong temperature/reasoning handling. This PR fixes the GPT-5 branch for Azure but leaves these gates broken.

(Separately: Azure also uses arbitrary deployment names rather than model IDs, so azure/<deployment> won't match even after normalization — but that's a deeper mapping concern, not this prefix bug.)

Suggestion

Compute the normalized base name once (the model_base this PR already introduces) and route all capability lookups through it — temperature, reasoning, user-message, claude-thinking — instead of patching only the GPT-5 site. That would also let the lists drop the hand-maintained prefix permutations. Worth adding regression cases for openai/o3 and azure/o3 (temperature dropped) alongside the GPT-5 ones.

# Conflicts:
#	pr_agent/algo/ai_handlers/litellm_ai_handler.py
@naorpeled

naorpeled commented Jul 3, 2026

Copy link
Copy Markdown
Member

Resolved the merge conflict and finalized this from my side

  • Resolved the conflict with main. It was a small overlap in chat_completion: this PR captures user_model, and main added the Databricks capture (is_databricks + if self.azure and not is_databricks:) at the same spot. Kept both — they're independent (Databricks models aren't touched by the openai//azure/ normalization, so the two features don't interact).
  • Verified the fix and that Qodo's earlier findings are already addressed in the current commits: the while-loop strips stacked prefixes (azure/openai/gpt-5…), and the provider-prefix rebuild preserves an explicit azure/ from user config (covered by test_gpt5_with_explicit_azure_prefix_preserves_routing). No lines exceed 120 chars.
  • Tests: all 5 test_litellm_* modules pass locally — 97 passed, Databricks provider tests alongside the GPT-5 reasoning-effort tests.

Clean, surgical fix for a real "primary model always fails → silent fallback" bug. Thanks @sizickp!

@naorpeled naorpeled merged commit c8852c1 into The-PR-Agent:main Jul 3, 2026
5 checks passed
@qodo-free-for-open-source-projects

Copy link
Copy Markdown
Contributor

Code review by qodo was updated up to the latest commit 6906cb9

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants