chore(deps): bump @ai-sdk/openai from 1.3.24 to 3.0.64

[dependabot]

Bumps @ai-sdk/openai from 1.3.24 to 3.0.64.

Release notes

Sourced from @​ai-sdk/openai's releases.

@​ai-sdk/openai-compatible@​3.0.0-canary.50

Patch Changes

• 7fc6bd6: Raise minimum supported Node.js version to 22. Supported versions: 22, 24, and 26.
• Updated dependencies [7fc6bd6]
  • @​ai-sdk/provider-utils@​5.0.0-canary.43
  • @​ai-sdk/provider@​4.0.0-canary.17

Changelog

Sourced from @​ai-sdk/openai's changelog.

3.0.64

Patch Changes

• b7ed8bd: feat(openai): add opt-in pass-through for unsupported file media types

3.0.63

Patch Changes

• Updated dependencies [f591416]
  • @​ai-sdk/provider-utils@​4.0.27

3.0.62

Patch Changes

• 65edcca: feat: add allowedTools provider option for OpenAI Responses

3.0.61

Patch Changes

• b93f9b4: feat(provider/openai): forward imageDetail providerOptions on tool-result image content

3.0.60

Patch Changes

• 6dcd8e6: feat(openai): add GPT-5.5 chat model IDs

3.0.59

Patch Changes

• 38966ab: fix(openai, openai-compatible): only send null content for assistant messages with tool calls

3.0.58

Patch Changes

• 2370948: feat(openai): preserve namespace on function_call output items

3.0.57

Patch Changes

• d33e7cc: chore(provider/openai): add type for image model options for type-safe processing

3.0.56

... (truncated)

Commits

• 2e7664b Version Packages (#15315)
• b7ed8bd Backport: feat(openai): add opt-in pass-through for unsupported file media ty...
• e3ccdb5 Version Packages (#15094)
• bf9de31 Version Packages (#15046)
• 65edcca Backport: feat(openai): add allowedTools provider option for Responses (#15044)
• ee37690 Version Packages (#15020)
• b93f9b4 Backport: feat(provider/openai): forward imageDetail providerOptions on tool-...
• c706111 Version Packages (#14971)
• 6dcd8e6 Backport: feat(openai): add GPT-5.5 chat model IDs (#14965)
• a1dddcc Version Packages (#14954)
• Additional commits viewable in compare view

Maintainer changes

This version was pushed to npm by GitHub Actions, a new releaser for @​ai-sdk/openai since your current version.

[minsky-reviewer]

Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown

---

Findings

[BLOCKING] Major version bump of @ai-sdk/openai without aligning sibling @ai-sdk/* providers

• File: package.json:84-91 (dependencies block)
• Change: "@ai-sdk/openai": "^1.0.2" → "^3.0.53"
• Related: "@ai-sdk/anthropic": "^1.0.2", "@ai-sdk/google": "^1.0.2" remain on 1.x
• Failure mode: The @ai-sdk provider packages share internal utilities (e.g., @ai-sdk/provider-utils) and tend to evolve in lockstep across majors. The release notes excerpt included in this PR explicitly mentions updated dependency "@ai-sdk/provider-utils@5.0.0-beta.26" for the 3.x line of compatible packages. Upgrading only @ai-sdk/openai to 3.x while leaving @ai-sdk/anthropic and @ai-sdk/google on 1.x risks:
  • Peer dependency/version skew and resolver conflicts
  • Multiple copies of shared internals at different majors
  • Runtime/type incompatibilities if shared helpers or message formats diverged across majors
• Ask: Either upgrade all @ai-sdk/* providers used by the project to the same major (preferably 3.x) and validate compatibility, or keep @ai-sdk/openai on the 1.x line until a coordinated upgrade is done.

[BLOCKING] Potential breaking API changes unaccounted for in codebase

• File: package.json:86 ("@ai-sdk/openai": "^3.0.53")
• Failure mode: A major version bump implies breaking changes. The AI SDK provider API has had breaking shifts across majors (e.g., initialization factory, model naming, message format/fields, streaming tool call handling). This PR contains no corresponding source code changes or migration notes. If the repo imports from "@ai-sdk/openai" anywhere, this can lead to:
  • TypeScript compile errors (changed exports/types)
  • Runtime errors due to changed options or message structure (e.g., tool-only assistant messages now sending content: null vs empty string per included notes)
• Ask: Audit all imports/usages of "@ai-sdk/openai" in the codebase, apply required migration steps for v3, and add/adjust tests covering those paths.

[BLOCKING] Lockfile not updated

• Files: package-lock.json / yarn.lock / pnpm-lock.yaml (root) — no changes in diff
• Failure mode: Without a lockfile update, CI and other environments using the existing lock will not pick up @ai-sdk/openai@3.0.53, causing non-reproducible installs and masking upgrade issues until later. Dependabot PRs for npm/yarn normally include the lockfile.
• Ask: Commit the updated lockfile corresponding to this dependency change. If the repo intentionally does not track a lockfile, state that explicitly in the PR.

[NON-BLOCKING] PR description/version mismatch

• Evidence: PR title/description say “bump from 1.3.24 to 3.0.53”; package.json shows "^1.0.2" → "^3.0.53".
• Impact: Confusion about the actual previous version can obscure whether the upgrade path is correct and which release notes apply.
• Ask: Clarify the prior resolved version (e.g., via the lockfile) and update the PR description accordingly.

[NON-BLOCKING] Potential ESM-only transition

• Context: Several AI SDK packages have moved to ESM-only in recent majors.
• Failure mode: If this project uses CommonJS require() for "@ai-sdk/openai", Node will throw ERR_REQUIRE_ESM at runtime.
• Ask: Confirm the module system for this repo and adjust imports/tsconfig/build config if needed. Add a quick sanity test to ensure the module loads under the project’s Node/toolchain.

[NON-BLOCKING] Release notes in PR don’t correspond to the target version

• Evidence: Embedded notes reference "@ai-sdk/openai-compatible 3.0.0-beta.31" and "@ai-sdk/openai 2.0.103" rather than 3.0.53.
• Impact: Reviewers can’t assess breaking changes accurately from the provided notes.
• Ask: Link to the actual changelog for @ai-sdk/openai@3.0.53 and summarize any breaking changes relevant to this repo.

Spec verification table

• No task spec provided. N/A.

Documentation impact

• Likely yes:
  • If provider initialization/config APIs changed: update any README/examples referencing "@ai-sdk/openai".
  • Note any environment variable or option changes (e.g., tool-call argument defaults, content null/empty behavior).
  • If Node/toolchain requirements changed (e.g., ESM-only, Node >= 18), update contributing/CI docs.

Event: REQUEST_CHANGES

[minsky-reviewer]

Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown

---

Findings

[NON-BLOCKING] Spec/description mismatch on “from” version

• File: package.json: dependencies block
• Evidence: The PR description claims a bump from @ai-sdk/openai 1.3.24 → 3.0.53, but the repo previously had "@ai-sdk/openai": "^1.0.2" and now has "^3.0.53" (package.json lines ~64–86 in dependencies).
• Why it matters: Mismatch between stated and actual change can confuse reviewers and release notes. Please correct the PR description to reflect the true “from” version for this repo.

[NON-BLOCKING] Potential version skew across @ai-sdk/* provider packages

• File: package.json: dependencies block
• Evidence: After this change, providers are:
  • "@ai-sdk/openai": "^3.0.53"
  • "@ai-sdk/anthropic": "^1.0.2"
  • "@ai-sdk/google": "^1.0.2"
• Risk: The @ai-sdk provider packages often share internals (e.g., @ai-sdk/provider-utils) and may evolve in lockstep across majors. Mixing 3.x and 1.x can induce:
  • Multiple incompatible transitive versions of shared utilities
  • Peer dependency or runtime/type incompatibilities when composing providers
• Ask: Confirm compatibility matrix for vercel/ai v4.x ("ai": "^4.1.5" in package.json) with a mixed set of provider majors, or consider aligning anthropic/google to their compatible majors. At minimum, verify lockfile resolution yields a single compatible @ai-sdk/provider-utils version and that tests cover mixed-provider usage.

[NON-BLOCKING] Lockfile not updated with dependency bump

• File: bun.lock
• Evidence: The diff does not show bun.lock changes, while package.json was modified. This repo uses Bun (bun.lock present at repo root).
• Risk: CI/local installs will continue to resolve the old version per existing lockfile, causing non-reproducible states between environments and potentially masking breakages until a separate lockfile update occurs.
• Ask: Commit the updated bun.lock generated by Bun after bumping @ai-sdk/openai.

[NON-BLOCKING] Major version bump without explicit compatibility note or tests targeting breaking areas

• File: package.json: dependencies block
• Evidence: Bumping @ai-sdk/openai 1.x → 3.x is a major upgrade. Release notes include changes around tool-call input defaults and message content handling.
• Risk: Silent behavior changes in request/response shaping could affect user-facing behavior where OpenAI provider is used (e.g., tool-only assistant messages, function call arguments).
• Ask: Link to the specific 2.x/3.x breaking-change notes in the PR (you already linked general release notes), and confirm relevant tests pass against scenarios using tool calls and streaming. If coverage is thin in this repo for those flows, consider adding a minimal smoke test or note why it’s safe.

Spec verification table

• No task spec provided. N/A.

Documentation impact

• No direct docs changes required by this PR. However:
  • Please correct the PR description’s “from” version.
  • If mixed provider majors are intentional and supported, a short note in developer docs or dependency policy documenting the compatibility rationale would help future maintainers.

Event: COMMENT

Notes:

• A prior review raised the provider version skew as BLOCKING. Given this PR is classified as trivial/docs-only, I’m marking it NON-BLOCKING here, but the underlying compatibility risk remains. Please address or explicitly justify the mixed-major setup and update the lockfile.

[minsky-reviewer]

Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown

---

reviewer-service error: chain-of-thought leakage detected

The upstream model emitted raw internal reasoning into the review body. The reviewer service sanitised the output but could not locate a valid Findings section to preserve, so the leaked content was discarded. The PR will receive a fresh review on the next commit. See docs/architecture/critic-constitution-reliability.md for details.

[minsky-reviewer]

Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown

---

This PR bumps @ai-sdk/openai to 3.0.58 in package.json but leaves bun.lock pinned to 1.x, so CI and installs won’t reflect the upgrade. Update and commit bun.lock to make installs reproducible and surface any breaking changes. Non-blocking: clarify the PR’s from-version (repo was on ^1.0.2, lock at 1.3.22, not 1.3.24), and confirm the mixed-major @ai-sdk providers (OpenAI 3.x vs Anthropic/Google 1.x) are intentionally compatible. Also consider a quick sanity check for ESM imports and tool-call/message-shaping changes introduced in v3. With the lockfile updated, this should be ready for re-review.

Findings

• [BLOCKING] bun.lock:8 — Lockfile not updated: bun.lock still pins @ai-sdk/openai 1.x despite package.json bump to 3.x
  package.json now declares "@ai-sdk/openai": "^3.0.58" (see package.json dependencies), but bun.lock still reflects the previous 1.x line:
• bun.lock lines 7–13: top-level workspace dependencies list "@ai-sdk/openai": "^1.0.2".
• bun.lock packages section shows resolution to "@ai-sdk/openai@1.3.22" with transitive deps locked to @ai-sdk/provider-utils@2.2.8 (far below the 3.x line noted in upstream changelogs).
  Without updating and committing bun.lock, CI and other environments will continue to install 1.x, masking breaking changes until later and making installs non-reproducible relative to package.json. Please run your package manager to update bun.lock and include it in this PR.
• [NON-BLOCKING] package.json:74 — Mixed major versions across @ai-sdk/* providers may cause incompatibilities
  After this PR, dependencies include:
• "@ai-sdk/openai": "^3.0.58"
• "@ai-sdk/anthropic": "^1.0.2"
• "@ai-sdk/google": "^1.0.2"
  The vercel/ai provider packages often share internal utilities and evolve together. Mixing 3.x OpenAI with 1.x Anthropic/Google increases risk of multiple @ai-sdk/provider[-utils] versions or subtle type/runtime mismatches when used together. If this project composes responses/tools across providers, verify compatibility. Consider aligning provider majors or documenting why this matrix is supported. At minimum, ensure the updated lockfile resolves a compatible set and add a sanity test using both OpenAI and one 1.x provider.
• [NON-BLOCKING] package.json:1 — PR description claims bump from 1.3.24 → 3.0.58, but repo previously referenced ^1.0.2
  The PR body cites 1.3.24 as the previous version. However, the repo’s package.json changed from "@ai-sdk/openai": "^1.0.2" to "^3.0.58" (see package.json diff at dependencies). bun.lock also shows lock to 1.3.22, not 1.3.24. Please correct the PR description to reflect the actual from-version for this repo (likely ^1.0.2 → ^3.0.58, lock at 1.3.22), so release notes and reviewer expectations match the change.

Inline comments

• package.json:3 — Confirm the codebase imports @ai-sdk/openai using ESM (this project is type: "module"). If earlier versions allowed CJS require(), note that 3.x may be ESM-only — a quick local run or CI job that imports the provider can catch ERR_REQUIRE_ESM regressions.
• package.json:82 — Given the upstream changelog mentions behavior changes like sending content: null for tool-only assistant messages and defaulting undefined tool-call input to {}, do we have tests that cover these flows with the OpenAI provider? If not, consider adding a minimal check to detect regressions from 1.x → 3.x.

Spec verification

Criterion	Status	Evidence
Lockfile must be updated to reflect dependency bumps so CI installs are reproducible.	Not Met	bun.lock at repo root still lists "@ai-sdk/openai": "^1.0.2" in the workspace deps and resolves to packages "@ai-sdk/openai@1.3.22"; package.json declares "@ai-sdk/openai": "^3.0.58".

[minsky-reviewer]

Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown

---

This PR updates package.json to @ai-sdk/openai 3.0.62 but leaves bun.lock unresolved on the 1.x line. The lockfile still pins @ai-sdk/openai@1.3.22, so CI will not exercise the upgraded dependency — this must be fixed before merge. I also noted a mixed-major matrix across @ai-sdk providers (openai 3.x vs anthropic/google 1.x) and suggested verifying compatibility and tests, plus an ESM import reminder. Finally, the PR description’s “from” version doesn’t match the repo’s prior lock. Please update bun.lock to reflect 3.x, clarify the PR description, and confirm provider compatibility; after that, this should be straightforward to merge.

Findings

• [BLOCKING] bun.lock:8 — Lockfile not updated: bun.lock still pins @ai-sdk/openai 1.x despite package.json bump to 3.x
  package.json now declares "@ai-sdk/openai": "^3.0.62" (see the dependencies block), but bun.lock still reflects the previous 1.x line:

• bun.lock top-level workspace dependencies list "@ai-sdk/openai": "^1.0.2" (around lines 6–12).

• bun.lock packages section resolves to "@ai-sdk/openai@1.3.22" with transitive deps locked to @ai-sdk/provider-utils@2.2.8 — far below the 3.x line referenced in upstream changelogs.

Without updating and committing bun.lock, CI and other environments will continue to install 1.x, masking breaking changes until later and making installs non-reproducible relative to package.json. Please run your package manager to update bun.lock and include it in this PR.

• [NON-BLOCKING] package.json:74 — Mixed major versions across @ai-sdk/* providers may cause incompatibilities
  After this PR, dependencies include:

• "@ai-sdk/openai": "^3.0.62"

• "@ai-sdk/anthropic": "^1.0.2"

• "@ai-sdk/google": "^1.0.2"

The vercel/ai provider packages often share internal utilities and evolve together. Mixing 3.x OpenAI with 1.x Anthropic/Google increases risk of multiple @ai-sdk/provider[-utils] versions or subtle type/runtime mismatches when used together. If this project composes responses/tools across providers, verify compatibility. Consider aligning provider majors or documenting why this matrix is supported. At minimum, ensure the updated lockfile resolves a compatible set and that tests cover mixed-provider usage.

• [NON-BLOCKING] package.json:1 — PR description claims bump from 1.3.24 → 3.0.62, but repo previously referenced ^1.0.2
  The PR body cites 1.3.24 as the previous version. However, the repo’s package.json changed from "@ai-sdk/openai": "^1.0.2" to "^3.0.62". The existing bun.lock also shows a lock to @ai-sdk/openai@1.3.22, not 1.3.24. Please correct the PR description to reflect the actual from-version for this repo (^1.0.2 with lock at 1.3.22 → ^3.0.62), so release notes and reviewer expectations match the change.

Inline comments

• package.json:3 — This repo is type: "module". Please confirm all imports of @ai-sdk/openai use ESM import syntax. If any older code used CommonJS require(), v3 of the provider may be ESM-only and could trigger ERR_REQUIRE_ESM at runtime.
• package.json:82 — Upstream changelogs mention behavior changes like sending content: null for tool-only assistant messages and defaults around tool-call inputs. Do we have tests covering these flows with the OpenAI provider? If not, consider adding a minimal check once the lockfile is updated to actually pull 3.x in CI.

Spec verification

Criterion	Status	Evidence
Lockfile must be updated to reflect dependency bumps so CI installs are reproducible.	Not Met	bun.lock at repo root still lists "@ai-sdk/openai": "^1.0.2" in the workspace deps and resolves to packages "@ai-sdk/openai@1.3.22"; package.json declares "@ai-sdk/openai": "^3.0.62".

[minsky-reviewer]

Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown

---

The major version bump to @ai-sdk/openai is present in package.json, but the lockfile was not updated: bun.lock still pins the 1.x line, so CI will not actually install 3.x. This is a repeat of the prior blocking finding and remains unresolved. Please update and commit bun.lock so it resolves @ai-sdk/openai@3.0.63 and corresponding transitive deps.

Non-blocking: you still have mixed majors across @ai-sdk/* providers (openai 3.x vs anthropic/google 1.x); if intentional, confirm compatibility and ensure the updated lockfile yields a coherent set. Also confirm ESM import usage and consider adding a minimal test for tool-call behavior changes in 3.x once the lockfile is updated.

Findings

• [BLOCKING] bun.lock:8 — Lockfile not updated: bun.lock still pins @ai-sdk/openai 1.x despite package.json bump to 3.x
  package.json declares "@ai-sdk/openai": "^3.0.63" now (see package.json dependencies), but bun.lock still reflects the previous 1.x line:

• Top-level workspace dependencies list "@ai-sdk/openai": "^1.0.2" (around bun.lock:6–12).

• The packages section resolves to "@ai-sdk/openai@1.3.22" with transitive deps @ai-sdk/provider-utils@2.2.8 — far below the 3.x line noted in upstream changelogs.

Without updating and committing bun.lock, CI and other environments will continue to install 1.x, masking breaking changes and making installs non-reproducible relative to package.json.

Please run your package manager to update bun.lock and include it in this PR so it resolves @ai-sdk/openai@3.0.63 (and corresponding transitive versions).

• [NON-BLOCKING] package.json:86 — Mixed major versions across @ai-sdk/* providers may cause incompatibilities
  After this change, providers are:

• "@ai-sdk/openai": "^3.0.63"

• "@ai-sdk/anthropic": "^1.0.2"

• "@ai-sdk/google": "^1.0.2"

The AI SDK provider packages often share internals (e.g., @ai-sdk/provider-utils) and tend to evolve together. Mixing 3.x OpenAI with 1.x Anthropic/Google increases risk of multiple @ai-sdk/provider[-utils] versions and subtle type/runtime mismatches when composed.

Action: If mixed majors are intentional, please confirm compatibility for your usage and ensure the updated lockfile resolves a coherent set. Otherwise, consider aligning provider majors or documenting why the matrix is supported.

Inline comments

• package.json:3 — This repo is type: "module". Please confirm all imports of @ai-sdk/openai use ESM import syntax. If any older code used CommonJS require(), v3 may be ESM-only and could trigger ERR_REQUIRE_ESM at runtime once the lockfile is updated to install 3.x.
• package.json:86 — Upstream changelogs for 3.x mention behavior changes (e.g., assistant tool-call messages sending content: null). Once the lockfile is updated, do we have tests covering tool-call flows with the OpenAI provider to catch regressions from 1.x → 3.x? If not, consider adding a minimal smoke test.

Spec verification

Criterion	Status	Evidence
Lockfile must be updated to reflect dependency bumps so CI installs are reproducible.	Not Met	package.json sets "@ai-sdk/openai": "^3.0.63" (see package.json dependencies), but bun.lock still lists "@ai-sdk/openai": "^1.0.2" and resolves to "@ai-sdk/openai@1.3.22" in the packages section.

[minsky-reviewer]

Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown

---

The previous blocking issue remains: bun.lock was not updated to reflect the bump to @ai-sdk/openai@^3.0.63. The lockfile still pins the 1.x line, so CI will not actually install 3.x, hiding compatibility problems and breaking reproducibility. Please update and commit bun.lock so it resolves to 3.x.

I left two minor inline notes regarding ESM import usage and potential behavior changes in 3.x that merit test coverage once the lockfile is refreshed. No other scope creep or legal issues detected. Once the lockfile is corrected, this looks ready to proceed.

Findings

• [BLOCKING] bun.lock:8 — Lockfile not updated: bun.lock still pins @ai-sdk/openai 1.x despite package.json bump to 3.x
  package.json now declares "@ai-sdk/openai": "^3.0.63" (see package.json dependencies), but the committed bun.lock still reflects the old 1.x line:

• Top-level workspace deps list "@ai-sdk/openai": "^1.0.2" around bun.lock:6–12.

• The packages section resolves to "@ai-sdk/openai@1.3.22" with transitive @ai-sdk/provider-utils@2.2.8.

Without updating and committing bun.lock, CI and other environments will continue to install 1.x, masking breaking changes and causing non-reproducible installs relative to package.json. Please run your package manager to refresh bun.lock so it resolves @ai-sdk/openai@3.0.63 (and corresponding transitive versions), and commit the updated lockfile.

Inline comments

• package.json:3 — This repo is type: "module". Once the lockfile is updated to actually install @ai-sdk/openai@3.x, please double-check any imports of @ai-sdk/openai use ESM import syntax only. If any code still uses CommonJS require(), v3 being ESM-only could raise ERR_REQUIRE_ESM at runtime.
• package.json:86 — Upgrading to @ai-sdk/openai@3.x can subtly change behavior (e.g., tool-call message content null vs empty, provider option changes). After updating bun.lock, do we have tests covering tool-call/streaming paths with the OpenAI provider to catch regressions from 1.x → 3.x?

Spec verification

Criterion	Status	Evidence
Lockfile must be updated to reflect dependency bumps so CI installs are reproducible.	Not Met	package.json sets "@ai-sdk/openai": "^3.0.63" (see package.json dependencies), but bun.lock still lists "@ai-sdk/openai": "^1.0.2" in the workspace deps and resolves packages["@ai-sdk/openai"] to 1.3.22.

[minsky-reviewer]

Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown

---

The prior blocking issue remains: bun.lock was not updated to reflect the @ai-sdk/openai bump to 3.0.63. The lockfile still pins @ai-sdk/openai@1.x, so CI will not actually install the upgraded version, leading to non-reproducible installs and masking any breaking changes. Please regenerate and commit bun.lock so it resolves to 3.x. I left a couple of inline notes about ESM imports and potential behavior changes to verify once the lockfile is updated. Once the lockfile is refreshed and CI installs 3.x consistently, this should be ready to proceed.

Findings

• [BLOCKING] bun.lock:8 — Lockfile not updated: bun.lock still pins @ai-sdk/openai 1.x despite package.json bump to 3.x
  package.json now declares "@ai-sdk/openai": "^3.0.63" (see package.json dependencies), but the committed bun.lock still reflects the old 1.x line:

• Top-level workspace deps show "@ai-sdk/openai": "^1.0.2" near the start of bun.lock (around lines 6–12).

• The packages section resolves "@ai-sdk/openai@1.3.22" with transitive @ai-sdk/provider-utils@2.2.8 (well below the 3.x line referenced in upstream changelogs).

Without updating and committing bun.lock, CI and other environments will continue to install 1.x, masking breaking changes and causing non-reproducible installs relative to package.json.

Action: Run your package manager to refresh bun.lock so it resolves @ai-sdk/openai@3.0.63 (and corresponding transitive versions), and commit the updated lockfile.

Inline comments

• package.json:3 — This repo is type: "module". Once bun.lock is updated to actually install @ai-sdk/openai@3.x, please double-check any imports of @ai-sdk/openai use ESM import syntax only. If any code still uses CommonJS require(), v3 being ESM-only could raise ERR_REQUIRE_ESM at runtime.
• package.json:86 — Upgrading to @ai-sdk/openai@3.x can subtly change behavior (e.g., assistant tool-call messages sending content: null, provider option changes). After updating bun.lock, do we have tests covering tool-call/streaming paths with the OpenAI provider to catch regressions from 1.x → 3.x?

Spec verification

Criterion	Status	Evidence
Lockfile must be updated to reflect dependency bumps so CI installs are reproducible.	Not Met	package.json declares "@ai-sdk/openai": "^3.0.63" (see package.json dependencies), but bun.lock still lists "@ai-sdk/openai": "^1.0.2" at the workspace root and resolves packages["@ai-sdk/openai"] to 1.3.22.

[minsky-reviewer]

Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown

---

The prior blocking issue about the lockfile remains unresolved. package.json now requires @ai-sdk/openai@^3.0.63, but bun.lock still pins the 1.x line and resolves to 1.3.22, which will cause CI to install the old version and mask real upgrade issues. Please run your package manager to refresh and commit bun.lock so it resolves 3.x transitive deps. I also left two inline notes regarding ESM import usage and potential behavior changes to cover with tests once the lockfile is updated.

Findings

• [BLOCKING] bun.lock:8 — Lockfile not updated: bun.lock still pins @ai-sdk/openai 1.x while package.json requires 3.x
  package.json now declares "@ai-sdk/openai": "^3.0.63" (see package.json dependencies block), but the committed bun.lock still reflects the old 1.x line:

• Top-level workspace deps list "@ai-sdk/openai": "^1.0.2" near the start of bun.lock.

• The packages section resolves to "@ai-sdk/openai@1.3.22" with transitive @ai-sdk/provider-utils@2.2.8.

Without updating and committing bun.lock, CI and other environments will continue to install 1.x, masking breaking changes and causing non-reproducible installs relative to package.json.

Action: Run your package manager (e.g., bun install) to refresh bun.lock so it resolves @ai-sdk/openai@3.0.63 (and corresponding transitive versions), and commit the updated lockfile.

Inline comments

• package.json:3 — This repo is type: "module". Once the lockfile is updated to actually install @ai-sdk/openai@3.x, please confirm all imports of @ai-sdk/openai use ESM import syntax only. If any legacy code uses CommonJS require(), v3 may be ESM-only and could raise ERR_REQUIRE_ESM at runtime.
• package.json:86 — After bumping to @ai-sdk/openai@3.x, upstream changelogs note subtle behavior changes (e.g., assistant tool-call messages may send content: null). Once bun.lock is updated so CI actually pulls 3.x, do we have tests covering tool-call/streaming flows to catch regressions from 1.x → 3.x?

Spec verification

Criterion	Status	Evidence
Lockfile must be updated to reflect dependency bumps so CI installs are reproducible.	Not Met	package.json sets "@ai-sdk/openai": "^3.0.63" (see package.json dependencies), but bun.lock still lists "@ai-sdk/openai": "^1.0.2" at the workspace root and resolves packages["@ai-sdk/openai"] to 1.3.22.

[minsky-reviewer]

Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown

---

The prior blocking concern about the lockfile remains: package.json now requires @ai-sdk/openai ^3.0.63, but bun.lock still pins the 1.x line and resolves to 1.3.22. This will cause CI and other installs to keep using 1.x, masking breakages and making installs non-reproducible relative to package.json. Please run your package manager to update bun.lock and commit it.

I left two minor inline notes: confirm ESM-only import usage once 3.x is actually installed, and ensure tests cover tool-call/streaming behavior changes in 3.x. Once the lockfile is updated, I expect to approve.

Findings

• [BLOCKING] bun.lock:8 — Lockfile not updated: bun.lock still pins @ai-sdk/openai 1.x while package.json requires 3.x
  package.json declares "@ai-sdk/openai": "^3.0.63" (see package.json:99–116 dependencies), but the committed bun.lock still lists the old 1.x constraint and resolution:

• Top-level workspace deps in bun.lock show "@ai-sdk/openai": "^1.0.2" near the start (around bun.lock:6–12).

• The packages section resolves "@ai-sdk/openai@1.3.22" with transitive @ai-sdk/provider-utils@2.2.8.

Without updating and committing bun.lock, CI and other environments will continue to install 1.x, masking any breaking changes and causing non-reproducible installs relative to package.json. Please run your package manager (e.g., bun install) to refresh bun.lock so it resolves @ai-sdk/openai@3.0.63 (and corresponding transitive versions), and commit the updated lockfile.

Inline comments

• package.json:3 — This repo is type: "module". After updating bun.lock to actually install @ai-sdk/openai@3.x, please confirm all imports of @ai-sdk/openai use ESM import syntax only. If any legacy code still uses CommonJS require(), v3 being ESM-only could raise ERR_REQUIRE_ESM at runtime.
• package.json:110 — Upgrading to @ai-sdk/openai@3.x can subtly change behavior (e.g., assistant tool-call messages may send content: null, different defaults). Once bun.lock is updated so CI actually pulls 3.x, do we have tests covering tool-call/streaming paths with the OpenAI provider to catch regressions from 1.x → 3.x?

[minsky-reviewer]

Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown

---

The prior blocking issue remains: bun.lock was not updated to reflect the @ai-sdk/openai bump. package.json now requires ^3.0.63, but the lockfile still pins 1.x (workspace dep ^1.0.2 and resolved 1.3.22). This breaks reproducibility and means CI won’t exercise the new major, masking incompatibilities.

Please run your package manager (e.g., bun install) to refresh bun.lock so it resolves @ai-sdk/openai@3.0.63, commit the updated lockfile, and re-run tests. I’ve also left non-blocking notes about ESM import usage and tests for tool-call/streaming behavior changes once 3.x is actually installed.

Findings

• [BLOCKING] bun.lock:8 — Lockfile not updated: bun.lock still pins @ai-sdk/openai 1.x while package.json requires 3.x
  package.json now declares "@ai-sdk/openai": "^3.0.63" in the dependencies (see package.json, the dependencies block containing "@ai-sdk/openai": "^3.0.63"). However, the committed bun.lock still reflects the old 1.x line:

• Top-level workspace deps near the start of bun.lock list "@ai-sdk/openai": "^1.0.2".

• The packages section resolves to "@ai-sdk/openai@1.3.22" with transitive @ai-sdk/provider-utils@2.2.8.

Without updating and committing bun.lock, CI and other environments will continue to install the 1.x provider, masking breaking changes and making installs non-reproducible relative to package.json.

Action: Run your package manager (e.g., bun install) to refresh bun.lock so it resolves @ai-sdk/openai@3.0.63 (and corresponding transitive versions), and commit the updated lockfile.

Inline comments

• package.json:3 — This repo is type: "module". Once the lockfile is updated to actually install @ai-sdk/openai@3.x, please confirm all imports of @ai-sdk/openai use ESM import syntax only. If any legacy code uses CommonJS require(), v3 being ESM-only could raise ERR_REQUIRE_ESM at runtime.
• package.json:110 — Upgrading to @ai-sdk/openai@3.x can subtly change behavior (e.g., assistant tool-call messages may send content: null, different defaults). After updating bun.lock so CI actually pulls 3.x, do we have tests covering tool-call/streaming paths with the OpenAI provider to catch regressions from 1.x → 3.x?

Spec verification

Criterion	Status	Evidence
Lockfile must be updated to reflect dependency bumps so CI installs are reproducible.	Not Met	package.json sets "@ai-sdk/openai": "^3.0.63" (see package.json dependencies), but bun.lock still lists "@ai-sdk/openai": "^1.0.2" in the workspace deps and resolves packages["@ai-sdk/openai"] to 1.3.22.

[minsky-reviewer]

Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown

---

The prior blocking issue remains: bun.lock still pins @ai-sdk/openai 1.x while package.json now requires 3.x. This means CI and installs won’t actually pick up the intended upgrade, risking non-reproducible builds and masking any breaking changes until later. Please run your package manager to update and commit bun.lock so it resolves @ai-sdk/openai@3.0.63. Once the lockfile is updated, this PR should be ready to proceed.

Findings

• [BLOCKING] bun.lock:8 — Lockfile not updated: bun.lock still pins @ai-sdk/openai 1.x while package.json requires 3.x
  package.json now declares "@ai-sdk/openai": "^3.0.63" (see package.json:111 in the dependencies block). However, the committed bun.lock still reflects the old 1.x line:

• Top-level workspace dependencies near the start of bun.lock list "@ai-sdk/openai": "^1.0.2" (see bun.lock:6–12).

• The packages section resolves "@ai-sdk/openai@1.3.22" with transitive @ai-sdk/provider-utils@2.2.8 (well below the 3.x line mentioned in upstream changelogs) — see the entry around bun.lock:~120 where "@ai-sdk/openai": ["@ai-sdk/openai@1.3.22", ...] is recorded.

Without updating and committing bun.lock, CI and other environments will continue to install the 1.x provider, masking breaking changes and causing non-reproducible installs relative to package.json.

Action: Run your package manager (e.g., bun install) to refresh bun.lock so it resolves @ai-sdk/openai@3.0.63 (and corresponding transitive versions), and commit the updated lockfile.

[minsky-reviewer]

Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: unknown

---

The major bump to @ai-sdk/openai was applied in package.json, but the lockfile was not refreshed. bun.lock still pins @ai-sdk/openai to 1.x and resolves to 1.3.22, which will cause CI/local installs to diverge from package.json and mask any breaking changes until later. Please run your package manager to update bun.lock so it resolves @ai-sdk/openai@3.0.63 and commit the updated lockfile. Once that’s done, this should be ready to move forward.

Findings

• [BLOCKING] bun.lock:8 — Lockfile not updated: bun.lock still pins @ai-sdk/openai 1.x while package.json requires 3.x
  package.json now declares "@ai-sdk/openai": "^3.0.63" in the dependencies block (see package.json), but the committed bun.lock still reflects the old 1.x line:

• Top-level workspace dependencies near the start of bun.lock list "@ai-sdk/openai": "^1.0.2".

• The packages section resolves "@ai-sdk/openai@1.3.22" with transitive @ai-sdk/provider-utils@2.2.8.

Without updating and committing bun.lock, CI and other environments will continue to install the 1.x provider, masking breaking changes and causing non-reproducible installs relative to package.json.

Action: Run your package manager (e.g., bun install) to refresh bun.lock so it resolves @ai-sdk/openai@3.0.63 (and corresponding transitive versions), and commit the updated lockfile.

Spec verification

Criterion	Status	Evidence
Lockfile must be updated to reflect dependency bumps so CI installs are reproducible.	Not Met	package.json sets "@ai-sdk/openai": "^3.0.63", but bun.lock still lists "@ai-sdk/openai": "^1.0.2" in the workspace deps and resolves the package to @ai-sdk/openai@1.3.22. See bun.lock header deps and packages["@ai-sdk/openai"] entry.

[minsky-reviewer]

Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: 3

---

Thanks for the update to @ai-sdk/openai in package.json. However, the lockfile wasn’t refreshed: bun.lock still pins @ai-sdk/openai 1.x and resolves to 1.3.22, which will cause CI and other environments to install the old version. This is a reproducibility and hidden-regression risk and remains blocking.

Please run your package manager to update bun.lock so it resolves @ai-sdk/openai@3.0.64 and commit it. As a non-blocking note, the repo now mixes provider majors across @ai-sdk/*; verify this matrix is supported or consider aligning versions once the lockfile is updated. Once the lockfile is corrected, this should be good to merge.

Findings

• [BLOCKING] bun.lock:8 — Lockfile not updated: bun.lock still pins @ai-sdk/openai 1.x while package.json requires 3.x
  package.json now declares "@ai-sdk/openai": "^3.0.64" in the dependencies block (see package.json). However, the committed bun.lock still reflects the old 1.x line:

• Top-level workspace deps near the start of bun.lock list "@ai-sdk/openai": "^1.0.2" (around bun.lock:6–12).

• The packages section resolves "@ai-sdk/openai@1.3.22" with transitive @ai-sdk/provider-utils@2.2.8.

Without updating and committing bun.lock, CI and other environments will continue to install the 1.x provider, masking breaking changes and causing non-reproducible installs relative to package.json.

Action: Run your package manager (e.g., bun install) to refresh bun.lock so it resolves @ai-sdk/openai@3.0.64 (and corresponding transitive versions), and commit the updated lockfile.

• [NON-BLOCKING] package.json:113 — Mixed major versions across @ai-sdk/* providers may cause incompatibilities
  After this change, providers include:
• "@ai-sdk/openai": "^3.0.64"
• "@ai-sdk/anthropic": "^1.0.2"
• "@ai-sdk/google": "^1.0.2"

The vercel/ai provider packages often share internal utilities and evolve together. Mixing 3.x OpenAI with 1.x Anthropic/Google increases risk of multiple @ai-sdk/provider[-utils] versions or subtle type/runtime mismatches when used together. If this project composes responses/tools across providers, verify compatibility. Consider aligning provider majors or documenting why the matrix is supported. At minimum, once the lockfile is updated, ensure it resolves a coherent set and that tests cover mixed-provider usage.

Spec verification

Criterion	Status	Evidence
Lockfile must be updated to reflect dependency bumps so CI installs are reproducible.	Not Met	package.json declares "@ai-sdk/openai": "^3.0.64" (see package.json dependencies), but bun.lock still lists "@ai-sdk/openai": "^1.0.2" in the workspace deps and resolves to "@ai-sdk/openai@1.3.22" in the packages section (see header and the packages["@ai-sdk/openai"] entry).

[minsky-reviewer]

Independent adversarial review (Chinese-wall)
Reviewer: minsky-reviewer[bot] via openai:gpt-5
Tier: 3

---

The prior blocking issue remains: bun.lock was not updated, so the lockfile still pins @ai-sdk/openai 1.x while package.json now requires 3.0.64. This will cause CI and installs to drift from package.json and mask any breaking changes. Please run bun install (or your package manager) to refresh and commit bun.lock resolving @ai-sdk/openai@3.0.64.

Non-blocking: consider aligning other @ai-sdk/* provider majors or confirming compatibility for the mixed 3.x/1.x setup once the lockfile is updated. Once the lockfile is fixed, this PR should be ready to merge.

Findings

• [BLOCKING] bun.lock:8 — Lockfile not updated: bun.lock still pins @ai-sdk/openai 1.x while package.json requires 3.x
  package.json now declares "@ai-sdk/openai": "^3.0.64" in the dependencies block (see package.json). However, the committed bun.lock still reflects the old 1.x line:

• Top-level workspace deps near the start of bun.lock list "@ai-sdk/openai": "^1.0.2" (around bun.lock:6–12).

• The packages section resolves "@ai-sdk/openai@1.3.22" with transitive @ai-sdk/provider-utils@2.2.8.

Without updating and committing bun.lock, CI and other environments will continue to install the 1.x provider, masking breaking changes and causing non-reproducible installs relative to package.json.

Action: Run your package manager (e.g., bun install) to refresh bun.lock so it resolves @ai-sdk/openai@3.0.64 (and corresponding transitive versions), and commit the updated lockfile.

• [NON-BLOCKING] package.json:112 — Mixed major versions across @ai-sdk/* providers may cause incompatibilities
  After this change, providers include:

• "@ai-sdk/openai": "^3.0.64"

• "@ai-sdk/anthropic": "^1.0.2"

• "@ai-sdk/google": "^1.0.2"

The vercel/ai provider packages often share internal utilities and evolve together. Mixing 3.x OpenAI with 1.x Anthropic/Google increases risk of multiple @ai-sdk/provider[-utils] versions or subtle type/runtime mismatches when used together. If this project composes responses/tools across providers, verify compatibility. Consider aligning provider majors or documenting why the matrix is supported. At minimum, once the lockfile is updated, ensure it resolves a coherent set and that tests cover mixed-provider usage.

Spec verification

Criterion	Status	Evidence
Lockfile must be updated to reflect dependency bumps so CI installs are reproducible.	Not Met	package.json declares "@ai-sdk/openai": "^3.0.64" (see package.json dependencies), but bun.lock still lists "@ai-sdk/openai": "^1.0.2" in the workspace deps and resolves to "@ai-sdk/openai@1.3.22" in the packages section (see bun.lock header and the packages["@ai-sdk/openai"] entry).