Skip to content

adr: OpenAI/Anthropic-compatible providers - #116

Open
Zhanghoks wants to merge 3 commits into
yc-software:mainfrom
Zhanghoks:adr/compatible-model-providers
Open

adr: OpenAI/Anthropic-compatible providers#116
Zhanghoks wants to merge 3 commits into
yc-software:mainfrom
Zhanghoks:adr/compatible-model-providers

Conversation

@Zhanghoks

@Zhanghoks Zhanghoks commented Aug 2, 2026

Copy link
Copy Markdown

Details in adrs/compatible-model-providers.md.

Text-only. Admin-configured OpenAI/Anthropic-compatible endpoints + presets; reuse the existing web-ui model picker. Happy to help test real endpoints if the direction lands.


细节见 adrs/compatible-model-providers.md

仅文本,无代码。希望支持管理员配置 OpenAI/Anthropic 兼容端点与预设,并沿用现有 web-ui 模型切换。若方向认可,我可以协助用真实兼容端点做测试。


View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.

Informal proposal per CONTRIBUTING: admin-configured compatible endpoints
and presets, using the existing web-ui model picker.
Drop the formal CONTRIBUTING line; keep admin-only compatible endpoints,
presets, and existing web-ui picker.

@rajpratham1 rajpratham1 left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This ADR proposes supporting OpenAI-compatible and Anthropic-compatible providers instead of continuing to add individual provider integrations. The proposal is scoped as a design discussion rather than an implementation and presents a clear motivation, especially for deployments where Anthropic or OpenAI endpoints are unavailable or organizations already operate compatible gateways.

@16francej 16francej added adr Text proposal in adrs/ per CONTRIBUTING adr-looks-human ADR reads as human-written per guidelines enhancement New feature or request connector Proposes a new connector/surface/provider labels Aug 4, 2026
pull Bot pushed a commit to danielabelski/qm that referenced this pull request Aug 4, 2026
…tered providers

Two layers of custom model endpoints:

1. ANTHROPIC_BASE_URL / OPENAI_BASE_URL / OPENROUTER_BASE_URL are parsed
   and validated once in config (bad URLs fail at boot), resolved through
   one provider-endpoints module, and applied uniformly: the pi harness,
   the claude/codex child harness process envs, and admin key validation
   (a gateway-issued key validates against the configured endpoint).

2. An org admin can register additional providers that speak the OpenAI
   or Anthropic wire protocol — base URL, API key, and the model ids to
   expose — via PUT /v1/admin/custom-providers/:slug. Registered models
   resolve through the same choke point as built-ins, surface in the
   catalog and model pickers, and serve on the pi and opencode harnesses.
   Keys validate against the registered endpoint (skippable for gateways
   without a models listing), live in the same encrypted store as the
   built-in provider keys, and are write-only. Built-in model ids and
   provider slugs are reserved. The admin portal gets a Custom providers
   card. DeepSeek / Kimi / xAI / a corporate gateway become request
   bodies, not code.

QA hardening: custom keys reach the model runtime for every provider,
models.json materialization is cached per registry version, a corrupt
custom key degrades only its provider, slashed custom ids win the
opencode modelRef lookup, model/name input caps, double-delete 404s,
and the picker refreshes when registrations change.

Addresses the custom-endpoint asks in yc-software#110, yc-software#60, yc-software#116, yc-software#104.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

adr Text proposal in adrs/ per CONTRIBUTING adr-looks-human ADR reads as human-written per guidelines connector Proposes a new connector/surface/provider enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants