[yetihan]

Why

WorkBuddy enterprise custom models can appear in /v3/config with a full request id such as custom:claude-opus-5-5|claude-opus-5-5, while their detail entry uses the bare id (claude-opus-5-5). liveModels() only joined the two lists by exact id, so the model was omitted or stripped of its metadata.

Fixes #1015.

What changed

• Keep the full custom:<name>|<name> id that WorkBuddy accepts for requests.
• Join agent ids and detail ids by exact id first, then only an exact custom/bare alias. Display names are never used for matching.
• Also handle the inverse shape: a bare cli-agent id whose detail entry carries the full custom id.
• Carry context, output, image, pricing, effort, and default-effort metadata onto the listed custom model.
• Keep custom Claude models on the chat endpoint: the request in workbuddy: enterprise custom: models (gpt-5.6-sol, claude-opus-5-5) are not listed #1015 succeeds there, while the Messages-route matcher intentionally recognizes bare Claude ids.
• Bump WorkBuddy to 0.2.28 and document the model-id contract.

Validation

• HOME=$(mktemp -d) bun test packages/workbuddy/enterprise.test.mjs — 12 pass, 0 fail.
• HOME=$(mktemp -d) bun test packages/workbuddy/ — 334 pass, 0 fail in the non-sandbox run; the sandboxed local run only timed out in reset.test.mjs while binding 127.0.0.1.
• bun scripts/check.mjs packages/workbuddy
• node --check packages/workbuddy/index.mjs
• git diff --check

[yetone]

Thanks for picking this up. I can't merge it as it stands, because it doesn't fix the shape #1015 reports.

The issue's shape: #1015 says the custom: entries are "absent entirely (not merely unexposed)", and the product-config entry it quotes carries the full id with its details inline: {"id": "custom:claude-opus-5-5|claude-opus-5-5", "name": "claude-opus-5-5", "maxInputTokens": 256000, …}. If the cli agent's models named that id, the old code would already list it (as {id, name: id}, just without details). So the id isn't in the agent's list. It is in cfg.models only.

Why WorkBuddy shows them anyway: WorkBuddy's own CLI (AgentManager.computeModels in the bundled cli/dist/codebuddy.js) takes the models the agent names, then appends every model in the config whose id starts with custom: (and those tagged custom or chat). The plugin never does that append.

What this PR does: it joins an agent-listed id to a detail entry under the other spelling (custom:x|x against bare x). Neither spelling is in #1015, and the fixture's bare detail ids and display names ("Claude Opus 5.5", "GPT-5.6 Sol") aren't in the issue either. I ran a test built from the issue's literal JSON against d2e21b7 on a Mac mini. liveModels returns neither model there (expected 2, received 0), on workbuddy and on workbuddy-ai.

I'm shipping the fix as 0.2.28: append the config's custom: models after the cli agent's own, as WorkBuddy's CLI does, with their details and their id as given. I'll close this PR once it's on npm. If you have a real /v3/config where the alias shape occurs, please open an issue with the redacted bytes, and the alias join can go on top of the new code.

[yetihan]

Thanks for the detailed review and the literal fixture check. I reproduced the same result: config-only custom: entries were still absent, so the alias join only covered a different shape and does not fix #1015 as reported.

Appending WorkBuddy CLI's config-only custom: models is the right fix. I'll keep this PR open only until 0.2.28 reaches npm, then close it so the alias case can be handled separately with a real redacted config if it occurs.