mosaicstack/stack
25
0 Fork 1
Code Issues 402 Pull Requests 13 Packages Projects Releases 15 Wiki Activity

Model providers as plugin modules: Routing offers what the model proxy has configured #1858

New Issue
Open
opened 2026-11-07 00:01:29 +00:00 by jason.woltje · 0 comments
jason.woltje commented 2026-11-07 00:01:29 +00:00
Owner
Copy link
Copy source

Jason, 2026-11-07, uidev feedback:

the model providers that are configured in the model proxy settings should be available for assignment to the agents in the settings page. We started with z.ai, claude, and codex, but more will be offered soon. Hand-coding them in the app is the wrong way to do this. They must be linked properly. Consider everything a plugin/module that gets configured and included in the system.

Today (ui-dev at ad9b2dee4)

  • Routing offers only the keys of the business file's hand-written launch.models table (uidev: opus, sonnet, haiku, all anthropic). Accounts added on Settings > Model proxy (z.ai, Codex) never reach Routing.
  • Provider and route names are hard-coded in five places:
    • packages/business/src/launch.mjs:22 and packages/harness/src/bundle.mjs:80: route must be anthropic, glm or codex;
    • packages/bus/src/proxy-page.mjs:41 and :87: account providers claude or codex, everything else other;
    • packages/model-proxy/src/client.mjs:106: client providers claude or codex.
  • A plugin kind registry already exists (packages/plugins/src/kinds.mjs: usage-source, limit-check, search-source, channel, harness). Model providers are not a kind.

What is wanted

  • A model provider is a module configured into the instance, not a list in core. The model proxy (CLIProxyAPI) is one source of providers; others can follow.
  • The set of providers and models Routing offers comes from what is configured and signed in, read at run time, with no code change to add one.
  • Each module declares which harnesses can drive its models (claude-code, pi, others), so Routing only offers a harness and model pair that can run.
  • Memory (#1856) uses the same plugin mechanism; design them together so there is one way to add a module.

Design questions (answer before build)

  1. Kind shape: a model-provider kind in kinds.mjs, its exports (catalogue, preflight, route for a model) and interface version.
  2. Catalogue source for the proxy module: CLIProxyAPI's model list through the existing management client, cached, with the account state from Settings > Model proxy.
  3. How a route names a model: provider module + model id instead of a launch.models key, or keys generated from the catalogue. Migration of existing business files and the kept-instance and creative-instance human-only rules (launch-settings.mjs).
  4. Harness compatibility: which harness drives which provider through the proxy (claude-code via the Anthropic route; pi; a codex harness?), and how a module declares it.
  5. What happens to a route when its provider is signed out or removed: refuse at launch with a named code, and show it on Routing.
  6. Removing the five hard-coded lists without widening anything the role contracts or human-only rules restrict.

Acceptance (first slice)

  • Design doc answering the six questions, reviewed once, summary approved by Jason (it changes the business-file schema).
  • On uidev: Routing lists the models of every provider configured in the proxy (today z.ai, Claude, Codex); one short run on each goes through the proxy; adding or removing a proxy account changes the list with no code change.
  • No provider name hard-coded in core outside the module that owns it.

Filed by the Lead.

Jason, 2026-11-07, uidev feedback: > the model providers that are configured in the model proxy settings should be available for assignment to the agents in the settings page. We started with z.ai, claude, and codex, but more will be offered soon. Hand-coding them in the app is the wrong way to do this. They must be linked properly. Consider everything a plugin/module that gets configured and included in the system. ## Today (ui-dev at ad9b2dee4) - Routing offers only the keys of the business file's hand-written `launch.models` table (uidev: opus, sonnet, haiku, all `anthropic`). Accounts added on Settings > Model proxy (z.ai, Codex) never reach Routing. - Provider and route names are hard-coded in five places: - `packages/business/src/launch.mjs:22` and `packages/harness/src/bundle.mjs:80`: route must be anthropic, glm or codex; - `packages/bus/src/proxy-page.mjs:41` and `:87`: account providers claude or codex, everything else `other`; - `packages/model-proxy/src/client.mjs:106`: client providers claude or codex. - A plugin kind registry already exists (`packages/plugins/src/kinds.mjs`: usage-source, limit-check, search-source, channel, harness). Model providers are not a kind. ## What is wanted - A model provider is a module configured into the instance, not a list in core. The model proxy (CLIProxyAPI) is one source of providers; others can follow. - The set of providers and models Routing offers comes from what is configured and signed in, read at run time, with no code change to add one. - Each module declares which harnesses can drive its models (claude-code, pi, others), so Routing only offers a harness and model pair that can run. - Memory (#1856) uses the same plugin mechanism; design them together so there is one way to add a module. ## Design questions (answer before build) 1. Kind shape: a `model-provider` kind in kinds.mjs, its exports (catalogue, preflight, route for a model) and interface version. 2. Catalogue source for the proxy module: CLIProxyAPI's model list through the existing management client, cached, with the account state from Settings > Model proxy. 3. How a route names a model: provider module + model id instead of a `launch.models` key, or keys generated from the catalogue. Migration of existing business files and the kept-instance and creative-instance human-only rules (`launch-settings.mjs`). 4. Harness compatibility: which harness drives which provider through the proxy (claude-code via the Anthropic route; pi; a codex harness?), and how a module declares it. 5. What happens to a route when its provider is signed out or removed: refuse at launch with a named code, and show it on Routing. 6. Removing the five hard-coded lists without widening anything the role contracts or human-only rules restrict. ## Acceptance (first slice) - Design doc answering the six questions, reviewed once, summary approved by Jason (it changes the business-file schema). - On uidev: Routing lists the models of every provider configured in the proxy (today z.ai, Claude, Codex); one short run on each goes through the proxy; adding or removing a proxy account changes the list with no code change. - No provider name hard-coded in core outside the module that owns it. Filed by the Lead.
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
bug
Defect in framework tooling or delivered code
 fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
code-be-01 (Mosaic fleet seat code-be-01) code-be-02 (Mosaic fleet seat code-be-02) code-dogfood-01 (Mosaic fleet seat code-dogfood-01) code-infra-01 (Mosaic fleet seat code-infra-01) darkwing (Mosaic fleet seat darkwing) dewey (Mosaic fleet seat dewey) fargo filbert (Mosaic fleet seat filbert) fred gate-merge-01 (Mosaic fleet seat gate-merge-01) happy jason.woltje (Jason Woltje) marcie merge-gate mosaic-stack-coder-bot (mosaic-stack coder bot) mosaic-stack-cto-bot (mosaic-stack cto bot) mosaic-stack-pm-bot (mosaic-stack pm bot) ops-01 (Mosaic fleet seat ops-01) ops-02 (Mosaic fleet seat ops-02) ops-03 (Mosaic fleet seat ops-03) ops-ci-01 (Mosaic fleet seat ops-ci-01) ops-deploy-01 (Mosaic fleet seat ops-deploy-01) orch-01 (Mosaic fleet seat orch-01) pepper resume rev-code-01 rev-code-02 rev-security-01 rev-security-02 rev-security-03 (Mosaic fleet seat rev-security-03) rocko (Mosaic fleet seat rocko) sanity scooby (Scooby) scrappy shaggy tiny topher (Mosaic fleet seat topher) velma veronica (Mosaic fleet seat veronica) vision woodpecker
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#1858