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:

  1. 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.
  1. 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
  1. 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"
  1. 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.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 10 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #3721
  • #4136

Powered by Codex Action

Jayk56 · 10 months ago

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 :)

Jayk56 · 10 months ago
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 #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.

    // Some providers (e.g., certain OpenRouter models) do not emit
    // `response.output_item.done` for assistant messages and only include the
    // final assistant message inside the `response.completed.response.output`
    // array. Track whether we've seen an assistant message item so we can fall
    // back to parsing the final message from `response.completed` when needed.

This may work for the vertex endpoint, but I wasn't having a great time trying to use it through the Chat endpoint

HansDaigle · 10 months ago

Experiencing similar issue with Codex -> LiteLLM -> Ollama -> gpt-oss:120b.

+1

avikalpa · 9 months ago

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 codex client 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:

npm i -g @avikalpa/codex-litellm

Repo: https://github.com/avikalpa/codex-litellm

---
@Jayk56 I was thinking about vLLM from your comment. Since vLLM also provides an OpenAI-compatible API, codex-litellm has 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 vLLM endpoint and see? If you encounter any issues, please open a issue on the codex-litellm repo. We could make it a goal to work smoothly with vLLM if 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!