Registering a custom model provider from the Admin UI fails with Could not save this provider. Every custom-provider route returns 404 — GET /v1/admin/custom-providers, PUT .../:provider, DELETE .../:provider.
The cause is not configuration. src/wiring.ts builds the store and returns it, ServerDeps in src/api/deps.ts declares customProviders?: CustomProviderStore, and the routes require ctx.deps.customProviders. But src/index.ts never passes it to createServer — it forwards modelCredentials: built.modelCredentials and stops there. Because the field is optional, omitting it typechecks, so ctx.deps.customProviders is undefined at runtime and putCustomProvider's first guard returns 404 {"error":"not_found"}.
Observed on a self-built image from main:
[admin] PUT /v1/admin/custom-providers/<slug> 404 27ms
refreshCustomProviders is missing the same way, so even a successful upsert would not re-hydrate the registry.
Why tests do not catch it: test/custom-provider-route.test.ts builds its own server and passes customProviders: built.customProviders and refreshCustomProviders: built.refreshCustomProviders explicitly. The test knows the correct wiring; only the production entrypoint does not. So the suite stays green while the feature is dead for every deployment.
The fix is two lines in src/index.ts next to modelCredentials:
customProviders: built.customProviders,
refreshCustomProviders: built.refreshCustomProviders,
We are running that locally and can confirm it makes the routes reachable. A regression test that asserts the entrypoint forwards them is worth having too, since the optional field means the next omission will also typecheck — we added one to test/custom-provider-route.test.ts and verified it fails when the fix is reverted.
Happy to send the patch if useful, though CONTRIBUTING suggests issues for bugs, so filing it here.
https://claude.ai/code/session_01AnKuftwBchrSLpfQkzBHUE
Registering a custom model provider from the Admin UI fails with
Could not save this provider.Every custom-provider route returns 404 —GET /v1/admin/custom-providers,PUT .../:provider,DELETE .../:provider.The cause is not configuration.
src/wiring.tsbuilds the store and returns it,ServerDepsinsrc/api/deps.tsdeclarescustomProviders?: CustomProviderStore, and the routes requirectx.deps.customProviders. Butsrc/index.tsnever passes it tocreateServer— it forwardsmodelCredentials: built.modelCredentialsand stops there. Because the field is optional, omitting it typechecks, soctx.deps.customProvidersisundefinedat runtime andputCustomProvider's first guard returns404 {"error":"not_found"}.Observed on a self-built image from
main:refreshCustomProvidersis missing the same way, so even a successful upsert would not re-hydrate the registry.Why tests do not catch it:
test/custom-provider-route.test.tsbuilds its own server and passescustomProviders: built.customProvidersandrefreshCustomProviders: built.refreshCustomProvidersexplicitly. The test knows the correct wiring; only the production entrypoint does not. So the suite stays green while the feature is dead for every deployment.The fix is two lines in
src/index.tsnext tomodelCredentials:We are running that locally and can confirm it makes the routes reachable. A regression test that asserts the entrypoint forwards them is worth having too, since the optional field means the next omission will also typecheck — we added one to
test/custom-provider-route.test.tsand verified it fails when the fix is reverted.Happy to send the patch if useful, though CONTRIBUTING suggests issues for bugs, so filing it here.
https://claude.ai/code/session_01AnKuftwBchrSLpfQkzBHUE