Skip to content

docs: codify the binding rule for PROVIDER_ID; refresh stale sections - #85

Open
pofallon wants to merge 1 commit into
mainfrom
docs/codify-binding-rule
Open

docs: codify the binding rule for PROVIDER_ID; refresh stale sections#85
pofallon wants to merge 1 commit into
mainfrom
docs/codify-binding-rule

Conversation

@pofallon

Copy link
Copy Markdown
Contributor

Groundwork for the zai-anthropic adapter — writes down the rule that says it deserves its own ID rather than being a config flag on claude.

The rule

An ID identifies a (wire protocol, endpoint, auth mechanism, feature surface) binding — not a vendor, not a framework.

The reserved-ID list was already evidence for this, but the reasoning was never stated. Every reserved pair splits one vendor across two IDs (anthropic/claude, moonshot/kimi, bedrock/bedrock-agents), and openrouter / opencode-zen / opencode-go sharing OpenAICompatibleRuntime rules out the framework reading. Neither axis fits; the binding does.

Also documents the two mechanisms that break if an ID straddles bindings — extras-gated list_providers, and SUPPORTED_FEATURES as a single honest capability manifest — plus a concrete test for whether something warrants a new ID, and the naming corollary that produced kimi rather than moonshot.

Adds the credential-scoping invariant from #84 as a general obligation on any adapter with an overridable base URL, so the next one doesn't have to rediscover it.

Stale content refreshed

Checked against the code rather than edited by eye:

Claim Reality
Kimi is a shipped adapter Removed (kimi-cli pinned transitive mcp<1.17); now listed as reserved with the reason
examples/probe_kimi.py Went with the adapter; probe list corrected
"five methods" Ten public members (session, count_tokens, supported_native_tools since)
"current release (v0.3.0)" 0.9.1
ProviderOptions are "empty scaffolding" ClaudeOptions has three fields
"only STRUCTURED_OUTPUT_JSON_SCHEMA returns True" claude implements 22 of 27 features; others 12–15

The last one is replaced with a pointer to probe_supports.py rather than a fresh enumeration, so it can't drift the same way again.

Docs only — no code touched.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UBTr6Q6kTGUMQiwwBHcdMj

The rule for minting a PROVIDER_ID was implicit — recoverable only by
reading the reserved-ID list and inferring why `anthropic` and `claude`
are separate. Written down: an ID identifies a (wire protocol, endpoint,
auth mechanism, feature surface) binding, not a vendor and not a
framework. The reserved list is evidence for this, since every reserved
pair splits one vendor across two IDs; `openrouter` / `opencode-zen` /
`opencode-go` sharing OpenAICompatibleRuntime rules out the framework
reading.

Includes the two mechanisms that break when an ID straddles bindings
(extras-gated discovery, the SUPPORTED_FEATURES manifest), a concrete
test for whether something warrants a new ID, and the naming corollary
that produced `kimi` rather than `moonshot`.

Also records the credential-scoping invariant from the ClaudeCodeRuntime
fix as a general obligation on any adapter with an overridable base URL.

Stale content refreshed against the code:

- Kimi is described as a shipped adapter; it was removed. Now listed as
  a reserved ID with the reason.
- examples/probe_kimi.py went with it; the probe list named it.
- The protocol was described as five methods; it exposes ten public
  members.
- Phasing said v0.3.0 / Phase 0, that ProviderOptions were empty
  scaffolding, and that only STRUCTURED_OUTPUT_JSON_SCHEMA returned
  True. The repo is 0.9.1, ClaudeOptions has three fields, and coverage
  runs 12-22 features depending on binding. Replaced the enumeration
  with a pointer to probe_supports.py so it can't drift the same way.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UBTr6Q6kTGUMQiwwBHcdMj
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant