# Fix list: GPT-Live From Anchor Terminal's listing at https://www.anchorterminal.com/tools/gpt-live, the October 2026 research run, assessed 17 October 2026. Grade B, 66.8 out of 100. This is everything the published grade says the listing lacks, the biggest possible gain to the total first. It comes from the reason given for each score, the checklist each category was scored against (https://www.anchorterminal.com/benchmark/#checklist), the provenance checks, the deductions, what we couldn't check and what the review panel asked for. A fix counts at the next check, once it's public. For a coding agent working on GPT-Live: work through the items below in the product, its docs and its public pages. Each category gives the reason for its score, with the points each checklist item earned, and the checklist itself, so the gap is the items that earned less than their points. Change the product, not the wording, and keep a note of what you changed and where it's published. ## 1. Payments & pricing, 20 out of 100, up to 10 more on the total Why it scored 20: No x402, MPP or L402 in the docs or the OpenAPI file (0 of 40). The per-minute session price is published without a login on the model and pricing pages (20). The model page lists the Free usage tier as unsupported for `gpt-live-1` (0). API keys are created in the platform after a browser sign-in (0). The checklist (https://www.anchorterminal.com/benchmark/#checklist-payments): The published rubric, also on the [x402 page](https://www.anchorterminal.com/x402/). - 40, a machine payment protocol (x402, MPP or L402) on the tool's own endpoints. 10 to 30 when it covers only some endpoints or only goes through a third party, and the note says which. - 20, per-call or per-unit pricing published without a login. 10 for public plan-only pricing, 0 for "contact sales" or prices behind a login. - 20, a free tier or trial that doesn't need a card. - 20, autonomous onboarding, meaning an agent can get access without a person signing up in a browser (keyless use, x402, a programmatic key API). Payment platforms and agent wallets rarely charge for their own API over a machine protocol, so the first line has steps for them, and the highest one that applies counts. 40 when x402, MPP or L402 runs on all their own endpoints, 30 when it runs on part of their own API, 25 when their merchants can accept one, 20 for running a facilitator, 15 for paying as a buyer, and 0 when the only protocol is their own. Merchant acceptance sits above a facilitator because the platform's own customers can charge agents through it, while a facilitator settles for sellers who wire up the protocol themselves. The counter-argument (a facilitator does more for the protocol as a whole) has a point. Each note says which step applied. Open-source software you run yourself is scored on its hosted or paid option if it has one. A free, self-hosted package with nothing to buy gets 20, 20 and 20 for the last three lines, and 0 to 40 for the first only if it ships a payment protocol. ## 2. Reliability, 62 out of 100, up to 7.6 more on the total Why it scored 62: Graded as a hosted API. status.openai.com has a Live component under APIs (20). Its data starts on 16 October 2026, five weeks after general availability, and the status feed since 19 July names no incident for it, so there is no readable history for the period (5 of 30). The model page publishes concurrent session limits per tier, 50 on Build, 300 on Launch and 500 on Grow, and the SIP guide gives a 3-minute ringing limit and a 2-hour call limit (15). The OpenAPI file lists 429 and 503 on session creation and the rate limits guide documents `Retry-After` and backoff. Safe-retry guidance is explicit (check an action's outcome before retrying, deduplicate webhooks and events by ID, never retry an outbound call after a timeout), but session creation has no idempotency key (12 of 15). No SLA was found in the developer docs, and openai.com answered 403 (0). Generally available since 10 September 2026 (10). Native Decisions delegation depends on the Decisions API, which is in public beta, and was not scored separately. The checklist (https://www.anchorterminal.com/benchmark/#checklist-reliability): Hosted APIs, MCP servers, models and platforms. - 20, a public status page with component history (Statuspage, Instatus, BetterStack or the vendor's own). - 0 to 30, the incident record for the last 90 days on that page. 30 for a clean record or trivial incidents only, 20 for minor incidents only, 10 for one major outage (an hour or more of a core API down, or errors across the board), 0 for several. 5 when there's no history we could read, and the note says so. - 15, rate limits documented with numbers. - 15, documented 429 or overload handling (Retry-After, backoff guidance), and idempotency keys or safe-retry guidance where writes are involved. - 10, an SLA published for any paid tier. - 10, the surface agents use is generally available, not beta or preview. Local packages, SDKs, frameworks and stdio MCP servers. - 20, installs from an official package with supported runtimes stated. - 25, a public CI and test suite, passing on the default branch. - 0 to 25, open crash or regression issues relative to activity (25 for few and handled, 0 for many, old and unanswered). - 15, semver discipline and breaking changes called out in a changelog. - 15, version 1.0 or later, or declared stable. Protocols are read from their reference implementations, the public facilitators or servers, spec stability and test vectors. ## 3. Security & auth, 66 out of 100, up to 6 more on the total Why it scored 66: The project API key is sent as a Bearer header from a server, and WebSocket connections take no query parameters. GPT-Live has no browser client secret, so the key never reaches a browser and the server creates each session. Per-permission keys exist (`api.decisions.write`, `api.responses.write`), and the docs index lists workload identity federation, mutual TLS and IP allowlists. Key rotation was not read (24 of 30). The WebRTC data channel can be limited to listed client and server events for an untrusted frontend, though the default allows all. The application runs custom functions and answers MCP approval requests (15 of 20). The guardrails guide describes checking input transcripts for jailbreak attempts and blocking actions until checks pass, the SIP guide says to treat SIP headers as untrusted, and the session guide says to keep trusted instructions apart from user messages and results. No guidance on injected content in hosted tool results was found (9 of 15). Usage events per session, a final session snapshot, optional stored recordings and Admin APIs with audit log retrieval per the docs index (10 of 15). security.txt is PGP-signed with a Bugcrowd contact and a disclosure policy, and repositories carry SECURITY.md. Certifications and the trust portal on openai.com were not read (403) (8 of 20). The checklist (https://www.anchorterminal.com/benchmark/#checklist-security): - 0 to 30, the credential model. 30 for OAuth 2.1 with scopes, or scoped and revocable keys with rotation. 20 for plain revocable API keys. 10 for one all-powerful key. 10 off when a secret can travel in a URL query string as a documented option. - 0 to 20, read-only or least-privilege modes, and confirmation or approval for destructive actions. - 0 to 15, prompt-injection posture where the tool returns untrusted content (documented mitigations or guidance). A tool that returns no untrusted content gets 10. - 0 to 15, audit logs or per-call visibility for the operator. - 0 to 20, a security programme. security.txt or a disclosure policy, a bug bounty, SOC 2 or ISO 27001, advisories handled in public. Models are read for retention, whether API data trains models (and whether that's off by default), zero-retention options and certifications. Frameworks for telemetry defaults, approval hooks, guardrails and sandboxing. ## 4. Agent ergonomics, 76 out of 100, up to 3.9 more on the total Why it scored 76: Scored as a model API. Context is managed by the service in a 128,000-token window with background summaries, startup history is capped at 128 messages and 8,192 tokens, and `session.usage.updated` reports a context `usage_ratio`. The client cannot set its own truncation (20 of 25). There are no lists to page. The WebRTC frontend can be restricted to listed server events, transcripts are optional, and backend `max_output_tokens` is configurable (12 of 20). Errors carry code, param and the `client_event_id` of the failed command, configuration errors have their own code, and `session.closed` gives a reason (17 of 20). Commands are matched to acknowledgements by `event_id`, the sideband replays 3 seconds with original event IDs, and stored sessions can be forked to resume after a drop. Session creation has no idempotency key and outbound calls must not be retried (12 of 20). Only `model` is required, the voice defaults to `marin`, and the `openai` SDKs for Python and Node.js have Live resources, with partner integrations for LiveKit and Pipecat (15). The checklist (https://www.anchorterminal.com/benchmark/#checklist-ergonomics): - 0 to 25, context cost. For MCP, the number and size of the tool definitions (25 for ten or fewer compact tools, 15 for 11 to 30, 5 for more than 30, plus up to 10 back for toolsets, dynamic loading or read-only subsets). For APIs, whether responses can be sized (field selection, limits, summaries). - 20, pagination, filtering and output-size controls. - 20, actionable, documented error responses, codes and messages an agent can recover from. - 20, idempotency or safe retries, and for MCP the `readOnlyHint` and `destructiveHint` annotations. - 15, sensible defaults, few required parameters, and official SDKs in at least two languages. Models are read for tool use, structured output, prompt caching, context length, batch and SDKs. Frameworks for how much code and how many defaults a tool-calling agent with MCP needs. ## 5. Schema & documentation, 87 out of 100, up to 2.1 more on the total Why it scored 87: The OpenAPI 3.1 file in `openai/openai-openapi` (updated 17 October 2026) has seven `/live/sessions` paths and 172 Live schemas, with 15 client and 27 server events on the primary connection and 13 and 23 on the sideband. It is not an AsyncAPI document, so the WebSocket channels are described only as event schemas (22 of 25). llms.txt and a Markdown twin of every page (10). The delegation guide has a table of when to choose Responses or client delegation, the connection guides say when to use WebRTC, WebSocket or SIP, and the Decisions guide says when to delegate or react to transcripts (17 of 20). Fields carry enums and limits, such as `delegation.type`, SIP reject codes 300 to 699 and 500-token appends, but `model` also accepts any string and the Live MCP tool schema types only `type` (12 of 15). Python and JavaScript examples on every guide, an `error` event with a documented shape and several named codes, and a table of close reasons. No full catalogue of Live error codes was found, and three JavaScript examples in the Markdown twins are empty (12 of 15). A dated changelog tags entries with `v1/live/sessions`, there is one snapshot, and the deprecated webhook event is named (14 of 15). The checklist (https://www.anchorterminal.com/benchmark/#checklist-schema): APIs and MCP servers. - 25, a machine-readable contract (a public OpenAPI file or similar; for MCP, typed JSON Schema inputs on every tool). - 10, llms.txt or Markdown docs served for agents. - 0 to 20, descriptions that say what a tool is for, when to use it and when not to, read from the tool definitions in the source or the API reference. - 0 to 15, typed inputs with enums, constraints and required fields, and no free-form JSON blobs. - 0 to 15, examples and documented error responses. - 15, versioning and a public changelog. Models are read from the API reference, the OpenAPI file, llms.txt, the structured-output and tool-use docs and the model cards. Frameworks from docs a model can follow, typed interfaces, examples and the API reference. ## 6. Transparency & trust, 76 out of 100, up to 2.1 more on the total Made of editorial 58, provenance 94. Why it scored 76: Closed service. The Python SDK is Apache-2.0, and the OpenAPI file and the Live Console sample are MIT. The service terms and the service terms that cover prompt-to-voice were not read because openai.com answered 403 (10 of 30). The data controls page says `/v1/live/sessions` data is not used for training, abuse logs are kept up to 30 days, recordings are stored for 30 days only when `store` is true and storage is enabled, and Zero Data Retention disables storage. It also says there is no public endpoint to delete a stored session, and prompt-generated voices are kept until deleted. The privacy policy and DPA were not read, so agreement between them is unchecked (18 of 30). The deprecations page states at least six months' notice for generally available models and lists dated shutdowns (20 of 20). US and EU data residency are listed for `/v1/live/sessions`. The sub-processor list was not read (10 of 20). The checklist (https://www.anchorterminal.com/benchmark/#checklist-transparency): - 0 to 30, source availability and licence clarity. 30 for open source under an OSI licence, 15 for closed with clear terms, 0 for unclear terms. - 0 to 30, data handling and retention statements that agree with each other (privacy policy, DPA, retention periods, subprocessors). - 0 to 20, a deprecation policy or notices with dates. - 0 to 20, telemetry disclosed with an opt-out (local software), or subprocessors and data locations disclosed (hosted). The other half of Transparency and trust is the provenance score, computed from checked facts (below). The category score is the mean of the two. Provenance checks not met in full (half of this category, computed from checked facts): - Terms of service: published, but our reader couldn't read it (7 of 10) - Privacy policy: published, but our reader couldn't read it (7 of 10) ## 7. Maintenance & community, 82 out of 100, up to 1.6 more on the total Why it scored 82: The last dated changelog entry tagged `v1/live/sessions` is 16 October 2026, one day before the check (30). Three entries in the last 90 days, on 10 September, 15 October and 16 October (20). Closed service with a changelog updated several times a week and a community forum and Discord linked from the docs, which we did not test (10 of 15). Current official SDKs, with `openai` for Python at 3.33.0 on 16 October 2026 and Live fixes in several releases since 10 September (15). The SDK is Apache-2.0 and released often. Its CI results were not read (7 of 10). The checklist (https://www.anchorterminal.com/benchmark/#checklist-maintenance): - 0 to 30, time since the last release, or the last published model or API change for a closed service. 30 within 30 days, 20 within 90, 10 within 180, 0 older. - 20, at least three releases or dated changelog entries in the last 90 days. - 0 to 25, responsiveness. Issues and pull requests answered on GitHub (the open issues and how recent the replies are). For closed services, a public changelog and a support or community channel that answers, 0 to 15. - 15, presence in the official MCP registry under a verified namespace (MCP servers), or current official SDKs (APIs and models). - 10, package health, current dependencies and CI. Models are read for deprecation notice periods and model churn rather than release counts. ## What we couldn't check What we couldn't read counted as absent. Publishing it on a page a plain HTTP fetch can read (not only in a browser) lets the next check count it. - unchecked: the services agreement, the service terms (which the custom voices guide says cover prompt-to-voice), the privacy policy, DPA, sub-processor list and trust pages on openai.com. Both policy URLs answered 403 on 17 October 2026, and the provenance block keeps the entity and links from the OpenAI API listing's check of 26 September. - unchecked: whether an SLA is published for any tier. None was found in the developer docs. - unchecked: incident history for GPT-Live between 10 September and 16 October 2026. The status page had no Live component before 16 October, and the feed names none. - unchecked: the maximum length of a WebRTC or WebSocket session. The close reasons table names a duration limit without giving it. The 2-hour limit found applies to SIP calls. - unchecked: concurrent session limits for tiers above Grow, and whether failed or rejected session creations are billed. - unchecked: GitHub stars and package download counts. pypi.org's JSON API is disallowed by robots.txt and was not read. - firstReleased is 2026-09-10, the changelog's general availability entry, matched by the Python SDK's 3.12.0 release and the first commit of the Live Console sample. No earlier preview was found in the changelog. - The scout was right on the interface, the model and the two additions of 15 and 16 October. Native Decisions delegation depends on the Decisions API, which its guide says is in public beta. Category voice-agents. First capability `voice.speech-to-speech`, as the scout suggested, because GPT-Live is the voice layer and delegates reasoning. openai-realtime lists `voice.agent` first. - GPT-Live is neither LocalGhost's job (a hosted API, not on the owner's device) nor letme's (it routes a conversation to one backend the developer configures, not tasks between tools). ## Weaknesses - openai.com answered 403 to our reader on 17 October 2026, so the service terms, privacy policy and security pages were not read. - The Live component on status.openai.com has data only from 16 October 2026, so the five weeks since general availability have no readable history. - The Free usage tier is not supported for `gpt-live-1`, and no keyless or machine payment route was found. - There is no public endpoint to delete a stored session recording. Stored recordings expire after 30 days. - Session creation has no idempotency key. The SIP guide warns that retrying an outbound call after a timeout can place a second call. ## What costs an agent a turn today The notes we give agents before they call it. Each one is a workaround an agent shouldn't need. - Create sessions on a server with the project API key. GPT-Live has no browser client secret, so the server exchanges the browser's SDP offer with `POST /v1/live/sessions`. - Choose `delegation.type` at creation. Changing between client, Responses and Decisions delegation needs a new session, and `delegation: null` selects client mode. - After `session.started`, listen for `error` with code `responses_validation_failed`. Responses settings are validated asynchronously and are not rolled back. - Do not retry an outbound SIP `POST /v1/live/sessions` after a timeout. Attach the sideband at once, since it replays only the last 3 seconds of events. - Keep the transport open until `session.closed` to read the final `usage.seconds`. A WebRTC session bills 15 seconds at creation, credited once it runs. ## What the review panel asked for - Say whether failed creations are billed - Publish every Live error code - Fill the empty JavaScript examples - Add an idempotency key to session creation - Publish a session duration limit - injection guidance for hosted tools - stored session deletion endpoint ## When it's done Send what changed and where it's published as a dispute (https://www.anchorterminal.com/builders/#disputes, or `POST https://www.anchorterminal.com/api/v1/contact` with `"kind": "dispute"`). Disputes are answered in public, and the listing is checked again by the same checklist. Paying for an audit or a listing claim changes nothing here.