Skip to content

Add GPT-5.5 and Gemini 3.1 Pro model selectors#176

Open
akseljoonas wants to merge 3 commits intomainfrom
codex/add-gpt55-gemini31-models
Open

Add GPT-5.5 and Gemini 3.1 Pro model selectors#176
akseljoonas wants to merge 3 commits intomainfrom
codex/add-gpt55-gemini31-models

Conversation

@akseljoonas
Copy link
Copy Markdown
Collaborator

Summary

  • add GPT-5.5 (high) and Gemini 3.1 Pro to the frontend model selector and backend allowlist
  • add Gemini direct-provider LiteLLM routing and effort validation
  • add CLI /model suggestions plus shared default-effort handling so GPT-5.5 uses high when the global preference is max
  • document the Gemini CLI model id

Verification

  • UV_CACHE_DIR=/tmp/uv-cache uv run pytest tests/unit/test_llm_params.py tests/unit/test_cli_rendering.py
  • npm run build

Known unrelated failures

  • UV_CACHE_DIR=/tmp/uv-cache uv run pytest tests/unit fails two existing test_doom_loop.py assertion text expectations.
  • npm run lint fails existing unrelated lint issues in ActivityStatusBar.tsx, agentStore.ts, main.tsx, and logger.ts.

The web selector and CLI suggestions now expose GPT-5.5 with the product-level high reasoning default and Gemini 3.1 Pro through LiteLLM's Gemini provider path. A small shared default-effort helper keeps frontend sessions and CLI probes aligned when the global preference is max, while preserving explicit user effort choices.

Constraint: LiteLLM routes Gemini API-key usage with the gemini/ provider prefix, not through the Hugging Face router.
Constraint: The local sandbox blocks writes under .git, so this commit was created through the GitHub API instead of local git refs.
Rejected: Treat gemini/gemini-3.1-pro-preview as an HF-router id | that would send it to the wrong base URL and token path.
Confidence: high
Scope-risk: narrow
Directive: Keep frontend MODEL_OPTIONS, backend AVAILABLE_MODELS, and CLI SUGGESTED_MODELS in sync when adding selector models.
Tested: UV_CACHE_DIR=/tmp/uv-cache uv run pytest tests/unit/test_llm_params.py tests/unit/test_cli_rendering.py
Tested: npm run build
Not-tested: Full unit suite is red on existing doom_loop assertion text expectations; frontend lint is red on pre-existing unrelated prefer-const/no-unused-vars issues.
@github-actions
Copy link
Copy Markdown

github-actions Bot commented Apr 28, 2026

Claude encountered an error —— View job


I'll analyze this and get back to you.

A real CLI run against the Gemini selector reached provider auth, but the local environment has no Gemini API key. The existing friendly auth message only named Anthropic, OpenAI, and HF Router, so Gemini users would not see the variable required for the new selector entry.

Constraint: No GEMINI_API_KEY is present in the local environment or .env, so live Gemini completion cannot be validated from this machine.
Confidence: high
Scope-risk: narrow
Directive: Keep provider auth hints aligned with every direct-provider model shown in selectors.
Tested: UV_CACHE_DIR=/tmp/uv-cache uv run pytest tests/unit/test_llm_params.py tests/unit/test_cli_rendering.py tests/unit/test_llm_error_classification.py
Tested: npm run build
Tested: UV_CACHE_DIR=/tmp/uv-cache uv run ml-intern --model openai/gpt-5.5 --max-iterations 1 --no-stream 'Reply with exactly: OK'
Not-tested: Gemini live completion; GEMINI_API_KEY is not available locally.
@akseljoonas
Copy link
Copy Markdown
Collaborator Author

Live CLI validation update:

  • ✅ GPT-5.5 was tested with the real local OPENAI_API_KEY from .env:
    UV_CACHE_DIR=/tmp/uv-cache uv run ml-intern --model openai/gpt-5.5 --max-iterations 1 --no-stream 'Reply with exactly: OK'
    Result: completed successfully and returned OK.
  • ⚠️ Gemini was tested through the real CLI entrypoint, but this machine has no GEMINI_API_KEY in env or .env. The command reached provider auth and failed with the expected missing/invalid API key error:
    UV_CACHE_DIR=/tmp/uv-cache uv run ml-intern --model gemini/gemini-3.1-pro-preview --max-iterations 1 --no-stream 'Reply with exactly: OK'
  • Follow-up commit adds GEMINI_API_KEY to README setup and to the friendly auth error text.

Additional checks after the follow-up:

  • UV_CACHE_DIR=/tmp/uv-cache uv run pytest tests/unit/test_llm_params.py tests/unit/test_cli_rendering.py tests/unit/test_llm_error_classification.py
  • npm run build

@github-actions
Copy link
Copy Markdown

github-actions Bot commented Apr 28, 2026

Claude encountered an error —— View job


I'll analyze this and get back to you.

Live CLI validation with a Gemini key reached Google successfully but free-tier quota for both Gemini 3.1 Pro and Gemini 2.0 Flash was exhausted. The failed 3.1 Pro run showed that raw fallback tracebacks can include provider URLs with API keys, so quota and rate-limit errors now render through a friendly message and fallback tracebacks are scrubbed before surfacing.

Constraint: The supplied Gemini key has zero free-tier quota for gemini-3.1-pro and gemini-2.0-flash, so successful Gemini completion could not be validated.
Rejected: Leave quota failures as transient tracebacks | provider URLs may contain API keys.
Confidence: high
Scope-risk: narrow
Directive: Any new direct provider should be represented in auth hints and secret redaction patterns before adding it to selectors.
Tested: UV_CACHE_DIR=/tmp/uv-cache uv run pytest tests/unit/test_llm_error_classification.py tests/unit/test_redact.py tests/unit/test_llm_params.py tests/unit/test_cli_rendering.py
Tested: npm run build
Tested: GEMINI_API_KEY=<redacted> UV_CACHE_DIR=/tmp/uv-cache uv run ml-intern --model gemini/gemini-2.0-flash --max-iterations 1 --no-stream 'Reply with exactly: OK' | provider returned RESOURCE_EXHAUSTED; CLI ended with friendly quota error
Not-tested: Successful Gemini completion; key quota is exhausted / limit 0.
@akseljoonas
Copy link
Copy Markdown
Collaborator Author

Additional Gemini live validation:

  • Tried the supplied Gemini key with the selector model via the real CLI:
    ml-intern --model gemini/gemini-3.1-pro-preview --max-iterations 1 --no-stream 'Reply with exactly: OK'
    Result: authenticated/reached Google, but Google returned RESOURCE_EXHAUSTED with free-tier quota limit 0 for gemini-3.1-pro.
  • Tried a lower-tier Gemini model as requested:
    ml-intern --model gemini/gemini-2.0-flash --max-iterations 1 --no-stream 'Reply with exactly: OK'
    Result: authenticated/reached Google, but Google returned RESOURCE_EXHAUSTED with free-tier quota limit 0 for gemini-2.0-flash.
  • The failed live run exposed that raw provider tracebacks can contain Gemini keys in request URLs. Follow-up commit d1ab7ef adds Gemini key redaction and maps quota/rate-limit failures to a friendly error instead of raw traceback output.

Checks after the fix:

  • UV_CACHE_DIR=/tmp/uv-cache uv run pytest tests/unit/test_llm_error_classification.py tests/unit/test_redact.py tests/unit/test_llm_params.py tests/unit/test_cli_rendering.py
  • npm run build

Security note: the Gemini key used for validation was pasted into chat and appeared in an upstream traceback before the redaction fix; it should be rotated.

@github-actions
Copy link
Copy Markdown

github-actions Bot commented Apr 28, 2026

Claude encountered an error —— View job


I'll analyze this and get back to you.

@fglogan
Copy link
Copy Markdown

fglogan commented May 3, 2026

closed per maintainer request

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants