docs(Claude): document existing backends, protocols and feature limits [P1; independent] #4581

🤖 Automated architect agent — this comment was posted by the architect bot from Docker Agentic Platform, not by a human engineer

What

Publish a source-backed guide to the Claude access paths docker-agent actually has, including protocol, host, authentication, model identity and feature limitations. Distinguish current implementation from the planned Claude 5.x compatibility work.

This is a documentation-only increment with no model-default, code, schema or authentication-policy change. It is independently useful: users can choose the correct endpoint now without waiting for the core/fallback fixes.

Why

“Anthropic Direct, Vertex and Bedrock” is not a complete description of how users reach Claude, and a platform name alone does not establish the API or feature contract.

Existing repository evidence

At research revision 49e4ca657fd454e9d46ea258e8cf61c517df9aab:

• Anthropic client construction supports direct Messages, a custom base_url, and Models Gateway construction. These are different hosts, not automatic capability/pricing equivalence.
• Vertex dispatch and its native client/auth use native prediction, not OpenAI Chat Completions.
• Bedrock's call is ConverseStream, not InvokeModel or Mantle.
• Provider aliases are OpenAI-compatible. OpenCode's Messages configuration is a separate custom-provider path. Do not equate the default OpenCode alias with it.

These code links explain integration behavior; vendor documents below do not mandate how docker-agent should organize its registry.

Official documentation motivating the changes

• Claude migration index and model IDs and versions: 5.x dateless IDs are pinned snapshots, not rolling aliases.
• Claude on Vertex: project/location, OAuth and native prediction request dialect differ from the Claude API. The model belongs in the URL; anthropic_version belongs in the body.
• AWS Mythos 5 card, Mythos 5.1 card and endpoint table: Mythos 5 is Mantle-only and unsupported on runtime/Converse; Mythos 5.1 is supported on runtime, not Mantle. No new Mantle integration is part of this issue.
• Compaction overview documents Google on-demand compaction; the Vertex integration currently rejects it. Say “not integrated,” not “Google does not support it.” AWS compaction explicitly excludes Converse and requires InvokeModel for both mechanisms.
• Google structured outputs: capability is disabled by default by organization policy. Generic examples do not override model-specific 5.x prefill restrictions. General Bedrock feature statements must not override a specific model card.
• Mythos 5 overview and Mythos 5.1 overview announce Google limited access; the audited Google Claude directory had no dedicated Mythos card. Absence of a card is neither proof of absence nor account entitlement.
• Preserved thinking: libraries, proxies and gateways: intermediary rewrites count as prefix edits. An OpenAI-compatible Claude endpoint does not inherit Messages signed-history or constrained-decoding guarantees.

How — indicative

Add a concise transport/host/auth/ID/guarantee table to the Anthropic/provider overview and cross-link Google, Bedrock, custom providers and OpenCode guides. Reuse existing configuration examples and schema. List wrappers (routing, first_available, instrumentation) as composition, not new transports.

Describe native Mantle/InvokeModel/Foundry/Claude Platform on AWS as not wired by this integration, even if SDK integrations or compatible custom-endpoint possibilities exist. Do not claim those custom configurations have been tested. Do not infer that every aggregator offers every Claude model.

Use a source date and explicit evidence labels. Cover the nine models: Haiku 5.5; Opus 5/5.5; Sonnet 5/5.5; Fable 5/5.1; Mythos 5/5.1. Across the three native families, the audit found 24 corroborated pairs, 2 limited-access Mythos/Google announcements and 1 unsupported Mythos 5/Converse pair. This is not 26 implemented or live-tested successes.

Acceptance criteria

• Native adapters, custom Messages hosts, Models Gateway and OpenAI-compatible aggregators are distinct. OpenCode alias vs Messages and Azure alias vs native Foundry are not conflated.
• All nine model names/IDs and evidence levels are documented; AWS profile IDs come from the specific model's documentation rather than invented normalization.
• Native compaction and structured-output limitations distinguish service support, client integration and organization/account prerequisites. No consent or cloud setting is changed.
• Current documentation does not claim that the future 5.x core is already complete, or that a proxy preserves signatures/betas/prices by default.
• Links and rendered docs are checked; examples match the existing schema. Follow repository docs validation. For a docs/**-only PR, skipped Go jobs are reported as skipped, not passed.
• This increment is merged/delivered with its own docs validation; drafting or opening a PR is not completion.

Dependencies and boundaries

No technical dependency on clone fixes, #4576, the core or server fallback. Shipping this first is recommended but does not block those workstreams technically; every later code PR still updates its own behavior documentation. #4116 stays separate. This issue changes no implementation and does not close #4553.

Implementation PR linkage: pending.

Epic: #4580

Cross-links

Epic: #4580. Independent clone correction: #4582. Future atomic core: #4583. Future server fallback: #4584. External routing-price work: #4576; this documentation issue does not depend on it. No implementation PR is linked yet.