What should we do?
Replace the LangChain4j bridge for the openai and openaiCompatible provider discriminators with a native implementation over the official com.openai:openai-java SDK on its Chat Completions endpoint. Azure is handled in its own sub-issue; the Responses API lands in Phase 2.
Requirements:
- Streaming-first internal driver as in the Anthropic Messages issue.
- Hardcoded
ModelCapabilities: text + image on user-message; text on tool-result; text on assistant-message.
- Token usage, stop-reason mapping, error classification, and JDK proxy transport, all consistent with the Anthropic Messages implementation.
openaiCompatible builds the SDK client against a custom base URL with optional API key.- Reuse one
OpenAiToolConverter for tool definition serialization that the Responses API impl can pick up later.
Why should we do it?
Provides the second wire format on the new SPI and unblocks every customer using the direct OpenAI API or an OpenAI-compatible gateway (Ollama, vLLM, etc.).
What should we do?
Replace the LangChain4j bridge for the
openaiandopenaiCompatibleprovider discriminators with a native implementation over the officialcom.openai:openai-javaSDK on its Chat Completions endpoint. Azure is handled in its own sub-issue; the Responses API lands in Phase 2.Requirements:
ModelCapabilities: text + image on user-message; text on tool-result; text on assistant-message.openaiCompatiblebuilds the SDK client against a custom base URL with optional API key.OpenAiToolConverterfor tool definition serialization that the Responses API impl can pick up later.Why should we do it?
Provides the second wire format on the new SPI and unblocks every customer using the direct OpenAI API or an OpenAI-compatible gateway (Ollama, vLLM, etc.).