hermes - 💡(How to fix) Fix [Feature]: Document gpt-realtime-2 as a supported OpenAI Realtime model in google_meet plugin [1 pull requests]

Problem or Use Case

OpenAI shipped gpt-realtime-2 (GPT-5-class voice reasoning, 128K context) on 2026-05-07 alongside the Realtime API GA. The new model is the canonical recommendation for new realtime agents per OpenAI's own SDK guidance (verified across openai-python, openai-node, openai-go, openai-ruby, openai-java, openai-dotnet, and openai-cookbook).

Hermes has one OpenAI Realtime integration in main today: the google_meet plugin (plugins/google_meet/realtime/openai_client.py). The model name flows from HERMES_MEET_REALTIME_MODEL (default gpt-realtime) directly into the WebSocket URL with no validation. A user could already set HERMES_MEET_REALTIME_MODEL=gpt-realtime-2 today, but:

1. Plugin docs do not mention gpt-realtime-2 exists.
2. The website's built-in-plugins page documents the plugin generically without listing the env var or supported identifiers.
3. No test pins the contract that the model identifier flows verbatim into the WebSocket URL; a wiring regression could silently break realtime voice without anyone noticing.

This is purely a discoverability and contract-pinning gap. The runtime path already supports any string; the missing pieces are docs and a test.

Proposed Solution

Three small documentation edits and one test parametrize. No production code changes. Defaults preserved.

1. plugins/google_meet/README.md: add a ### Configuring the OpenAI Realtime model subsection under ## Realtime mode documenting HERMES_MEET_REALTIME_MODEL, HERMES_MEET_REALTIME_VOICE, HERMES_MEET_REALTIME_KEY, HERMES_MEET_REALTIME_INSTRUCTIONS, plus a supported-identifier table listing gpt-realtime (default), gpt-realtime-2 (recommended for new agents), and the dated snapshot gpt-realtime-2025-08-28.
2. plugins/google_meet/SKILL.md: add a one-line note in the body referencing the env var and the new alias so the agent system prompt advertises the capability.
3. website/docs/user-guide/features/built-in-plugins.md: add a **Realtime mode (optional):** subsection in the ### google_meet section mirroring the existing Langfuse env-var table style, listing the same identifiers.
4. tests/plugins/test_google_meet_realtime.py: parametrize the existing handshake test over ["gpt-realtime", "gpt-realtime-2"] so both identifiers are pinned to flow verbatim into the WebSocket URL via RealtimeSession.connect(). Reuses the existing _FakeWS + _install_fake_websockets pattern; no live API calls.

Defaults stay at gpt-realtime. Users opt into gpt-realtime-2 by setting the env var. Hermes does not validate the value, so future identifiers OpenAI ships will work without a Hermes upgrade.

Alternatives Considered

1. Bump the default to gpt-realtime-2. Rejected: would change behavior for every user who never set the env var, and gpt-realtime is still a stable supported identifier.
2. Add an allowlist or model registry. Rejected: none exists today, the env var already accepts any string, and OpenAI may ship more aliases. A registry would be premature abstraction.
3. Defer to OpenAI docs only. Rejected: the OpenAI doc page currently 403s on programmatic fetch and Hermes users discovering features via plugins/google_meet/README.md or SKILL.md would never learn the new model exists.
4. Wait for #21445 (Discord OpenAI Realtime voice bridge) to merge first. Rejected for the Google Meet path; Discord can land a parallel small follow-up after #21445 merges, mirroring the docs+test approach used here.

Feature Type

Configuration option

Scope

Small (single file, < 50 lines)

Contribution

• I'd like to implement this myself and submit a PR