feat(ai): Add support for Snowflake Cortex and OpenAI gateways

[almahirpmf]

Summary

Added environment variables to allow routing traffic to custom endpoints like Snowflake Cortex, without altering the default behavior for standard OpenAI users.

Changes included:
Support for OPENAI_BASE_URL and OPENAI_EXTRA_HEADERS_JSON to override the default api.openai.com endpoint and pass required custom headers.

Added FINALRUN_OPENAI_SNOWFLAKE_COMPAT=1 flag to intercept the underlying fetch call and map max_tokens to max_completion_tokens (required by Snowflake Cortex).

Added FINALRUN_OPENAI_USE_CHAT=1 flag to force the use of Chat Completions (openai.chat) instead of the default Responses API (openai.responses), avoiding 403 errors on /v1/responses for gateways that only support the chat-compatible endpoint.

The default behavior for standard OpenAI usage is kept exactly the same.

Validation

• npm run build
• npm test
• npm run lint
• Additional manual verification noted below:

Manually verified that finalRun successfully connects to Android using Snowflake Cortex as the API key gateway when using the new environment variables.

Notes

Call out platform-specific behavior, follow-up work, or known limitations.

[droid-ash]

@almahirpmf why is this change required? can you explain, we already support openai

[almahirpmf]

Hi @droid-ash, thanks for taking a look! You're right that OpenAI itself is already supported — this PR is about OpenAI-compatible gateways, which the current openai provider can't reach. Many setups route LLM traffic through a proxy that exposes an OpenAI-compatible endpoint instead of calling api.openai.com directly — Snowflake Cortex, LiteLLM, corporate gateways, etc. In my case I'm running FinalRun against Snowflake Cortex.

Three things block FinalRun against such a gateway today:

• Custom auth headers. There's no way to pass extra headers to createOpenAI. Snowflake, for example, requires X-Snowflake-Authorization-Token-Type: PROGRAMMATIC_ACCESS_TOKEN on every request, so authentication fails even with a valid key. Hence OPENAI_EXTRA_HEADERS_JSON (and an explicit OPENAI_BASE_URL pass-through so the routing is visible in code rather than relying on the SDK's implicit env read).
• Responses API is hardcoded. _getModel always uses openai.responses(...), but most compatible gateways only implement /v1/chat/completions — /v1/responses returns 403. FINALRUN_OPENAI_USE_CHAT=1 opts into openai.chat(...) for those cases, while keeping Responses as the default so reasoning-effort handling for real OpenAI models is untouched.
• max_tokens vs max_completion_tokens. Some gateways (Cortex included) reject the deprecated max_tokens param that the SDK sends on chat completions. FINALRUN_OPENAI_SNOWFLAKE_COMPAT=1 rewrites it in a fetch wrapper.

All three are env-gated and off by default, so stock OpenAI behavior is byte-for-byte identical. With these flags I've been running a full Android test suite through Cortex successfully.

Happy to adjust naming/approach if you'd prefer this shaped differently (e.g., a generic openai-compatible provider instead of env flags).