Add native OpenAI provider support for Codex Mini model #1099
Closed
fxcl
started this conversation in
1. Feature requests
Replies: 1 comment
-
tks |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
What specific problem does this solve?
Roo Code currently lacks native OpenAI provider support for the "codex-mini-latest" model, which is a specialized model for code-related tasks. While this model is available through OpenRouter, adding direct OpenAI provider support would improve performance, reliability, and potentially reduce costs for users who have direct OpenAI API access.
Who is affected: Users who need specialized code-focused AI capabilities through direct OpenAI API access
When this happens: When users want to use the Codex Mini model directly through OpenAI rather than via OpenRouter
Current behavior: The Codex Mini model is only available through OpenRouter, not through the native OpenAI provider
Expected behavior: Users can select and use the Codex Mini model directly through the OpenAI provider with appropriate configuration
Impact: Users currently need to use OpenRouter as an intermediary or use other models, which may introduce additional latency, costs, or limitations
Additional context
The Codex Mini model has the following specifications that need to be added to the native OpenAI provider:
"codex-mini-latest": {
maxTokens: 100_000,
contextWindow: 200_000,
supportsImages: false,
supportsPromptCache: false,
inputPrice: 1.5,
outputPrice: 6,
cacheReadsPrice: 0,
},
An important implementation detail is that this model is only supported in the v1/responses endpoint and not in the v1/chat/completions endpoint. This means that the current OpenAI provider implementation, which primarily uses the chat completions API, will need to be modified to support this model's different API requirements.
Some users might be eligible for free daily usage on traffic shared with OpenAI if they are willing to share their outputs for the purpose of training:
Up to 10 million tokens per day across gpt-4.1-mini, gpt-4.1-nano, gpt-4o-mini, o1-mini, o3-mini, o4-mini, and codex-mini-latest
Technical Analysis
Based on examination of the codebase, the following changes would be needed to implement native OpenAI provider support for the codex-mini-latest model:
Add Model Definition:
Add the model definition to packages/types/src/providers/openai.ts in the openAiNativeModels object with the provided specifications
Implement v1/responses Endpoint Support:
The current OpenAI provider implementation in src/api/providers/openai.ts only uses the chat completions API (client.chat.completions.create)
A new method will need to be added to handle the v1/responses endpoint for models that don't support chat completions
Similar to how there's special handling for the O3 family models in handleO3FamilyMessage, a new method like handleCodexMiniMessage would be needed
Update Model Detection Logic:
Modify the createMessage method in OpenAiHandler class to detect when the codex-mini-latest model is being used and route to the appropriate handler
Add a condition like: if (modelId === "codex-mini-latest") { yield* this.handleCodexMiniMessage(...); return; }
Implement Completions API Call:
Use the OpenAI SDK's completions API instead of chat completions
Convert the messages format appropriately for the completions API
Handle streaming and non-streaming cases
Update UI:
Ensure the model appears in the model selection UI for the native OpenAI provider
Add appropriate tooltips or information about the free usage tier
This implementation would require adding a new API endpoint handler that hasn't been used elsewhere in the codebase, so careful testing would be needed to ensure it works correctly.
Beta Was this translation helpful? Give feedback.
All reactions