[BUG] Default api_base is always set to GLM provider

[iambpn]

Quick Summary

Environment & Tools

• PicoClaw Version: 0.1.2-189-g4cc8b90 (git: 4cc8b90)
• Go Version: 1.26.0
• AI Model & Provider: Deepseek and Github Copilot
• Operating System: Ubuntu 24
• Channels: None

📸 Steps to Reproduce

1. Create a config file and add the deepseek model in model list but omit api_base to use the default api_base url.

"model_list": [
    {
      "model_name": "deepseek-chat",
      "model": "deepseek/deepseek-chat",
      "api_key": "......"
    }
}

2. Run this command: picoclaw agent -m "hello"

❌ Actual Behavior

Returns this error:

2026/02/23 15:04:36 [2026-02-23T09:19:36Z] [ERROR] agent: LLM call failed {agent_id=main, iteration=1, error=API request failed:
  Status: 401
  Body:   {"error":{"code":"401","message":"令牌已过期或验证不正确"}}}
Error: LLM call failed after retries: API request failed:
  Status: 401
  Body:   {"error":{"code":"401","message":"令牌已过期或验证不正确"}}

✅ Expected Behavior

Api call should be successful and LLM should respond.

💬 Additional Context

During debugging, I discovered that if the api_base key is not specified in the config file, the system falls back to the default GLM provider’s base URL. This occurs because the default config struct is pre-populated with the full model list. When config.json is parsed, the same struct instance is passed to json.Unmarshal. As a result, only the fields explicitly defined in config.json overwrite the existing values, while any omitted optional fields retain their default values.

To resolve this, the model list should be removed from the default config struct so that omitted fields do not unintentionally inherit preset values.

[PixelTux]

In your config:

{
  "agents": {
    "defaults": {
      "model": "deepseek",  // <-- Is this set to "deepseek" in your config?
      ...
    }
  },
  "model_list": [
    {
      "model_name": "deepseek",
      "model": "deepseek/deepseek-chat",
      "api_key": "......"
    },
    ...
  ]
}

Could you confirm that "model": "deepseek" is explicitly set in agents.defaults.model? This will help clarify the issue.

[iambpn]

Yes, model is set in my config. It is set the same as the model_name from model_list. Which is deepseek-chat in my case.

[PixelTux]

I tested the new model base approach and did not encounter the issue. However, when using Deepseek directly, I received the following error due to insufficient balance on Deepseek ( 0 $ ):

Error: LLM call failed after retries: API request failed:
  Status: 402
  Body: {"error":{"message":"Insufficient Balance","type":"unknown_error","param":null,"code":"invalid_request_error"}}

But, the same models (including Deepseek) worked as expected on OpenRouter.
I used the default settings from the example config file: sipeed/config/config.example.json

This is how I set-up OpenRouter:

"model_list": [
    ...
    {
      "model_name": "openrouter-cust-set",
      "model": "openrouter/deepseek/deepseek-v3.2",
      "api_key": "sk-or-v1-xxxx",
      "api_base": "https://openrouter.ai/api/v1"
    }
  ],

and I use "model": "openrouter-cust-set".

When did you install this, and what method did you use (source, release, Docker, etc.)? Also, have you updated it lately?

[iambpn]

It will work if you add the api_base key to the config file but according to the docs its not necessary to add api_base for deepseek so when omitting api_base property it would fallback to glm providers api_base value instead of deepseek.

[PixelTux]

From my understanding, some providers require explicit configuration while others don’t. The config I shared earlier was just a custom test, as I haven't seen OpenRouter wired up, since this new model-base approach in Picoclaw is fairly recent.

I can’t fully test your case because I don’t have DeepSeek access, but after reading the migration logic, just like you suspect this might be a fallback issue, defaulting to GLM.

Looking at:

picoclaw/pkg/config/migration.go

Lines 356 to 363 in ae74fa3

	} else if userProvider == "" && userModel != "" && !legacyModelNameApplied {
	// Legacy config: no explicit provider field but model is specified
	// Use userModel as ModelName for the FIRST provider so GetModelConfig(model) can find it
	// This maintains backward compatibility with old configs that relied on implicit provider selection
	mc.ModelName = userModel
	mc.Model = buildModelWithProtocol(m.protocol, userModel)
	legacyModelNameApplied = true
	}

It seems that if:

providers.zhipu.api_key is set (defined earlier in migration order),
agents.defaults.model = "deepseek-chat",
and agents.defaults.provider is not explicitly set,

then the first configured provider (Zhipu) may be selected automatically.

This would produce:

ModelName: "deepseek-chat"
Model: "zhipu/deepseek-chat" (which seems incorrect)
Using Zhipu’s API key + endpoint
So maybe the logic assumes “first provider with a key wins,” even if the model belongs to another provider?

Just sharing what I observed.

Good news and bad news is this line:

picoclaw/config/config.example.json

Line 145 in ae74fa3

"_comment": "DEPRECATED: Use model_list instead. This will be removed in a future version",

This issue should be resolved in the next release. The legacy provider-based model configuration is going to be removed, and this problem appears to be related to the temporary coexistence of both the old provider-based approach and the new model-based approach.

For now, if setting api_base works for you, I would recommend continuing to use that until the next version is released.

Alternatively, if you’d like to submit a fix and open a PR, that would be great, just please keep in mind the upcoming changes to the provider based configuration so the solution aligns with the new direction.

[yinwm]

Hi @iambpn, I'm analyzing this bug.

Based on the code analysis, this issue likely occurs when your config file has both the providers section and the model_list section at the same time.

Could you confirm if your config.json looks something like this:

{
  "providers": {
    "zhipu": { "api_key": "..." },
    "deepseek": { "api_key": "..." }
  },
  "model_list": [
    {
      "model_name": "deepseek-chat",
      "api_key": "..."
    }
  ]
}

If so, there might be a conflict between the legacy provider migration logic and the new model_list configuration, causing the wrong API base URL to be used.

[iambpn]

No, my config has model_list only.

This is how my config looks like:

{
  "agents": {
    "defaults": {
      "workspace": "~/.picoclaw/workspace",
      "model": "deepseek-chat",
      "max_tokens": 8192,
      "temperature": 0.7,
      "max_tool_iterations": 20
    }
  },
  "model_list": [
    {
      "model_name": "deepseek-chat",
      "model": "deepseek/deepseek-chat",
      "api_key": "deepseek-api-key"
    },
  ]
}

Based of my findings, I think the issue originated from here:

picoclaw/pkg/config/config.go

Lines 502 to 515 in d20cb36

	cfg := DefaultConfig()
	data, err := os.ReadFile(path)
	if err != nil {
	if os.IsNotExist(err) {
	return cfg, nil
	}
	return nil, err
	}
	if err := json.Unmarshal(data, cfg); err != nil {
	return nil, err
	}

Specifically, at Line no: 512. When logging cfg before, line 512 will output cfg.ModelList something like this:

[]ModelList{
  {
    ModelName: "glm-4.7",
    Model:     "zhipu/glm-4.7",
    APIBase:   "https://open.bigmodel.cn/api/paas/v4",
    APIKey:    "",
  },
  {...},
  {...},
  {...}
}

And after line 512 (which will unmarshal the config.json and load it to cfg variable) logging cfg.ModelList will output something like this:

[]ModelList{
  {
    ModelName: "deepseek-chat",
    Model:     "deepseek/deepseed-chat",
    APIBase:   "https://open.bigmodel.cn/api/paas/v4",
    APIKey:    "deepseek-api-key",
  }
}

Here, what happened is go reused the ModelList list and only override the properties listed in config.json file.

---

Due to APIBase property being already populated from here, later when replacing the empty APIBase to provider specific APIBase it always returns false.

I wanted to send PR myself, but currently I don't have much time to explore the intention behind populating ModelList property in DefaultConfig.

If someone can clarify why ModelList is populated I can send the patch according to that else @yinwm can pick it from here.

[nikolasdehor]

@iambpn's analysis at config.go L502-515 is correct. The root cause is Go's json.Unmarshal behavior with slices: when unmarshaling into a pre-populated slice, it reuses existing elements and only overwrites fields present in the JSON. Since DefaultConfig pre-populates ModelList with entries that have APIBase set (e.g., GLM's bigmodel.cn URL), and the user's config.json omits api_base, the GLM URL survives into the final config.

The minimal fix in pkg/config/config.go is to nil-out ModelList before unmarshaling user config:

// Before json.Unmarshal(data, &cfg):
cfg.ModelList = nil

This ensures only the user's model_list entries are present, with no leftover defaults. Provider-specific api_base resolution (the code that fills empty api_base based on model prefix like 'deepseek/') will then work correctly because the field will genuinely be empty, not pre-filled with a stale value.

@PixelTux's note about the legacy provider-based config being removed is relevant -- but users hitting this today need a fix before that migration lands. The nil-out approach is safe and forward-compatible since it only affects the Unmarshal step.

As @yinwm asked -- this does NOT require both providers and model_list sections. A pure model_list config triggers it because DefaultConfig already has ModelList populated.

[ArchiDevil]

It seems like this bug stops initial bootstrapping of the picoclaw in Docker, making it completely unusable. After doing

docker compose -f docker/docker-compose.yml --profile gateway up

on a freshly downloaded repository I always see:

[+] up 1/1
 ✔ Container picoclaw-gateway Created                                                                               0.1s
Attaching to picoclaw-gateway
picoclaw-gateway  | Error creating provider: no API key configured for model: glm-4.7
picoclaw-gateway exited with code 1 (restarting)

[nikolasdehor]

@ArchiDevil confirms this bug is more severe than initially scoped — it blocks fresh Docker bootstrapping entirely because the default config ships with glm-4.7 as the model, and the GLM api_base leaks into all provider configs via the slice reuse bug.

The root cause (Go json.Unmarshal reusing pre-populated slice elements) means any default model_list entry with a provider-specific api_base will contaminate subsequent entries. The fix is straightforward — clear the defaults slice before unmarshaling, or deep-copy each element.

PR #824 (merged Feb 27, "resolve fallback model alias parsing") may partially address this for the alias path, but the core slice contamination in config.go L502-515 still needs a dedicated fix.