[BUG] model_list does not inherit api_key/api_base from providers (even with matching protocol prefix)

[eric2788]

Quick Summary

When defining providers in config (e.g. litellm) and referencing matching protocol prefixes in model_list, ModelConfig does not inherit api_key/api_base unless they are manually specified in every model_list entry. This causes inconvenient errors and is non-DRY.

Environment & Tools

• PicoClaw Version: v0.2.2
• Go Version: N/A (running official binary release)
• Operating System: As per official Dockerfile
• Channels: Discord, Telegram

📸 Steps to Reproduce

1. Add litellm provider to config:

   "providers": {
     "litellm": { "api_key": "123", "api_base": "http://host:4000/v1" }
   }

2. Add model_list entries referencing litellm prefix but without duplicated keys:

   "model_list": [
     { "model_name": "kimi1", "model": "litellm/kimi-1" },
     { "model_name": "kimi2", "model": "litellm/kimi-2" }
   ]

3. Start up the system.

❌ Actual Behavior

Both models fail with:

Error creating provider: api_key or api_base is required for HTTP-based protocol "litellm"

✅ Expected Behavior

If a model_list entry has a protocol prefix matching a defined provider (e.g. litellm/), the ModelConfig should inherit api_key, api_base, proxy, etc., so the user does not need to repeat them.

💬 Additional Context

Current Architecture

• The current config loader only invokes auto-migration from providers to model_list if model_list is completely empty.
• If any entries exist in model_list, the providers block is silently ignored (see pkg/config/config.go LoadConfig & migration.go).
• ModelConfig entries require all credentials to be explicitly set, even for identical protocol prefixes.
• There is no check at runtime or config load to merge/inherit providers.

How to Add Without Breaking Current Behavior

• When loading/parsing model_list, for each entry missing api_key/api_base, check if its protocol prefix matches a configured provider.
• If found, automatically inherit these fields from the matching provider.
• This does not break current config formats, because explicit specification would always override inherited values.
• It is fully backward compatible, and enables DRY config for users with many model variants under one provider.
• If desired, provide an optional flag for strict mode or warnings if inheritance is not possible.

Refactor/Roadmap

Is this addressed by any planned refactor or milestone? If not, could you consider it for a future release?

[HongminHan]

As far as I know, use model_list is enough. Providers will removed in feature?
Keep agents.defaults.provider is "", use agents.defaults.model to link model_list.
"model_list": [
{
"model_name": "<your_model_name>",
"model": "<your_model>",
"api_base": "<your_api_base>",
"api_key": "<your_api_key>"
}
]

[eric2788]

As far as I know, use model_list is enough. Providers will removed in feature? Keep agents.defaults.provider is "", use agents.defaults.model to link model_list. "model_list": [ { "model_name": "<your_model_name>", "model": "<your_model>", "api_base": "<your_api_base>", "api_key": "<your_api_key>" } ]

hmm, so I need to add api_key and api_base every time I add a model? That’s a bit inconvenient. Are there any plans to improve this in a future release?