Soju06/codex-lb

Codex can complete ordinary requests through an OpenAI-compatible Model Source while failing to use subagents. A source can advertise multi_agent_version: "v2" to the client, yet codex-lb still removes the client-supplied collaboration namespace from the upstream Responses request. Source-provided base instructions are also lost in the catalog projection. Environment and scope Observed on a self-built fork based on 1.25.0-beta.6, before fork commit 00164ab0; Docker Compose deployment, Codex CLI 0.156.1. Enabled OpenAI-compatible Model Source with Responses, streaming, and tools support; custom model slug (custom/coder below is an anonymized example). HTTP Responses transport. The successful fix does not require WebSocket support or changing the source credential. Inspected upstream main at 09a140fa: the same catalog projection and tool-filter behavior are still present. The deployed end-to-end verification below was on the fork, not a clean upstream-main deployment. Reproduction Co

Problem The Codex provider examples in the README and client setup guide omit supports_standalone_web_search = true. With my setup, native web search was unavailable through the documented custom provider, even with --search. Codex used browser automation instead. Adding the capability setting restored native web search without changing or restarting codex-lb. Tested environment Codex CLI: 0.157.0 Model: gpt-6-astra, Low reasoning Authentication: ChatGPT login, with a codex-lb API key for the local proxy codex-lb: 1.24.0, Docker image ghcr.io/soju06/codex-lb:latest, revision 84fde5a1ed5e0d5a58ccb3ec4b82938b059bf8c5 Platform: macOS with Docker Desktop Provider base URL: http://127.0.0.1:2455/backend-api/codex Reproduction and comparison Using the documented provider configuration, run: codex --search -c 'model_provider="codex-lb"' \ -m gpt-6-astra -c 'model_reasoning_effort="low"' \ "Search today's top news" In my test, Codex opened Google News through computer use instead of invo

Problem Operators need to alert when the pool has too few active or available accounts, especially when no account can serve requests. codex_lb_accounts_total is declared as a gauge with a status label in app/core/metrics/prometheus.py, but a repository-wide search found no producer that updates it. Consequently, codex_lb_accounts_total{status="active"} cannot currently provide a reliable account count for alerting. No dedicated available-account count gauge was found either. This finding comes from source inspection; a live deployment scrape has not been checked. Evidence / reproduction Run rg -n 'accounts_total' app tests. Observe the gauge declaration, optional-dependency fallback, and export, but no calls populating its labeled values. Once implementing the fix, verify through the actual metrics scrape endpoint with populated and empty account pools. Relevant code: app/core/metrics/prometheus.py: accounts_total declaration (currently uses liveall in multiprocess mode). app/db/mo

Pre-flight checklist I searched existing issues and discussions for similar proposals. This is a concrete proposal, not an open-ended question. Problem / motivation Request logs already persist and return modelSourceId and modelSourceKind for configured model-source traffic (#1129), but the dashboard neither displays nor filters by them. As a result: model-source requests appear as Unassigned in the Account column; two sources serving the same model slug cannot be distinguished; operators cannot isolate source-specific failures, latency, or cost; historical traffic from a deleted source retains its stable source ID, but the dashboard provides no way to find or identify it. Proposed change Add an Upstream multi-select facet to the existing Request Logs view. The facet uses observed request-log data, not merely currently configured sources, with this exhaustive taxonomy: subscription_pool: rows where model_source_id IS NULL. This means the built-in subscription route family, inclu

Pre-flight checklist I searched existing issues and confirmed this is not a duplicate. I am running a supported codex-lb version (see Releases). I can reproduce the problem with the steps below. codex-lb version 1.24.0-beta.2 Deployment method Docker (ghcr.io/Soju06/codex-lb) Client used against codex-lb Codex CLI ChatGPT account plan(s) involved Pro Model(s) involved No response What happened? My telemetry "sample output" contains: "clients": { "codex-cli": 0.18072, "other": 0.81928 }, but I only ever use codex-cli. Is this just bogus sample data, or a bug? What did you expect to happen? codex-cli should be 1. other should be 0. Steps to reproduce 1. start codex-lb 2. View telemetry in settings panel Relevant logs Configuration / environment Additional context No response