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
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.
This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗