HYBIM-1011 Upgrade openai to 3.x.x(BLOCKED)

[ridhima-splunk]

Before PR changes trace
After trace

What was successfully removed: litellm as an explicit dependency — from handler.py, [project.optional-dependencies], and [tool.poetry.dependencies]. Token counts continue to work via LLMCallCompletedEvent on the crewai event bus.

What is still blocked: poetry lock cannot succeed because crewai (any version through 0.203.2 and 1.x) transitively depends on instructor, which requires openai <3.0.0. Poetry 2.x resolves all optional extras together so the conflict is
unavoidable in a single lockfile.

Root cause: instructor hasn't released support for openai 3.x yet. Until it does, openai 3.x and crewai cannot share a poetry.lock. This is an upstream ecosystem issue — nothing we can change in this repo today will resolve it.

crewai 0.x is essentially end-of-life. It will almost certainly never get openai 3.x support — that's what crewai 1.x is for. And crewai 1.x dropped litellm as a hard dependency precisely because they moved away from that architecture.

So keeping litellm + crewai <0.177 is a dead end for openai 3.x. The only realistic path is what we already did:

• Drop litellm
• Bump crewai to >=0.177.0
• Wait for instructor (the one remaining blocker) to support openai 3.x

[ridhima-cisco]

poetry.lock regeneration blocked by litellm conflict

litellm >=1.83.14,<2.0.0 (required by the crewai extra) hard-requires openai <3.0.0 in all versions up to and including 1.99.0rc1 (latest as of 2026-08-27). Poetry resolves all optional extras together, so openai >=3.0.0 and litellm cannot coexist in a single poetry.lock.

This means poetry lock fails until one of:

1. litellm ships a release with openai >=3.0.0 support (not yet available)
2. The crewai/litellm extra is moved to a separate Poetry dependency group decoupled from the main resolution

What was fixed in this PR:

• openai bumped to >=3.0.0,<4.0.0 in all four places in pyproject.toml
• openai-agents bumped to >=0.21.0,<1.0.0 (first version requiring openai 3.x)
• test_openai_agents.py: replaced respx + httpx.Response with httpx2.MockTransport + OpenAIProvider(openai_client=...) — needed because openai 3.x uses httpx2 internally and respx 0.22 cannot intercept httpx2 requests
• Removed explicit httpx2 dev dependency (installed transitively by openai 3.x)

CI failures are solely due to the stale poetry.lock — the lockfile cannot be regenerated until the litellm conflict is resolved upstream.

[ridhima-cisco]

Updated: root cause of poetry.lock conflict

The lockfile cannot be regenerated until instructor (a required transitive dep of crewai) releases support for openai >= 3.0.0.

Dependency chain:

crewai (>=0.177.0) → instructor (>=1.3.3) → openai <3.0.0

Every version of instructor through 1.16.0 (latest as of 2026-08-28) hard-requires openai <3.0.0. Poetry 2.x resolves all optional extras together so the conflict is unavoidable in a single lockfile.

What changed in this PR:

• openai bumped to >=3.0.0,<4.0.0; openai-agents bumped to >=0.21.0,<1.0.0
• litellm removed as an explicit dependency — token counts for crewai are now sourced entirely from LLMCallCompletedEvent on the crewai event bus (available since crewai 0.177.0)
• crewai lower bound bumped to >=0.177.0 to match — crewai 0.152–0.176 used litellm as the only token data source, which is no longer supported
• test_openai_agents.py: replaced respx + httpx.Response with httpx2.MockTransport + OpenAIProvider(openai_client=...) — openai 3.x uses httpx2 internally and respx 0.22 cannot intercept httpx2 requests
• litellm and crewai 0.x-specific code removed from handler.py and test_crewai_handler.py

Action needed: once instructor releases a version with openai >=3.0.0 support, run poetry lock and push the updated lockfile to unblock CI.