Repository navigation
audit follow-up: fleet model-family detection in shared protocols/openai-chat.ts alters official providers — relocate to gateway-door compatibility config #1824
Description
Audit follow-up — fleet edits inside the shared protocol of official providers
Source: 2026-11-06 provider audit (Audit A: official provider files). Every official provider file is clean — no fleet-authored changes in providers/openai.ts, mistral.ts, deepseek.ts, groq.ts, openrouter.ts, meta.ts, openai-compatible.ts. The one material breach of the "don't edit official providers" doctrine is one layer down, in the shared protocol those providers lower through.
The finding: packages/ai/src/protocols/openai-chat.ts
Two fleet commits change wire behavior for every consumer of the OpenAI Chat protocol — official openai, deepseek, groq, openrouter, meta (chat), and the fork openai-compatible (which effectively serves the opendesign / cline-pass / opencode-go.* doors after the native-rewrite layer):
46c691ef5f(2026-11-05, Multi-family gateways (cline-pass, opendesign, opencode-go) get zero per-family tool adaptation #1706) — addsdetectModelFamily()(glm/kimi/gemini by model-ID segment), threadsmodelIDintodetectMaxTokensField/detectSupportsStore/detectSupportsStrictMode/detectZaiToolStream.94ec4190e4(2026-11-05, fix(ai): DeepSeek models behind multi-family gateways get max_completion_tokens and a store flag — #1731 family classifier omits deepseek #1737) — extends it with adeepseekfamily (max_tokens, nostore).
Stated motivation is the fleet's multi-family gateway doors. But the detection also fires on direct official-provider traffic with matching model ids, and it will conflict on every upstream sync.
Fix shape
The protocol already honors explicit per-model compatibility overrides after detection ("Explicit compatibility overrides are applied after detection and always win" — the commit's own comment). Move the gateway family defaults to where they belong:
- per-model
compatibilityentries on the gateway doors (cline-pass,opendesign,opencode-gocatalog entries inopencode.jsonc/ models.dev overlay), or - a fleet-owned wrapper around the compatible provider for those doors.
Then revert the detection commits' behavior changes from the shared protocol (keeping any purely additive, behavior-neutral helpers if upstream-shaped).
Secondary shared-file fleet edits (lower severity — same principle, tracked here)
protocols/open-responses.ts—f64bbc14a7(fix(ai): open-responses item-ID prefix reads through the prototype chain — an item typed "constructor" mints an ID containing the Object function source #908/fix(ai): read open-responses item-ID prefixes by own property (#908) #910): own-property guard on item-ID prefixes.protocols/utils/responses-hosted-tools.ts—c523a00fe7(fix(ai): ResponsesHostedTools.isItem reads through the prototype chain — an output item typed "constructor" kills the Responses stream with a TypeError defect #927/fix(ai): guard ResponsesHostedTools against prototype-named item types (#927) #928): prototype-name guard.protocols/anthropic-messages.ts+route/client.ts+route/transport/http.ts+schema/options.ts—715c29a069(Design: generic OpenAI façades on the server — /v1/chat/completions + /v1/responses, one translation layer, proxy doors retire #1146) native-shape pass-through fast path;5315572131(fix(ai): Anthropic server-tool-result gate reads through the prototype chain — a block typed "constructor" kills the whole stream #856) in anthropic-messages. (Serves the fleetclaude-codeprovider; officialanthropicis not fleet-used.)protocols/utils/tool-schema.ts—bd60fed2b8(fix(ai): moonshot tool-schema projection dropsprefixItemswhenitemsis also present — position constraints are silently replaced #1574);protocols/utils/gemini-json-schema.ts—42b9794461(fix(ai): Gemini schema normalize only cuts single-def $ref loops — mutually recursive $defs through required properties reach Gemini uncut #1585). Shared schema utils, motivated by antigravity/moonshot.- Verified clean by contrast:
protocols/mistral-chat.ts.
These guards are close to behavior-preserving, but they are still fleet edits in upstream files and will surface as sync conflicts; each should either move to a fleet-owned location or be proposed upstream.
Acceptance criteria
- Fleet model-family detection no longer lives in the shared
packages/ai/src/protocols/openai-chat.tsprotocol layer, OR a written decision on this issue records why the protocol layer is the accepted home. - Official providers' wire behavior is unchanged for non-fleet model IDs (existing protocol tests pass; any behavior delta is enumerated on this issue).
- The gateway-door compatibility configuration carries the family detection for the fleet doors that need it (opendesign / cline-pass / opencode-go).
Activity
dezren39 commentedon Nov 6, 2026
🤖 Triage evidence · issue-sweep-rotating (Make feeder)
22c0a6ddbee19878e8e51bde432e995f75ccdd2a(verified x2 viagh api), readingpackages/ai/src/protocols/openai-chat.tsraw viagh apicontents.openai-chat.ts:698—detectModelFamily(modelID)(glm/kimi/gemini/deepseek families by model-ID segment)openai-chat.ts:714-719—detectMaxTokensFieldthreadsmodelIDinto family detectionopenai-chat.ts:751-756—detectSupportsStorereturnsfalsewhenever a family is detectedopenai-chat.ts:803/:824— kimi strict-mode and glm tool-stream behavior keyed off the detected familyopenai-chat.ts:871-873— detection results are consumed at request build; explicitcompatibilityoverrides are applied after detection, so plain official-provider traffic (openai, deepseek, groq, openrouter, meta) with a matching model id still gets fleet gateway behavior with no explicit config.compatibilityentries forcline-pass/opendesign/opencode-gocatalog entries, or a fleet-owned wrapper around the compatible provider); the shared protocol's detection-driven behavior changes are reverted (behavior-neutral additive helpers may stay if upstream-shaped); a test pins that an official provider with a glm/kimi/deepseek-shaped model id and no explicitcompatibilitygets upstream-default wire fields.repo-task/v1triage packet intorepo-health-opencode-pilotfrom this feeder run; the queue lane owns the fix work.dezren39 commentedon Nov 6, 2026
🤖 Agent note · queued by triage feeder
repo-task/v1triage packet as task 10988 in queuerepo-health-opencode-pilot(kindtriage, priority 50, deduperepo-health:v1:triage:developing-today/opencode:issue:1824). Packet:hidden_files/packet-opencode-1824.json.22c0a6ddbee1(verified x2):detectModelFamilyatprotocols/openai-chat.ts:698, threaded at:714-719/:751-756, consumed at:871-873with compatibility overrides applied only after detection.dezren39 commentedon Nov 6, 2026
Intake review
detectModelFamilyconsumers to it family by family, and keep the protocol layer's defaults upstream-shaped.🤖 Fleet monitor intake (repo-fleet-monitor), 2026-11-06.
dezren39 commentedon Nov 6, 2026
Triage complete — queue task 10988 (lane
opencode-a), all reads fresh on origin/main 22c0a6d.Confirmed: the full detection-driven behavior set in
protocols/openai-chat.tsdetectModelFamily(:698) classifies glm/kimi/gemini/deepseek by anchored id-segment regexes (commits 46c691e #1706, 94ec419 #1737 — both verified). It drives exactly four behaviors, all consumed infromRequestasrequest.model.compatibility?.X ?? detectX(...):detectMaxTokensField— family glm/kimi/deepseek →max_tokens, overriding the provider/baseURL heuristic for any consumer.detectSupportsStore— any detected family →storeunsupported (false), whatever the gateway/provider.detectSupportsStrictMode— kimi → strict mode off.detectZaiToolStream— glm →tool_stream: true(minus the glm-4.5 exclusions), behind any provider.Consumers of the shared protocol include official openai, deepseek, groq, openrouter, meta and many more (azure, cerebras, cohere, deepinfra, fireworks, …), plus the fleet's openai-compatible doors. So family-shaped model ids on official-provider traffic with no explicit compatibility get gateway behavior today — the issue's finding is confirmed as filed. Where the provider heuristic already agrees (direct deepseek/zai/moonshot), detection is redundant and removing it changes nothing.
Relocation decision: per-model
compatibilityon the gateway doorsEvery family effect is expressible through the protocol's own sanctioned channel:
maxTokensField,supportsStore,supportsStrictMode,zaiToolStreamare allcompatibilitykeys, and explicit compatibility already wins over detection at consumption. Decision: relocate to per-model compatibility entries for the door models that relied on detection (the glm/kimi/gemini/deepseek-shaped ids served through the cline-pass / opendesign / opencode-go doors, carried in the fork's catalog/config layer — models.dev overlay / door provider config), then remove the family detection from the shared protocol. A fleet-owned wrapper around the compatible provider was considered and rejected: it duplicates routing for three doors to deliver values the existing compatibility channel already carries, and leaves two behavior paths to keep in sync. The provider/baseURL heuristics in the detect* functions stay — they are upstream-shaped and predate the family commits.Secondary shared-file edits — disposition: propose upstream, keep in place meanwhile
Verified present: f64bbc1 (open-responses own-property guard, #908/#910), c523a00 (responses-hosted-tools prototype guard, #927/#928), 715c29a (anthropic-messages pass-through, #1146), 5315572 (anthropic-messages own-keys gate, #856), bd60fed (tool-schema prefixItems, #1574), 42b9794 (gemini-json-schema $ref cycle cut, #1585). Each is a small, behavior-preserving correctness guard in upstream shape. Moving them into fleet-owned wrappers would duplicate protocol logic for zero behavior gain; the honest disposition is propose upstream (they are exactly the kind of fix upstream takes), keeping them in place until upstream accepts or rejects. They are not part of the fix task below; if Drew wants upstream PRs filed, that is separate work. The #1146 pass-through is the largest of the set and the only one that is a feature rather than a guard — same disposition, noted explicitly.
Fix routed
Fix packet enqueued (repo-health-opencode-pilot): remove family detection from openai-chat.ts + add the door compatibility entries + a pinning test (official provider, family-shaped model id, no explicit compatibility → upstream-default wire fields:
max_completion_tokens,storehonored, strict allowed, notool_stream).3 remaining items
dezren39 commentedon Nov 6, 2026
agent-note:v1 — state: PR #1840 open, task 11000 parked for review. detectModelFamily removed from shared openai-chat protocol; family defaults now explicit per-model compatibility entries on cline-pass/opendesign/opencode-go doors in models-dev.ts (+ schema keys supportsStore/supportsStrictMode/zaiToolStream). Tests on laptop after merging origin/main: ai openai-chat 80 pass, core models 20 pass, ai+core typecheck clean. Resume: disposition Codex findings on #1840, merge if sound.
Merge pull request #1840 from developing-today-forks/queue/11000-1824…
dezren39 commentedon Nov 6, 2026
agent-note:v1 — state: completed via PR #1840 merged 2026-11-06; task 11000 complete. No Codex findings on #1840. Tests re-run on the verified PR head (629bb0b): ai openai-chat 80 pass, core models 20 pass, ai+core typecheck clean.