Upgrade LiteLLM to 1.84.0rc1

[neubig]

• A human has tested these changes.

---

Why

Upgrade LiteLLM to the requested incident-fix release 1.84.0rc1.

Summary

• Pins openhands-sdk's LiteLLM dependency to 1.84.0rc1.
• Regenerates uv.lock for the workspace using --upgrade-package litellm to minimize churn.
• openai (2.24.0 → 2.33.0) and tokenizers (0.22.2 → 0.23.1) are also updated because litellm 1.84.0rc1 pins them as exact dependencies. No other packages are changed.

Issue Number

N/A

How to Test

• Parsed modified pyproject.toml with Python tomllib.
• Ran uv lock --check --exclude-newer-package litellm=2026-05-06T00:00:00Z from the repository root.

Video/Screenshots

N/A - dependency upgrade only.

Type

• Bug fix
• Feature
• Refactor
• Breaking change
• Docs / chore

Notes

The package-specific exclude-newer override is needed because this repo has a workspace-wide exclude-newer = "7 days" guardrail, while litellm==1.84.0rc1 was uploaded on 2026-05-05.

This PR was created by an AI agent (OpenHands) on behalf of the user.

[github-actions]

Python API breakage checks — ❌ FAILED

Result: ❌ FAILED

⚠️ Breaking API changes or policy violations detected.

Log excerpt (first 1000 characters)

Resolving despite existing lockfile due to removal of exclude newer for package `litellm`
  × No solution found when resolving dependencies for split (markers:
  │ python_full_version >= '3.14'):
  ╰─▶ Because litellm==1.84.0rc1 was published after the exclude newer time
      and openhands-sdk depends on litellm==1.84.0rc1, we can conclude that
      openhands-sdk's requirements are unsatisfiable.
      And because your workspace requires openhands-sdk[boto3], we can
      conclude that your workspace's requirements are unsatisfiable.

      hint: While the active Python version is 3.13, the resolution failed for
      other Python versions supported by your project. Consider limiting your
      project's supported Python versions using `requires-python`.

Action log

[github-actions]

REST API breakage checks (OpenAPI) — ❌ FAILED

Result: ❌ FAILED

⚠️ Breaking REST API changes or policy violations detected.

Log excerpt (first 1000 characters)

Resolving despite existing lockfile due to removal of exclude newer for package `litellm`
  × No solution found when resolving dependencies for split (markers:
  │ python_full_version >= '3.14'):
  ╰─▶ Because litellm==1.84.0rc1 was published after the exclude newer time
      and openhands-sdk depends on litellm==1.84.0rc1, we can conclude that
      openhands-sdk's requirements are unsatisfiable.
      And because your workspace requires openhands-sdk[boto3], we can
      conclude that your workspace's requirements are unsatisfiable.

      hint: While the active Python version is 3.13, the resolution failed for
      other Python versions supported by your project. Consider limiting your
      project's supported Python versions using `requires-python`.

Action log

[all-hands-bot]

⚠️ Supply Chain Timing Alert: litellm==1.84.0rc1 was uploaded less than 7 days ago (by ~30 minutes), violating the repo's supply chain guardrail. While this is an intentional override for an incident fix, recommend either (1) waiting ~30 minutes for the 7-day window to pass, or (2) explicit human maintainer approval of the supply chain risk vs incident urgency trade-off.

[all-hands-bot]

🟠 Supply Chain Risk: litellm==1.84.0rc1 was uploaded on 2026-05-05T23:28:26Z (per uv.lock metadata). Current time is 2026-05-12T22:59:16Z, which is approximately 6 days, 23.5 hours after upload.

This is within the repo's 7-day supply chain guardrail by about 30 minutes.

Context:

• The PR intentionally overrides this via exclude-newer-package in uv.lock
• The PR description indicates this is a requested "incident-fix release"
• This is different from accidental Dependabot bypasses - the override is deliberate

Additional Risk: This is a release candidate (rc1), not a stable release, which increases supply chain risk.

Recommendation: Either:

1. Wait ~30 minutes for the package to age past the 7-day window, then re-lock
2. Have a human maintainer explicitly approve merging despite the timing (if the incident is urgent enough to justify the supply chain risk)

See repo docs: Supply Chain Security Guidelines for the 7-day guardrail rationale.