[bug] provider selection priority #103
Description
The situation is this:
We have three providers.
#1 and #2 - two providers are listed as belonging to group Let's say this is the Droid group, which includes the Anthropic and Open protocols.
#3 - one provider is a classic Anthropic provider and does not belong to any group.
We create an API key without specifying a group. This means it's universal for all platforms. Therefore, it's logical that this applies to all free providers, meaning those who are NOT ADDED to any group. This means provider #3. This is what we need.
But unfortunately, in reality, things don't work that way. This token will ask Droid provider #2, which already belongs to the Droid group, for example, the Anthropic protocol (if we use Claude Code), and with Anthropic provider #3! The token doesn't take into account that suppliers are in different groups, it doesn't care, it only takes into account the protocol!
And only if you hardcode the token's group to match the provider's group will it access only that provider.
token (group claude) --> provider (group claude).
Let me explain why this is bad.
In our version, the claude code won't work with the Droid API using the Sonnet 4.5 model. A priori. But it will try to connect to this provider, disabling it because it gets an error. But the provider isn't dead; it's alive and working, just for Droid clients.
It turns out that we don't have a universal key for several providers; we need to hard-code the token for each narrow group or even one provider. This leads to a large number of keys even for one user.
In our case, we must create separate groups for each cli client (for one user) and generate many identical providers if we have many users