Visitar URL original
fix: add missing providers to KnownProviders by MaxFreedomPollard · Pull Request #578 · charmbracelet/catwalk · GitHub
Skip to content

fix: add missing providers to KnownProviders - #578

Merged
andreynering merged 1 commit into
charmbracelet:mainfrom
MaxFreedomPollard:fix-known-providers
Sep 9, 2026
Merged

andreynering merged 1 commit into
charmbracelet:mainfrom
MaxFreedomPollard:fix-known-providers

Conversation

@MaxFreedomPollard

Copy link
Copy Markdown
Contributor

catwalk.KnownProviders() returns 35 providers. embedded.GetAll() returns 41. The six it leaves out are deepseek, ionet, alibaba-singapore, alibaba-us, coralbricks and scaleway.

All six are in providerRegistry in internal/providers/providers.go with embedded configs, so the catalog serves them, but the slice returned by KnownProviders() in pkg/catwalk/provider.go:106-144 never picked them up. InferenceProviderDeepSeek, InferenceProviderIoNet, InferenceProviderAlibabaSingapore and InferenceProviderAlibabaUS are declared in the constant block right above it and just not listed. coralbricks and scaleway have no constant at all.

Everywhere else the constant and the KnownProviders entry move together: atlascloud (#463), moonshot (#325), fireworks (#373) and baseten each added both in one commit, and the Lambda (#79) and z.ai coding (#66) removals took both out. These six missed the second half.

This adds InferenceProviderCoralBricks and InferenceProviderScaleway, then puts all six into KnownProviders at the position that mirrors the constant block, so the two lists read in the same order. KnownProviders() now returns 41.

TestKnownProvidersMatchesRegistry in internal/providers/providers_test.go checks both directions, since a stale entry left behind after a provider is dropped is the same class of bug as a missing one.

Verified on macOS arm64 with the go 1.26.6 toolchain from go.mod. The test on the branch with pkg/catwalk/provider.go reverted to main:

$ go test ./internal/providers/ -run TestKnownProvidersMatchesRegistry -v
    providers_test.go:34: Provider "alibaba-singapore" is registered but missing from catwalk.KnownProviders()
    providers_test.go:34: Provider "alibaba-us" is registered but missing from catwalk.KnownProviders()
    providers_test.go:34: Provider "coralbricks" is registered but missing from catwalk.KnownProviders()
    providers_test.go:34: Provider "deepseek" is registered but missing from catwalk.KnownProviders()
    providers_test.go:34: Provider "ionet" is registered but missing from catwalk.KnownProviders()
    providers_test.go:34: Provider "scaleway" is registered but missing from catwalk.KnownProviders()
--- FAIL: TestKnownProvidersMatchesRegistry (0.01s)

And with the fix in place:

$ go test ./...
ok      charm.land/catwalk/internal/providers   0.251s

$ go build ./... && go vet ./...
(clean)

$ golangci-lint run ./...          # v2.13.1, repo .golangci.yml
0 issues.

$ golangci-lint fmt --diff ./...   # gofumpt + goimports
(no diff)

catwalk.KnownProviders() in pkg/catwalk/provider.go returned 35 of the
41 providers that embedded.GetAll() actually ships. deepseek, ionet,
alibaba-singapore, alibaba-us, coralbricks and scaleway are all in
providerRegistry in internal/providers/providers.go with embedded
configs, but none of them was listed, so anything using the public API
to enumerate known providers missed six of them.

The two lists have always been kept in step: atlascloud (charmbracelet#463),
moonshot (charmbracelet#325), fireworks (charmbracelet#373) and baseten each added an
InferenceProvider constant and a KnownProviders entry in one commit,
and the Lambda (charmbracelet#79) and z.ai coding (charmbracelet#66) removals took both away.
These six drifted. ionet (charmbracelet#179), alibaba-singapore (charmbracelet#282), alibaba-us
(charmbracelet#412) and deepseek (charmbracelet#271) added the constant without the entry, and
coralbricks (charmbracelet#502) and scaleway (charmbracelet#309) never got a constant.

Declares InferenceProviderCoralBricks and InferenceProviderScaleway,
and inserts all six into KnownProviders at the position that mirrors
the constant block, so both read in the same order. Adds
TestKnownProvidersMatchesRegistry in internal/providers, which fails
if the registry and KnownProviders disagree in either direction.

@andreynering andreynering left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thank you!

@andreynering
andreynering merged commit 72037fe into charmbracelet:main Sep 9, 2026
5 checks passed
cooldk added a commit to cooldk/catwalk that referenced this pull request Sep 23, 2026
… to KnownProviders

- kunavo.json now lists exactly the chat models Kunavo's GET /v1/models
  returns on 2026-09-23: 13, down from 22. Removed claude-opus-5-fast,
  gpt-5-4, gpt-5-4-mini, gpt-5-3-codex, gpt-5-5-pro, gpt-5-6-luna and the four
  Gemini models. Kunavo has paused each of them: the API answers 404 naming a
  successor. Added gpt-6-astra, with its reasoning_levels copied from
  openai.json.
- default_small_model_id moves from gemini-2-5-flash, now paused, to
  claude-haiku-4-5, the model Kunavo names as its replacement.
- The cache fields follow CRUSH.md: cost_per_1m_in_cached is the cache-write
  price and cost_per_1m_out_cached the cache-read price. The previous revision
  had the read rate in in_cached and 0 in out_cached, which priced every cache
  read at $0. Kunavo publishes both rates for every model
  (https://kunavo.com/pricing): reads at 0.10x input (0.025x on Claude Fable
  5.1), writes at 1.25x input on Claude and GPT-5.6 / GPT-6 Astra, and at the
  input rate on GPT-5.5.
- pkg/catwalk: add InferenceProviderKunavo and its KnownProviders entry, so
  TestKnownProvidersMatchesRegistry (charmbracelet#578) passes with the provider
  registered.

go build ./..., go vet ./... and go test ./... pass, and gofmt is clean.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kingsleydon kingsleydon mentioned this pull request Oct 25, 2026
1 of 2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants