Codex with litellm vertex AI endpoint serving gpt-oss-120b model produces no output.
Resolved 💬 5 comments Opened Oct 14, 2025 by avikalpa Closed Nov 5, 2025
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What version of Codex is running?
0.46.0
Which model were you using?
gpt-oss-120b
What platform is your computer?
Linux 6.12.38+deb13-amd64 x86_64 unknown
What steps can reproduce the bug?
litellm with gcloud cli and minimal config.yaml as:
- Setup gcloud cli (We need this
~/.config/gcloud/application_default_credentials.json). Also enable the Vertex AI API and the gpt oss maas api on Vertex AI.
- Configure litellm with vertex endpoint:
services:
litellm:
image: ghcr.io/berriai/litellm:main-stable
volumes:
- ./config.yaml:/app/config.yaml
- ~/.config/gcloud/application_default_credentials.json:/app/application_default_credentials.json
command:
- "--config=/app/config.yaml"
ports:
- "4000:4000" # Map the container port to the host, change the host port if necessary
environment:
DATABASE_URL: "postgresql://llmproxy:password@db:5432/litellm"
STORE_MODEL_IN_DB: "True" # allows adding models to proxy via UI
env_file:
- .env # Load local .env file
depends_on:
- db # Indicates that this service depends on the 'db' service, ensuring 'db' starts first
healthcheck: # Defines the health check configuration for the container
test: [ "CMD-SHELL", "wget --no-verbose --tries=1 http://localhost:4000/health/liveliness || exit 1" ] # Command to execute for health check
interval: 30s # Perform health check every 30 seconds
timeout: 10s # Health check command times out after 10 seconds
retries: 3 # Retry up to 3 times if health check fails
start_period: 40s # Wait 40 seconds after container start before beginning health checks
db:
image: postgres:16
restart: always
container_name: litellm_db
environment:
POSTGRES_DB: litellm
POSTGRES_USER: llmproxy
POSTGRES_PASSWORD: password
ports:
- "5432:5432"
volumes:
- postgres_data:/var/lib/postgresql/data # Persists Postgres data across container restarts
healthcheck:
test: ["CMD-SHELL", "pg_isready -d litellm -U llmproxy"]
interval: 1s
timeout: 5s
retries: 10
prometheus:
image: prom/prometheus
volumes:
- prometheus_data:/prometheus
- ./prometheus.yml:/etc/prometheus/prometheus.yml
ports:
- "9090:9090"
command:
- "--config.file=/etc/prometheus/prometheus.yml"
- "--storage.tsdb.path=/prometheus"
- "--storage.tsdb.retention.time=15d"
restart: always
volumes:
prometheus_data:
driver: local
postgres_data:
name: litellm_postgres_data # Named volume for Postgres data persistence
- Before running docker compose up, create the required
config.yaml(required by our docker compose file) pointing to the models:
model_list:
- model_name: gpt-oss-120b-litellm
litellm_params:
model: vertex_ai/openai/gpt-oss-120b-maas
vertex_ai_project: "PROJECT_ID"
vertex_credentials: "/app/application_default_credentials.json"
#use_in_pass_through: true
model_info:
supports_reasoning: True
- model_name: gpt-oss-20b-litellm
litellm_params:
model: vertex_ai/openai/gpt-oss-20b-maas
vertex_ai_project: "PROJECT_ID"
vertex_credentials: "/app/application_default_credentials.json"
#use_in_pass_through: true
model_info:
supports_reasoning: True
litellm_settings:
# Necessary to use the models in codex as Vertex AI endpoint does not
# support the entire OpenAI Spec of tooluse.
drop_params: true
And a .env file
LITELLM_MASTER_KEY="sk-1234"
- Launch codex and test
# Point to your LiteLLM Proxy server
export OPENAI_BASE_URL=http://0.0.0.0:4000
# Use your LiteLLM API key (if you've set up authentication)
export OPENAI_API_KEY="sk-1234"
codex --model gpt-oss-120b-litellm
# ask something
# task completes but no output
What is the expected behavior?
codex --model gpt-oss-120b-litellm
# ask something
# task completes WITH OUTPUT
What do you see instead?
codex --model gpt-oss-120b-litellm
# ask something
# task completes but no output
Additional information
Linking issue with litellm: https://github.com/BerriAI/litellm/issues/15520
It is somewhat involved to setup vertex due to the gcloud cli authentication and enabling the API endpoint. But this endpoint is the most economical of this hosted model without any compromises in throughput and quality.
5 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
sounds similar to this openrouter issue I had opened, I just tested this with 0.46.0 and it seems like the bug is still present. #1963 - When running models from openrouter providers the model messages are not displayed.
there is a fix in https://github.com/openai/codex/pull/1964 - I'll merge in the latest versions and see if it still works. Would appreciate if you tried with VLLM as well :)
so this turned into a longer analysis than I was thinking initially lol and I'm not sure there's a simple answer that will get worked on anytime soon. (would love to be wrong)
There's a bandaid fix for the issue for _some_ openrouter providers in this branch: https://github.com/Jayk56/codex/tree/jay/fresh-fix-for-openrouter, but I think I only saw it work semi-reliable with Cerebras, and pointed at the openrouter /responses api endpoint rather than the chat completions default.
This may work for the vertex endpoint, but I wasn't having a great time trying to use it through the Chat endpoint
Experiencing similar issue with Codex -> LiteLLM -> Ollama -> gpt-oss:120b.
+1
Hey all, as the original poster, I'm happy to follow up with a complete solution.
After a deep dive, the core issue is that the
codexclient is tightly coupled to the specific API structure and streaming behavior of OpenAI's platform. This is perfectly reasonable for the original project, but it creates friction when trying to use it with other model backends.Building on the incredible foundation the OpenAI team created, I've developed a fork,
codex-litellm, to bridge this gap. This fork is specifically patched to understand and handle the variety of API responses and streaming nuances that come from different model providers, especially when unified through a backend like LiteLLM.It serves as a community-maintained, drop-in replacement that unlocks Codex for a much wider ecosystem. Contributors and PRs are welcome :)
Install:
Repo: https://github.com/avikalpa/codex-litellm
---
@Jayk56 I was thinking about
vLLMfrom your comment. SincevLLMalso provides an OpenAI-compatible API,codex-litellmhas a very high chance of working with it, as it's designed to be more tolerant of API variations than the original.Could you test it against your
vLLMendpoint and see? If you encounter any issues, please open a issue on thecodex-litellmrepo. We could make it a goal to work smoothly withvLLMif it's not already there, although I do not have vLLM setup myself, so will rely on vLLM users for PRs if it is not already compatible.With a dedicated solution now available, I'll go ahead and close this issue. Thank you for the discussion!