The Claude Opus 5 Rumor Passed the Screenshot Test, Not the API Contract Test

A Rumor Acquired Production Vocabulary Most model rumors stay vague. This one arrived with configuration language. One social image claimed claude-opus-5 was live on Vertex and would launch soon. A second, more persuasive screenshot appeared to show a Cursor model picker with “Honeycomb EAP 1M Extra High.” Its tooltip called Honeycomb an Anthropic research model with per-turn controls, safety fallbacks, early-access status, a one-million-token context window, and extra-high effort. Other posts supplied a release window and a product theory. Opus 5 would arrive within a week or two. It would fill the cost-performance gap between Opus 4.8 and Fable 5. A fallback to Opus 4.8 supposedly proved that Honeycomb was stronger and therefore probably Opus 5. The package sounded operational. It was still missing the operational object that matters: a supported model contract. What the Current Catalogs Actually Said The audit used July 15, 2026 as its cutoff. Anthropic's current model overview documented claude-fable-5, claude-opus-4-8, and claude-sonnet-5. Its pricing documentation supplied the commercial baseline. Model Documented ID Standard input Standard output Claude Fable 5 claude-fable-5 $10/MTok $50/MTok Claude Opus 4.8 claude-opus-4-8 $5/MTok $25/MTok Claude Sonnet 5 claude-sonnet-5 $2/MTok through August 31, 2026 $10/MTok through August 31, 2026 Anthropic said Sonnet 5 would move to $3/MTok input and $15/MTok output on September 1, 2026. It also priced Opus 4.8 Fast Mode at $10/$50, a detail that complicates the simple claim that Fable is always “twice the price” of Opus. Google Cloud's current Claude partner-model catalog contained dedicated entries for Sonnet 5, Fable 5, and Opus 4.8. Cursor's current model catalog likewise exposed public pages for Fable 5, Opus 4.8, and Sonnet 5. None of those current catalogs listed Opus 5 or Honeycomb. That finding is narrower than “the screenshot is fake.” It means the public catalogs did not support the release claim on the audit date. Why the Honeycomb Screenshot Remained Unauthenticated The screenshot is the strongest rumor artifact because it contains product-like detail. It is also missing the fields that would make the detail auditable. There is no visible absolute date. No Cursor build number. No source post URL. No account entitlement. No network response. No public changelog. No official Anthropic model card. It may depict a genuine private experiment. It may show a short-lived feature flag. It may be a mockup, a staging state, a translated capture, or a real label that never becomes a public product. The image cannot choose among those possibilities. The one-million-token label does not authenticate it either. Anthropic's current pricing page states that Fable 5, Opus 4.8, and Sonnet 5 all include the full 1M-token context window at standard pricing. A shared context limit cannot function as a unique model fingerprint. The screenshot also says “safety fallbacks,” not “fallback to Opus 4.8.” The stronger routing claim is absent from the visible artifact. There is a real, documented fact nearby. Anthropic describes Fable 5 as its most capable generally available model. Its Fable 5 and Mythos 5 announcement explains that certain safeguarded requests may receive a response from Opus 4.8, which Anthropic calls its next-most-capable generally available model. Anthropic's support article explains the user-facing switch. That confirms Fable behavior. It does not confirm Honeycomb behavior. A fallback can be chosen for capability, policy coverage, latency, entitlement, regional capacity, or compatibility. Even a confirmed fallback target would describe routing policy, not automatically establish an unknown model's public name or generation. The rumor took an official fact from one model and used it to certify another. How an Unverified Name Becomes a Production Incident Adding a guessed model ID behind fallback can feel cautious. It can also make the mistake harder to detect. Consider the sequence: The router requests claude-opus-5. The provider rejects the unknown ID. A retry adds several seconds. Fallback routes to Opus 4.8. The user receives a valid answer. Telemetry records only the requested label. The request looks successful. The data is wrong. Latency now includes a failed primary attempt. Token cost belongs to the fallback. Quality belongs to the fallback. The error rate may be attributed to a provider outage instead of invalid configuration. An evaluation grouped by requested model can credit Opus 5 for outputs it never produced. Agents add more waste. Retrieval, tool planning, context assembly, and reserved capacity may happen before model resolution fails. Replaying that state against a fallback can create a second incompatibility if tool behavior, context handling, or safety policy differs. This is why model verification belongs inside reliability engineering, not only editorial fact-checking. A Seven-Gate Availability Test The following gates turn a launch from a social event into a controlled dependency update. Gate 1: Identity Require a first-party announcement or model page and an exact documented ID. Do not derive the ID by autocomplete. Gate 2: Surface and region Confirm the intended provider surface, project, account tier, entitlement, and region. Direct API availability does not guarantee cloud-marketplace availability, and the reverse does not establish universal access. Gate 3: Commercial contract Record price, rate limits, context and output limits, cache and batch rules, preview restrictions, data terms, and retirement policy. A successful test call is not yet a production budget. Gate 4: No-fallback canary Send a minimal authenticated request with retries and automatic fallback disabled. Store the raw response or raw terminal error. This test proves model resolution, not intelligence. Gate 5: Capability matrix Test the exact features the application uses: streaming, cancellation, tool schemas, structured output, images, documents, caching, long context, safety errors, and timeouts. Gate 6: Resolved-model telemetry Log requested_model and resolved_model separately, along with provider, region, attempt count, fallback reason, token usage, latency, and raw error code. Gate 7: Controlled rollout and rollback Begin with internal or low-percentage traffic. Keep the previous documented model available. Define rollback criteria before launch rather than after the first incident. The rumor article also described Fable 5 as “free” inside subscriptions and said Anthropic had extended the promotion three times. The official promotional-access page said eligible paid-plan users could use Fable 5 at no extra cost through July 19, 2026 at 11:59:59 PM PT, but only for up to 50% of their regular weekly usage. API usage was excluded. Anthropic's redeployment announcement originally named July 7. The current support page showed a July 12 update and a July 19 end date. The accessible first-party record did not preserve enough history to substantiate “three extensions.” Even a July 7 to July 12 to July 19 sequence would describe two extensions. Mutable pages need timestamps. Promotional wording needs mechanics. “Free” is not precise when usage consumes the normal plan allowance. The Limitation: Current Absence Is Not Historical Proof The audit can say what the catalogs contained on July 15. It cannot prove that no private test, employee build, partner entitlement, or transient UI entry ever used Honeycomb or Opus 5. Proving historical nonexistence would require logs, authenticated archives, or first-party testimony that the researchers did not have. This limitation cuts both ways. The absence finding should not be inflated into “the leak was fake.” The screenshot should not be inflated into “the model launched.” The accurate status is unconfirmed. If Anthropic later releases Opus 5, that future release will need a new timestamp, model ID, price, access map, and capability test. It will not retroactively turn an unsupported release-date claim into verified reporting. The Engineering Conclusion A screenshot can be worth investigating. It should never be enough to make a model routable. Store rumors in a watchlist. Store documented IDs in an integration registry. Store callable, compatible models in a canary pool. Put a model into production only after telemetry and rollback are ready. The rule is deliberately unexciting: Discover the ID. Verify the surface. Disable fallback. Test the contract. Observe the resolved model. Then route. Sources and Further Reading Anthropic model overview Anthropic API pricing Claude Opus product page Introducing Claude Opus 4.8 Claude Fable product page Claude Fable 5 and Claude Mythos 5 announcement Redeploying Claude Fable 5 Claude Fable 5 promotional access Why Claude switched models in a Fable 5 conversation Claude Sonnet product page Introducing Claude Sonnet 5 Google Cloud Claude model catalog Claude Sonnet 5 on Google Cloud Claude Fable 5 on Google Cloud Claude Opus 4.8 on Google Cloud Cursor model catalog Claude Fable 5 in Cursor documentation Claude Opus 4.8 in Cursor documentation Claude Sonnet 5 in Cursor documentation