Rename Opus gate to OPUS_ACCESS_ORG (default ml-agent-explorers)

[akseljoonas]

Summary

The Opus access gate was named after HF staff (HF_EMPLOYEE_ORG, require_huggingface_org_member, _require_hf_for_anthropic) and defaulted to the huggingface org, which reads as "Opus is an employee perk". The actual intent was just "members of a specific HF Hub org" — and the org we want is ml-agent-explorers, which the WelcomeScreen already promotes to every visitor as the way to unlock free HF inference credits.

This is a pure rename + default swap, no behavior change other than which org unlocks Opus.

• HF_EMPLOYEE_ORG → OPUS_ACCESS_ORG, default ml-agent-explorers
• require_huggingface_org_member → require_opus_access_org_member
• _require_hf_for_anthropic → _require_opus_org_for_anthropic
• 403 copy now names the org and points at huggingface.co/ml-agent-explorers
• Stale comments referencing "HF staff" / "HF org membership" updated

Deployment note

Unset HF_EMPLOYEE_ORG on the Space (it's no longer read). Optionally set OPUS_ACCESS_ORG=huggingface if you want the old staff-only behavior. With defaults, anyone who joins ml-agent-explorers via the existing WelcomeScreen tile automatically unlocks Opus.

Test plan

• Logged-in user in ml-agent-explorers → can pick Opus, gets 1/day (free) or 20/day (Pro) per quota
• Logged-in user NOT in ml-agent-explorers → picks Opus → 403 with new copy naming the org
• Dev mode (OAUTH_CLIENT_ID unset) → still unrestricted
• OPUS_ACCESS_ORG=huggingface env override → only staff can pick Opus (old behavior)

[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.

[claude]

Claude finished @akseljoonas's task in 1m 45s —— View job

---

PR Review — Rename Opus gate to OPUS_ACCESS_ORG

• Gather context and understand request
• Read changed files (dependencies.py, agent.py)
• Diff against origin/main
• Check for stale symbol references
• Review: correctness, security, LiteLLM/Bedrock routing impact, merge safety
• Post final review

---

Verdict: LGTM with one minor fix — the rename is clean and internally consistent, but the 403 error body hardcodes the org name rather than reflecting the configured value.

---

Correctness

All three gated call-sites are updated correctly:

• POST /api/session (create_session) ✓
• POST /api/session/restore-summary (restore_session_summary) ✓
• POST /api/session/{id}/model (set_session_model) ✓

No stale references to HF_EMPLOYEE_ORG, require_huggingface_org_member, or _require_hf_for_anthropic remain anywhere in the codebase.

Security

The gate logic in dependencies.py is unchanged — only the env var name and default value differ. The dev-mode bypass (AUTH_ENABLED check), the positive-only membership cache, and the check_org_membership function itself are all untouched. Security posture is equivalent to before.

Bug — 403 message hardcodes ml-agent-explorers (agent.py:90-91)

"message": (
    "Opus is gated to ml-agent-explorers members. Join the "      # ← hardcoded
    "org on huggingface.co/ml-agent-explorers, or pick a "        # ← hardcoded
    "free model — Kimi K2.6, MiniMax M2.7, or GLM 5.1."
),

If an operator sets OPUS_ACCESS_ORG=huggingface (the PR's own rollback instruction), the gate will correctly enforce huggingface membership, but the 403 will still tell the user to join ml-agent-explorers. The fix is to import OPUS_ACCESS_ORG from dependencies and interpolate it:

from dependencies import get_current_user, require_opus_access_org_member, OPUS_ACCESS_ORG
# …
"message": (
    f"Opus is gated to {OPUS_ACCESS_ORG} members. Join the "
    f"org on huggingface.co/{OPUS_ACCESS_ORG}, or pick a "
    "free model — Kimi K2.6, MiniMax M2.7, or GLM 5.1."
),

Fix this →

Note — auth.py:174 not in scope but worth flagging

backend/routes/auth.py has its own separate ORG_NAME = "ml-agent-explorers" constant (pre-existing, not touched by this PR) used by the /auth/org-membership endpoint. The frontend likely calls this to decide whether to surface the Opus option in the UI. If OPUS_ACCESS_ORG is overridden, the /auth/org-membership response won't reflect the new org — the UI may still show Opus as locked/unlocked based on the wrong org. Low severity for typical use, but creates a confusing gap if the env var is ever changed.

LiteLLM / Bedrock routing

No impact. The gate fires before any LLM call is made. No Bedrock models are in AVAILABLE_MODELS; all non-Anthropic paths are routed through HF Router and are completely unaffected.

Merge safety

The community review flagged a conflict — I can't verify the rebase state without remote access in this environment, so maintainers should confirm the branch is rebased on current main before merging. Logic and diff look correct on their own.

---