chore(deps): declare OpenAI 1.66.2 as supported floor

[isaacbmiller]

Summary

DSPy currently claims OpenAI 0.28.1 is supported, but shipped code already depends on the v1 SDK and on the corrected Responses reasoning schema. This PR makes the package contract truthful:

- "openai>=0.28.1"
+ "openai>=1.66.2"

The same requirement is mirrored in uv.lock. No OpenAI package, hash, transitive dependency, or runtime code changes.

Review dossier

1. Issue / repro

The declared floor and the shipped API surface disagree.

DSPy declares:

"openai>=0.28.1"

But shipped runtime paths use v1-only entry points:

from openai import OpenAI

openai.fine_tuning.jobs.retrieve(job_id)
openai.files.retrieve(file_id)

DSPy also processes Responses reasoning summaries:

elif output_item_type == "reasoning":
    if getattr(output_item, "summary", None):
        for summary_item in output_item.summary:
            reasoning_contents.append(summary_item.text)

An isolated OpenAI 0.28.1 probe confirms that OpenAI, fine_tuning, and files are all absent. The current metadata therefore advertises an SDK generation the shipped code cannot execute.

2. Why this is the root cause

The >=0.28.1 floor is legacy metadata from the period when DSPy deliberately supported both OpenAI 0.x and 1.x. It remained after DSPy adopted:

• the v1 client and module-level resource proxies;
• typed v1 API errors;
• the Responses API and reasoning summaries.

The lockfile masks the stale declaration because development and CI already resolve OpenAI 1.75 or 1.88.

3. How we know 1.66.2 is the correct boundary

This does not rest on one test.

Evidence	Result
OpenAI 0.28.1 runtime probe	No OpenAI, fine_tuning, files, or v1 error classes
Lowest LiteLLM-compatible graph	LiteLLM 1.64.1 resolves OpenAI 1.66.1
OpenAI 1.66.1 negative control	v1 resources exist, but the corrected ResponseReasoningItem schema is absent
OpenAI 1.66.2 positive control	v1 resources, typed errors, and a constructed Responses reasoning summary all work
Current DSPy lock	Already newer: OpenAI 1.75 / 1.88

The upstream release history explains the patch boundary:

• OpenAI 1.66.0 introduced the Responses API and built-in tools.
• OpenAI 1.66.1 was an intermediate release.
• OpenAI 1.66.2 shipped only 75 minutes later specifically to correct the Responses reasoning output type.

So 1.66.2 is the first corrected release for the complete OpenAI surface DSPy ships—not simply the version that makes a fixture import.

4. Why this fix is concise

The entire PR is two metadata substitutions across two files:

# pyproject.toml
- "openai>=0.28.1",
+ "openai>=1.66.2",

# uv.lock project metadata
- { name = "openai", specifier = ">=0.28.1" },
+ { name = "openai", specifier = ">=1.66.2" },

There is:

• no SDK upgrade;
• no compatibility shim or fallback;
• no runtime branch;
• no unrelated lock refresh;
• no change to OpenAI 2.x support.

5. Context needed to validate it

This is a lower-bound correction, not the separate Dependabot upgrade to OpenAI 2.x.

Contract layer	Version
stale direct declaration	0.28.1
effective transitive floor before this PR	1.66.1
first corrected full-surface release	1.66.2
locked versions	1.75 / 1.88

The practical compatibility cost is intentionally narrow: downstream environments pinned at or below 1.66.1 will now fail resolution. Normal DSPy installs already resolve at least 1.66.1 through LiteLLM, and 1.66.2 followed 1.66.1 by 75 minutes.

A full uv lock --check also detects a pre-existing unrelated mismatch in DSPy's own recorded version (3.2.1 vs 3.3.0b1). This PR deliberately excludes that line to preserve the two-line scope.

6. What the fix does

The wheel now publishes:

Requires-Dist: openai>=1.66.2

That prevents installers from selecting SDKs that cannot represent the full OpenAI behavior DSPy ships, while preserving the exact packages used by current development and CI.

Verification

• Exact-minimum probe: LiteLLM 1.64.1 + OpenAI 1.66.2 passed v1 resource, typed-error, and Responses reasoning-schema checks.
• Below-floor control: OpenAI 1.66.1 lacked ResponseReasoningItem as expected.
• OpenAI 0.28.1 control: OpenAI, fine_tuning, files, and v1 errors were absent.
• uv sync --all-extras --frozen — passed without changing the lock.
• uv run --frozen pytest --deno -q tests/clients — 133 passed, 21 skipped.
• uv run --frozen pytest --deno -q tests/adapters/test_json_adapter.py -k responses — 1 passed.
• uv build --out-dir /tmp/dspy-openai-floor-dist — wheel and sdist built.
• Built wheel metadata contains Requires-Dist: openai>=1.66.2.
• uv run --frozen pre-commit run --all-files — passed.
• git diff --check cmpnd/main..HEAD — clean.

Scope

One commit. Two files. Two changed metadata lines.

[greptile-apps]

Greptile Summary

This PR updates DSPy's declared OpenAI dependency floor.

• pyproject.toml now requires openai>=1.66.2.
• uv.lock mirrors the same project metadata requirement.
• The resolved OpenAI versions in the lock stay unchanged.

Confidence Score: 5/5

This looks safe to merge.

No blocking issues were found in the changed code. The lock already resolves OpenAI to versions above the new floor, and the project Python range remains compatible with the resolved OpenAI packages.

No files need attention.

T-Rex Logs

What T-Rex did

• Ran the probe to validate the environment; it completed with exit code 0, confirmed OpenAI version 1.75.0, and showed dspy is a required dependency.
• Confirmed the wheel build completed successfully with exit code 0.
• Checked the wheel metadata to confirm the dependency openai>=1.66.2 is declared in the built wheel.
• Ran the Responses adapter tests and they passed.

_{Ran code and verified through T-Rex}

Important Files Changed

Filename	Overview
pyproject.toml	Raises the published OpenAI lower bound to match the SDK surface used by the package.
uv.lock	Mirrors the updated OpenAI requirement in the locked project metadata without changing resolved packages.

_{Reviews (1): Last reviewed commit: "chore(deps): declare OpenAI 1.66.2 as su..." | Re-trigger Greptile}