OpenShift AI 3.5 EA2 makes the Responses API GA inside an unsupported early-access release

Red Hat’s OpenShift AI 3.5 EA2 release notes draw an important distinction between a feature’s maturity label and the support status of the release that carries it. The OpenAI-compatible Responses API on OGX is listed as generally available, with providers enabled by default in the runtime config.yaml. But 3.5 EA2 itself remains an Early Access build, and Red Hat’s lifecycle policy says EA releases receive no support, security updates or CVE fixes and require a fresh installation when moving to GA.

What changed

The Responses API is the clearest application-facing change. Red Hat says existing OpenAI SDKs, tools and workflows can call the API without client changes. That gives teams a stable-looking compatibility surface for testing agent and retrieval applications against OGX.

EA2 also adds operator-facing controls and catalog data. Administrators can set OAuth proxy sidecar requests and limits through spec.components.kserve.oauthProxy.resources while leaving KServe managed, rather than editing an Operator-owned ConfigMap. The model catalog now shows cold-start model-load time, minimum vRAM, container size and benchmark commands. Red Hat explicitly limits the startup metric: it measures the vLLM load phase after weights have already been downloaded and copied into the container, not end-to-end readiness.

MaaS users gain a Subscriptions tab showing assigned subscriptions, models, token limits and associated API keys. That view sits alongside preview-only areas that should not be collapsed into the same support claim. Red Hat’s Technology Preview section marks batch inference through llm-d’s /v1/batches, EvalHub’s MCP server, evaluation thresholds and several other EA2 capabilities as not production-supported. The broader MaaS observability dashboard remains Technology Preview in the 3.5 documentation.

What operators should test

Teams evaluating the API should run their existing OpenAI client suite against OGX and verify streaming, tool calls, error handling and any response fields their application persists. The release note establishes compatibility intent, not application-level equivalence for every client behavior.

Platform teams should separately test the operational changes: confirm that OAuth proxy limits survive Operator reconciliation; compare the catalog’s model-load metric with pod scheduling, image pull, weight transfer and readiness timestamps; and verify that subscription membership, token limits and API-key visibility match the authorization policy actually enforced at the gateway.

For preview MaaS, batch and evaluation features, tests should be isolated from production service-level objectives. In particular, a low catalog cold-start figure must not be treated as an end-to-end startup SLO, and the preview observability dashboard should not be the sole source for billing or compliance evidence.

The support boundary

“Generally available” here describes the Responses API feature. It does not turn OpenShift AI 3.5 EA2 into a supported production release. Red Hat says EA releases last about a month or until superseded, use beta channels, do not receive security fixes, and cannot be upgraded to GA. Operators that need production support should use EA2 to validate clients and manifests, retain reproducible test results, and plan a fresh deployment and rerun of those checks when OpenShift AI 3.5 reaches GA.