Fix common.ai Anthropic models failing against anthropic 1.x in the CI image

[kaxil]

The Common AI provider's Anthropic models cannot be exercised in the CI image or a local breeze checkout. The image installs pydantic-ai-slim 2.31.1 next to anthropic 1.5.0, and that pair fails before any request leaves the process: 2.31 hands the SDK an httpx v1 client that anthropic 1.x rejects (Invalid http_client argument ... this SDK uses httpx2), and even with a pre-built client it passes temperature as a messages.create() kwarg that anthropic 1.x removed. pydantic-ai-slim 2.33.0 fixed both, so this raises the provider's floor to 2.33.0. Users installing the anthropic extra from PyPI already resolve a working version because nothing caps pydantic-ai there; the floor now says so, and the lock and image follow.

The lock could not follow on its own. pydantic-ai-slim[openai]>=2.33 declares openai>=3 (>=3.8 from 2.39), while llama-index-llms-openai 0.8.1 and litellm (pulled in unconditionally by the Google provider's google-cloud-aiplatform[evaluation]) still cap openai below 3. Both caps are stale rather than real: llama-index chat and embeddings work on openai 3.16 (run-llama/llama_index#22939 lifts the cap), and Airflow never imports litellm (BerriAI/litellm#40317). Moving llama-index-llms-openai out of the dev group and declaring the extras as conflicting, the shape one would reach for first, does not help, because litellm is a base dependency of another provider and has no extra to conflict on.

Why the override holds openai on 2.x rather than moving it to 3.x. Overriding to openai>=3.8 also resolves, and the Common AI, OpenAI provider and Google Vertex evaluation suites all pass on it. It fails at image build time instead: Dockerfile.ci runs a bare pip check after install, and that reports llama-index's and litellm's unconditional caps against openai 3. pip check ignores extra-gated requirements, so pydantic-ai's openai>=3.8; extra == "openai" is invisible to it and the 2.x pairing passes. It is also the pairing constraints-main already ships (pydantic-ai-slim 2.44.0 with openai 2.54.0), so the image tests what the constraints lane tests today. pydantic-ai's OpenAI model reaches the API on openai 2.54 at runtime; its declared floor tracks the SDK's httpx2 move. Overrides only shape uv.lock and the image, so published wheels see the floor bump and nothing else. The root pyproject.toml comment names both upstream trackers so the override can be dropped once they land.

With the new lock, inside breeze: pip check is clean, an AnthropicModel request with a dummy key now reaches the API and returns a 401 instead of the TypeError, and the Common AI unit suite (2275 tests), the OpenAI provider suite and the Vertex AI evaluation tests pass. The OpenAI provider's Managed Agents test module skips itself on openai 2.x because it imports an openai 3 type; that skip is unchanged from main.

The lowest-direct-dependency lane needed two more floors, because with openai's constraints overridden it installs the provider's own floors rather than the ones upstream caps used to force. openai 2.45 and 2.46 reject the httpx2 client that pydantic-ai-slim 2.33 hands them, and 2.47.0 is the first release that accepts it, so the openai extra and the override's lower bound both say 2.47.0. llama-index-llms-openai 0.6.0 declares llama-index-core>=0.13.0 but imports a type core only gained in 0.14; 0.6.8 is the first release whose metadata matches its imports, and it needs core 0.14.5, which is what that lane resolved on main anyway. In breeze, breeze testing providers-tests --force-lowest-dependencies --test-type "Providers[common.ai]" now passes all 2278 tests on pydantic-ai-slim 2.33.0, openai 2.47.0 and llama-index-llms-openai 0.6.8.

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.