[robinbowes]

Summary

SDK 1.x (#103) sends anthropic-version: 2026-10-21 to every endpoint, including third-party anthropic_compatible vendors. An anthropic_compatible AI config can now name 2023-06-01 instead. Unset keeps the SDK's version.

 ai_configs
+  api_version text  -- enum ['2023-06-01'], null = SDK default
 chatClientFromRow(row)
   createChatClient({ provider, apiKey, baseUrl,
+    apiVersion: row.apiVersion,
     defaults })
 createAnthropicChatClient
   new Anthropic({ apiKey, baseURL, fetch, maxRetries: 2,
+    defaultHeaders: apiVersion ? { 'anthropic-version': apiVersion } : undefined })

• Contract (shared/ai/config.ts): apiVersion on aiConfigSchema (nullable), on the upsert ('' or omitted clears it, the same as serviceTier), and on the inline connection-test candidate.
• Validation: ProviderInfo.supportsApiVersion is true only for anthropic_compatible. Any other provider gets 400 api_version_unsupported on save and on the connection test.
• UI: Settings → AI shows an API version select (2026-10-21 (SDK default) / 2023-06-01) for compatible vendors. "Set default" re-posts the whole row, so it now carries apiVersion; without that, making a row the default would clear the value.
• Migration 0020_kit-ai-config-api-version.sql: ALTER TABLE "ai_configs" ADD COLUMN "api_version" text.
• Docs: CONCEPTS §9, services/ai/CLAUDE.md, ui/CLAUDE.md, .claude/rules/api.md. Porting note steps 42–48, and verify step 19 rewritten (the "no override in source" check no longer holds).

Evidence

• Before: the four new API tests and two new UI tests fail (expected '2026-10-21' to be '2023-06-01', api_version_unsupported: expected 201 to be 400, Unable to find a label with the text of: API version).
  After: pnpm gate passes.
• The tests run the real SDK against a fake transport. A saved compatible row sends 2023-06-01, and the same row re-saved without the field sends 2026-10-21. An inline compatible candidate is probed on the version it names. anthropic with apiVersion gets 400 on save and on test. An unknown value gets 400 validation_failed.
• Mutation check: removing each of the six wiring sites (resolve, connection-test pass-through and guard, route guard, setDefault, modal body) fails a test.
• Review gate: approved, 0 findings.

Merge Danger

Door: two-way

The column is nullable and every existing row reads as null, so nothing changes until someone sets the field. Rolling back means dropping the column.

Blast Radius: AI settings

• Copies add their own migration (pnpm db:generate) rather than taking the kit's 0020, because their numbering differs. The porting note says so.

🤖 Generated with Claude Code

[robinbowes]

@cliftonc Can you cast your eye over this and #103 and let me know what you think?

[cliftonc]

Thanks for picking this up, the wiring and the mutation-checked tests are thorough.

I looked into whether we need it. Our two anthropic_compatible presets don't seem to: Fireworks' docs say it ignores anthropic-version entirely, and Moonshot's Messages API spec doesn't document the header. So the override wouldn't change anything for either of them today, and it costs a column, a migration and seven porting steps.

Could we close this one for now? If a vendor ever does reject 2026-10-21, a one-line defaultHeaders for anthropic_compatible in createAnthropicChatClient would cover it, and the work here gives us a good starting point.