fix(proxy): fall back to cloud-cache provider catalog when local registry misses#32
Merged
thomas-supervisor merged 1 commit intomainfrom May 5, 2026
Merged
Conversation
…er misses
Closes the gap surfaced by the M2 E2E walkthrough: when a user configured a
provider on thomas-cloud but hadn't run \`thomas providers register <id>\`
locally, the proxy returned "Unknown provider" even though the cloud
snapshot fully described how to reach it. Result: the user had to register
the same provider in two places.
Now the lookup is local-first, cloud-as-fallback:
attempt()
1. getProvider(id) ← builtins + ~/.thomas/providers.json (existing)
2. loadProviderFromCloudCache(id) ← reads cloud-cache.providers (new)
3. neither → 503 unknown_provider
Privacy boundary unchanged: this is metadata only (originBaseUrl, protocol).
**Credentials NEVER come from cloud** — they always live in
~/.thomas/credentials.json. If the user binds an agent to a cloud provider
without a local key, they still get 503 "no credentials for X" — but with
a clear remediation pointing at \`thomas providers add <id> <key>\` and
noting the provider came from cloud (not the legacy "unknown provider"
message that was effectively a dead end).
Local-first ordering means an explicit \`thomas providers register\` still
wins over a cloud snapshot of the same id — the user's machine remains
authoritative for endpoints they care to lock in.
Adds:
src/cloud/providers.ts loadProviderFromCloudCache()
tests/cloud-provider-fallback.test.ts
- cloud-only provider with local key → 200, request goes through
- cloud-only provider without local key → 502, "delivered from cloud"
hint includes \`thomas
providers add\` command
- same id in both stores → local wins (cloud not hit)
266/266 tests pass; build 187 KB.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes the gap surfaced by the M2 E2E walkthrough.
The problem
User flow:
Cause: `attempt()` resolved providers via `getProvider()`, which only consults builtins + `~/.thomas/providers.json`. The cloud cache's `providers[]` was data the proxy never read. So users had to double-register every cloud provider locally to make routing work — defeating the "cloud下发了模型配置给local" goal.
The fix
Local-first, cloud-as-fallback:
```
attempt()
```
`src/cloud/providers.ts` is a pure cache reader: returns a `ProviderSpec` from the snapshot, or `undefined` if the provider isn't there / has unknown protocol / has no `originBaseUrl`.
Privacy boundary unchanged
Credentials NEVER come from cloud. `findCredential()` still reads only `~/.thomas/credentials.json`. If the user binds an agent to a cloud provider without a local key, they still get a 503 — but the message now mentions the provider came from cloud and points at the exact `thomas providers add` command (legacy was just "Unknown provider", a dead end).
Why local-first ordering
Explicit `thomas providers register` should win over a cloud snapshot — the user's machine remains authoritative for any provider they've explicitly locked in. The 3rd test case verifies this.
Tests
`tests/cloud-provider-fallback.test.ts` — 3 fake-server cases:
266 / 266 tests pass, build 187 KB.
End-to-end implication
After this lands, the M2 happy path (which I walked through manually earlier today) would have just worked without the workaround:
```sh
(cloud) configure provider + binding
curl -X POST .../v1/providers ...
curl -X PUT .../v1/agents/bindings/claude-code ...
(local) login + sync + (only) add the credential
thomas cloud login --base-url http://...
thomas cloud sync
thomas providers add xiangxin ← only this remains; no
registerneededgo
claude "..." # routes through proxy → translates anthropic→openai → xiangxinai → translates back
```
🤖 Generated with Claude Code