Add GPT-5.5 as a selectable model

[lee101]

Adds OpenAI GPT-5.5 to the model picker, backend allowlist, CLI suggestions, and token-window map.

[lewtun]

GPT-5.5 is not available in OpenAI's API yet

[akseljoonas]

@claude please review this PR. Focus on correctness, security, LiteLLM/Bedrock routing impact, and whether it's safe to merge against current main. Keep it concise and prefer inline comments where it matters.

[akseljoonas]

@claude please re-review this PR following the REVIEW.md rubric at the repo root (P0/P1/P2 severity, rigor bias, explicit merge verdict, What-I-checked coverage list). The previous Claude review on this PR was posted before REVIEW.md existed and has been removed.

[claude]

Claude finished @akseljoonas's task in 2m 12s —— View job

---

PR Review: Add GPT-5.5 as a selectable model

1 P0, 2 P1 — DO NOT MERGE

---

P0 — Model does not exist; ships broken option to all users as "Recommended"

openai/gpt-5.5 is not a public OpenAI API model (confirmed by @lewtun above). The routing chain is straightforward:

1. User selects GPT-5.5 from the picker
2. POST /api/session/{id}/model validates it is in AVAILABLE_MODELS — passes (agent.py:319-321)
3. _require_hf_for_anthropic skips it — the guard only fires when "anthropic" in model_id (agent.py:79, 92)
4. _resolve_llm_params("openai/gpt-5.5", ...) returns {"model": "openai/gpt-5.5", ...} — no api_base override (llm_params.py:165-175)
5. LiteLLM calls OpenAI's API with model name gpt-5.5 → model-not-found error

Both backend and frontend mark the entry recommended: true (agent.py:62, ChatInput.tsx:51), so it is shown with a "Recommended" badge at the top of the picker for every user. The first thing users try will fail.

Merge-blocking until the model is confirmed generally available on the OpenAI API. If this is pre-emptive work, drop recommended: true from all four touch-points and consider adding a note in the label (e.g. "GPT-5.5 (coming soon)") so the breakage is explicit rather than silent.

---

P1 — No auth or billing gate for OpenAI models

All other paid models in AVAILABLE_MODELS are either HF-routed (billed via X-HF-Bill-To to the Space owner) or Anthropic-gated (guarded by _require_hf_for_anthropic to HF org members). openai/gpt-5.5 is marked tier: "pro" but has no corresponding gate. _is_anthropic_model only checks for "anthropic" in the id (agent.py:79), so any authenticated user can select this model and cause the Space to bill against its OPENAI_API_KEY.

This is the first openai/-prefixed model in AVAILABLE_MODELS; the pattern for guarding it doesn't exist yet. Before merging, either gate it behind HF-org membership (same as Anthropic) or document that OpenAI billing is intentionally open to all.

P1 — OPENAI_API_KEY is not configured in the Space environment

llm_params.py:110 explicitly says LiteLLM uses OPENAI_API_KEY for openai/ models. That key appears nowhere in the Dockerfile, README, or any env-var documentation in this repo. Even if GPT-5.5 were a real model, calls would fail with an auth error unless the key is manually set in the Space secrets. The PR description doesn't mention this prerequisite.

---

What I checked

• Full routing chain end-to-end: ChatInput.tsx → POST /api/session/{id}/model → AVAILABLE_MODELS allowlist → _require_hf_for_anthropic (agent.py:82-104) → _resolve_llm_params (llm_params.py:165-175) → LiteLLM → OpenAI API
• _is_anthropic_model guard logic and whether it fires for openai/ prefix (agent.py:79) — confirmed it does not
• _LOCAL_MAX_TOKENS entry in session.py:19-21 — correct defensive pattern; the 1M value is unverified but the fallback logic is sound and won't cause a crash
• Existing AVAILABLE_MODELS entries to understand the established gate pattern for paid models
• model_switcher.py:67 — openai/ prefix bypasses HF router catalog check entirely, consistent with the rest of the codebase
• OPENAI_API_KEY presence in Dockerfile, README, and all .py files — not present outside llm_params.py's docstring
• Frontend findModelByPath and firstFreeModel helpers — behavior unchanged by this PR, no regressions

---