What the docs say
docs/integrations.md, "Vercel AI SDK, and anything with its origin compiled in":
@ai-sdk/openai takes its origin as a constructor argument and reads nothing from the environment. The node adapter installs a preload through NODE_OPTIONS that redirects at globalThis.fetch — the one place every JS client agrees on.
The Mastra section inherits the same claim ("the origin is a constructor argument and the environment is not consulted"), and the README support table repeats it for both rows.
What I measured
@ai-sdk/openai 3.0.112 reads OPENAI_BASE_URL. Three construction paths, OPENAI_API_BASE unset, OPENAI_BASE_URL=http://127.0.0.1:9/v1, each probed by letting the request fail and reading the URL it tried:
createOpenAI({apiKey}) -> tried: http://127.0.0.1:9/v1/responses
bare openai provider -> tried: http://127.0.0.1:9/v1/responses
explicit baseURL arg -> tried: http://127.0.0.1:11/v1/responses
So: the environment is consulted, and an explicit baseURL argument wins over it — the ordinary precedence, not "nothing from the environment".
Why it matters
Three places are affected, and the error runs in the direction of making orca look more necessary than it is:
docs/integrations.md § Vercel AI SDK — the premise of the section.
docs/integrations.md § Mastra — "inherits that provider's behaviour exactly" is still true, but the behaviour it inherits is the opposite of what is written.
- README support table — both rows point at
orca record node -- and the fetch preload as the route. If OPENAI_BASE_URL works, orca record generic-openai -- is the simpler route for these two, and the preload is the fallback rather than the requirement.
The hardcoded_origin.mjs check is unaffected — an origin compiled into source genuinely does read nothing, and the preload is the right answer there. It is the attribution of that property to @ai-sdk/openai that looks wrong.
Possible explanations, in order of likelihood
- The SDK changed.
@ai-sdk/openai 3.x may have added the env fallback after the check was written. If so the fix is a version note plus updating the route, not a retraction.
- The check measures something narrower than the doc claims.
mastra_agent.mjs and the Vercel check both pass under the preload, which they would whether or not the env var also works — a preload that redirects fetch catches the request regardless of how the URL was resolved. So a green check does not discriminate between the two explanations.
Worth adding a check that pins the actual behaviour: set OPENAI_BASE_URL with no preload and assert the request lands on the stub. That is the assertion that would have caught this, and it would catch a future regression in either direction.
Environment
@ai-sdk/openai 3.0.112, Node 22.23.2, Windows. No preload, no proxy — just the provider and a dead port to read the URL off the error.
What the docs say
docs/integrations.md, "Vercel AI SDK, and anything with its origin compiled in":The Mastra section inherits the same claim ("the origin is a constructor argument and the environment is not consulted"), and the README support table repeats it for both rows.
What I measured
@ai-sdk/openai3.0.112 readsOPENAI_BASE_URL. Three construction paths,OPENAI_API_BASEunset,OPENAI_BASE_URL=http://127.0.0.1:9/v1, each probed by letting the request fail and reading the URL it tried:So: the environment is consulted, and an explicit
baseURLargument wins over it — the ordinary precedence, not "nothing from the environment".Why it matters
Three places are affected, and the error runs in the direction of making orca look more necessary than it is:
docs/integrations.md§ Vercel AI SDK — the premise of the section.docs/integrations.md§ Mastra — "inherits that provider's behaviour exactly" is still true, but the behaviour it inherits is the opposite of what is written.orca record node --and the fetch preload as the route. IfOPENAI_BASE_URLworks,orca record generic-openai --is the simpler route for these two, and the preload is the fallback rather than the requirement.The
hardcoded_origin.mjscheck is unaffected — an origin compiled into source genuinely does read nothing, and the preload is the right answer there. It is the attribution of that property to@ai-sdk/openaithat looks wrong.Possible explanations, in order of likelihood
@ai-sdk/openai3.x may have added the env fallback after the check was written. If so the fix is a version note plus updating the route, not a retraction.mastra_agent.mjsand the Vercel check both pass under the preload, which they would whether or not the env var also works — a preload that redirectsfetchcatches the request regardless of how the URL was resolved. So a green check does not discriminate between the two explanations.Worth adding a check that pins the actual behaviour: set
OPENAI_BASE_URLwith no preload and assert the request lands on the stub. That is the assertion that would have caught this, and it would catch a future regression in either direction.Environment
@ai-sdk/openai3.0.112, Node 22.23.2, Windows. No preload, no proxy — just the provider and a dead port to read the URL off the error.