Skip to content

LLM proxy and models

Production EAP model traffic goes through the Cisco LLM Proxy. For Codex projects, EAP writes the provider and model configuration into a generated project-scoped $CODEX_HOME/config.toml; project authors do not configure the production model in AGENTS.md.

What Is Cisco LLM Proxy

Cisco LLM Proxy is a Cisco Collaboration AI service that forwards requests to approved backend providers. EAP uses it for:

  • service identity — production runs do not depend on personal developer credentials
  • centralized governance — model allow-lists, data-handling rules, rate controls, and usage tracking are managed centrally
  • provider abstraction — Codex talks to one OpenAI-compatible Responses API while the proxy owns upstream routing

Reference: LLM Proxy Quickstart · Model list

Environment EAP Uses

EAP production runs against the internal-prod Cisco LLM Proxy environment. internal-prod is gated for customer-facing applications. Internal-only projects must confirm the intended proxy environment with the EAP team before onboarding traffic.

Available Models

The current EAP Codex runtime configuration exposes these model IDs:

Model ID Notes
gpt-5.4 Current EAP default. Also used as the default review model.
gpt-5.1 Available through the current runtime allow-list.
gpt-4.1 Available as a smaller model option.
gpt-5.3-chat-global Available through the current runtime allow-list.

The LLM Proxy portal can list models that EAP has not enabled. A model is usable in EAP only after it is added to the runtime's LLM_PROVIDER_MODELS allow-list and the EAP deployment is updated.

How Production Codex Is Configured

When a Codex project runtime starts, EAP generates configuration equivalent to:

model = "gpt-5.4"
model_provider = "cisco-llm"
review_model = "gpt-5.4"

[model_providers."cisco-llm"]
name = "Cisco LLM"
base_url = "http://localhost:<proxy-port>/llm/projects/<project-id>/v1"
wire_api = "responses"

The actual values come from the deployed EAP settings. The project-scoped proxy adds the project's approved Cisco identity before forwarding the request.

Model Configuration Ownership

Codex AGENTS.md files contain project instructions. EAP selects the production provider and model through the generated runtime configuration shown above.

If a project needs a different production model, request it through the EAP team. The change belongs in platform runtime configuration, with any required LLM Proxy approval, rather than in the customer agent repo.

Requesting A Model That Is Not Available

  1. Confirm that the model exists on the LLM Proxy model list.
  2. File a request with the EAP team containing the exact model ID, use case, expected volume, and reason the current allow-list is insufficient.
  3. The EAP team obtains any required proxy approval and updates the runtime allow-list and default configuration.
  4. Validate the model in EAP staging before production promotion.

Do not call a different LLM endpoint directly from skill code. Production credentials and network paths are owned by the platform.

Local Development With Codex

Use Codex locally to validate repository instructions and skill discovery before requesting an EAP staging deployment.

Setup

  1. Install the Codex CLI.
  2. Run codex login and use the approved local authentication method available to you.
  3. Start Codex from the project repository root so it discovers the root AGENTS.md and .agents/skills.
  4. Use /model or a local .codex/config.toml to select a model available to your local account.

For example, a local-only project config can contain:

model = "gpt-5.4"

Local model availability and production EAP availability are separate. Local testing proves that instructions, skills, and workflow shape are usable; EAP staging proves behavior with the production Cisco LLM Proxy model and generated runtime configuration.

Local MCP Configuration

For local testing, Codex reads MCP configuration from .codex/config.toml in a trusted repository or from ~/.codex/config.toml:

[mcp_servers.example]
url = "https://example.test/mcp"
bearer_token_env_var = "EXAMPLE_TOKEN"

See the Codex MCP documentation for supported transports and fields.

Local MCP configuration is authoring support only. EAP production MCP access is generated from the project's reviewed Registry YAML, and anything missing from that YAML is outside the production contract.