[Fix] Request Timeout needs to be also fetched from litellm_settings.request_timeout

[harish876]

Relevant issues

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• [ X] I have Added testing in the tests/test_litellm/ directory, Adding at least 1 test is a hard requirement - see details
• My PR passes all unit tests on make test-unit
• My PR's scope is as isolated as possible, it only solves 1 specific problem
• I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

CI (LiteLLM team)

CI status guideline:

• 50-55 passing tests: main is stable with minor issues.
• 45-49 passing tests: acceptable but needs attention
• <= 40 passing tests: unstable; be careful with your merges and assess the risk.

• Branch creation CI run
  Link:

• CI run for the last commit
  Link:

• Merge / cherry-pick CI run
  Links:

Screenshots / Proof of Fix

Type

🆕 New Feature
🐛 Bug Fix
🧹 Refactoring
📖 Documentation
🚄 Infrastructure
✅ Test

Changes

litellm/main.py

• Added _resolve_completion_timeout() with an explicit None chain (avoids or/truthiness bugs):

  1. Named timeout argument
  2. kwargs["timeout"]
  3. kwargs["request_timeout"] (model / deployment alias)
  4. getattr(litellm, "request_timeout", None) — picks up litellm_settings.request_timeout after proxy config load
  5. Default 600 seconds

• Preserved httpx.Timeout behavior: unchanged for providers where supports_httpx_timeout is true; otherwise coerce using read timeout (or 600.0).

• completion() sets timeout = _resolve_completion_timeout(...) so all provider branches (including azure_ai → azure_anthropic_chat_completions.completion) see the same resolved value.

• Docstring on the helper describes sources: deployment/model config vs litellm_settings.request_timeout.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
litellm	Ready	Preview, Comment	Apr 14, 2026 3:17am

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[codspeed-hq]

Merging this PR will not alter performance

✅ 16 untouched benchmarks

---

_{Comparing harish876:azure-anthropic-timeout-bug (fdccbcb) with main (e64d98f)}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[greptile-apps]

Greptile Summary

This PR fixes completion() not picking up litellm_settings.request_timeout from proxy config by extracting timeout resolution into a dedicated _resolve_completion_timeout() helper. The helper uses an explicit None-chain (named arg → kwargs["timeout"] → kwargs["request_timeout"] → litellm.request_timeout → 600 s fallback), replaces the old truthiness-based or chain that would silently skip a timeout=0, and introduces a sentinel comparison to preserve the pre-existing 600 s completion default when litellm.request_timeout still holds the package default of 6000 s.

Confidence Score: 5/5

• Safe to merge; the core logic is correct and backward-compatible, with one minor test coverage gap in the sentinel branch.
• All findings are P2. The sentinel correctly handles every production scenario — existing callers without an explicit timeout still get 600 s, and proxy operators who set a non-default request_timeout now have it respected in completion(). The only gap is that the sentinel branch itself (litellm.request_timeout == 6000.0 → 600 s) is not directly exercised by a unit test, but the logic is straightforward and the surrounding paths are well covered.
• tests/test_litellm/test_completion_timeout_resolution.py — add a test with litellm.request_timeout = 6000.0 to cover the sentinel branch

Important Files Changed

Filename	Overview
litellm/main.py	Extracts timeout resolution into _resolve_completion_timeout() with an explicit None-chain; correctly handles httpx.Timeout coercion and the sentinel to distinguish the package default (6000 s) from an operator-supplied value.
litellm/constants.py	Introduces DEFAULT_REQUEST_TIMEOUT_SECONDS = 6000.0 as an importable sentinel; request_timeout is unchanged in value (6000 s) so Router, speech/TTS, and other subsystems are unaffected.
tests/test_litellm/test_completion_timeout_resolution.py	Good coverage of explicit timeout, kwargs alias, and httpx coercion paths, but the sentinel branch (litellm.request_timeout == 6000.0 → 600 s) — the core production path — is not directly tested.
tests/test_litellm/llms/azure_ai/claude/test_main_azure_anthropic_timeout.py	New mock test verifying that completion() propagates the resolved timeout to the Azure Anthropic handler; clean and well-scoped.
tests/test_litellm/llms/azure_ai/claude/test_azure_anthropic_handler.py	Adds assertions that _get_httpx_client and post() both receive the correct timeout; strengthens existing non-streaming test.
tests/test_litellm/llms/custom_httpx/test_http_handler.py	Two new unit tests verify that _get_httpx_client correctly applies both float and httpx.Timeout objects; no real network calls, appropriate for the unit-test folder.
tests/local_testing/test_azure_anthropic_sync_post.py	Integration smoke-test for per-request timeout via httpbin; correctly placed in local_testing (not test_litellm), skips when httpbin is unreachable.
tests/llm_translation/test_azure_openai.py	Adds top-level import httpx alongside existing from httpx import Headers/Client; no functional change.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[completion called] --> B{timeout arg set?}
    B -- yes --> G[use timeout arg]
    B -- no --> C{kwargs timeout set?}
    C -- yes --> G
    C -- no --> D{kwargs request_timeout set?}
    D -- yes --> G
    D -- no --> E{litellm.request_timeout set?}
    E -- no --> F[600 s fallback]
    E -- yes --> H{== DEFAULT_REQUEST_TIMEOUT_SECONDS 6000s?}
    H -- yes sentinel fires --> F
    H -- no operator-set value --> G
    G --> I{httpx.Timeout and provider lacks support?}
    I -- yes --> J[coerce to float read timeout or 600]
    I -- no --> K[float coerce or pass through]
    J --> L[resolved timeout passed to provider]
    K --> L
    F --> K

Loading

_{Reviews (5): Last reviewed commit: "Merge branch 'main' of https://github.co..." | Re-trigger Greptile}

[greptile-apps]

request_timeout default change widens scope beyond completion()

Changing the default from 6000 to 600 fixes the completion() regression flagged in the previous thread, but litellm.request_timeout is also the default for Router.__init__ (self.timeout = timeout or litellm.request_timeout, router.py:530), speech() (main.py:6760), and the Anthropic / Azure-Anthropic / OpenAI count-token handlers. All of these would silently drop from a 6000 s ceiling to 600 s for users who have not set an explicit timeout. Long-running router calls or TTS jobs that complete in 600–6000 s will now time out.

Per the "avoid backwards-incompatible changes without user-controlled flags" rule, consider keeping the constant at 6000 (or introducing a separate COMPLETION_REQUEST_TIMEOUT constant) and only using the explicit-600 fallback inside _resolve_completion_timeout() itself, where you control the scope.

Rule Used: What: avoid backwards-incompatible changes without... (source)

[ishaan-berri]

what problem does this solve ?

[ishaan-berri]

this should be it's own file + class

[ishaan-berri]

• this just solves it for /chat/completions what about /responses, /messages do they have the same bug ?
• IS there a simpler way to fix this across call types

[ishaan-berri]

this section looks super complicated, can you write cleaner code here ?

it's hard to follow how this logic is set

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

Since your pull request originates from a forked repository, GitGuardian is not able to associate the secrets uncovered with secret incidents on your GitGuardian dashboard.
Skipping this check run and merging your pull request will create secret incidents on your GitGuardian dashboard.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
29203053	Triggered	Generic Password	fdccbcb	.circleci/config.yml	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}