Add profile-based LLM routing and tighten manager-worker dispatch tracking

[xxx7xxxx]

This PR introduces profile-based LLM routing for agents and tightens the manager-worker dispatch workflow.

• Add named LLM profiles, agent profile selection, and a bot-scoped OpenAI-compatible bridge so boxes use server-resolved model settings instead of direct upstream config.
• Improve manager runtime setup by seeding the dispatch skill/workspace, mounting generated PicoClaw config, and steering manager behavior toward the worker-dispatch fast path.
• Strengthen manager_worker_api.py tracking so task handoff stays sequential and depends on both todo.json progress and in-room worker replies.
• Update CLI, API, docs, UI output, and tests to match the new routing and dispatch flow.

Since the config has been enhanced, my local config looks like this. And I use https://github.com/router-for-me/CLIProxyAPI to leverage local codex as an API proxy.

# Generated by csgclaw onboard.

[server]
listen_addr = "0.0.0.0:18080"
advertise_base_url = ""
access_token = "your_access_token"

[llm]
default_profile = "codex-main"

[bootstrap]
manager_image = "ghcr.io/russellluo/picoclaw:2026.4.8.1"

[llm.profiles.codex-main]
provider = "llm-api"
base_url = "http://127.0.0.1:8317/v1"
api_key = "local"
model_id = "gpt-5.4"
reasoning_effort = "medium"

[llm.profiles.infini-glm5]
provider = "llm-api"
base_url = "https://cloud.infini-ai.com/maas/v1"
api_key = "sk-xxxx"
model_id = "glm-5"
reasoning_effort = ""

[RussellLuo]

Review suggestion 1

Recommended configuration structure:

• Rename llm to models
• Rename profile(s) to provider(s)
• Allow multiple models under each provider
• Let default point to "<provider>.<model>"
• Is reasoning_effort required? If not, suggest adding it later instead of now

# Generated by csgclaw onboard.

[server]
listen_addr = "0.0.0.0:18080"
advertise_base_url = ""
access_token = "your_access_token"

[bootstrap]
manager_image = "ghcr.io/russellluo/picoclaw:2026.4.8.1"

[models]
default = "codex:gpt-5.4"

[models.providers.codex]
models = ["gpt-5.4"]
provider = "llm-api"
base_url = "http://127.0.0.1:8317/v1"
api_key = "local"

[models.providers.infini]
models = ["glm-5"]
base_url = "https://cloud.infini-ai.com/maas/v1"
api_key = "sk-xxxx"

References:

• https://docs.langchain.com/oss/python/deepagents/cli/configuration#config-file
• https://docs.openclaw.ai/concepts/model-providers#openai-code-codex

Review suggestion 2

csgclaw onboard --profile default --default-profile default --base-url <url> --api-key <key> --model-id <model> [--reasoning-effort <effort>]

TODO: need to discuss this part further. My understanding of onboard is somewhat different.

Review suggestion 3

Packaging "workspace/config/skills" for PicoClaw directly in CSGClaw will introduce significant complexity. In addition, we may support other xxClaw variants in the future, which would further increase the complexity.

For now, I will build an image using your latest skill.

TODO: need to discuss the follow-up optimization strategy together.

Review suggestion 4

Consider removing comments like the following:

// step 2.0 Parse global flags first, then dispatch the remaining args as one concrete command branch.

They are too detailed and numerous for inline comments. When needed, we can rely on AI to interpret them instead.

[xxx7xxxx]

Suggestion 1

reasoning_effort is required for the OpenAI API since medium or below makes debugging time quicker. So I keep it with optional.

[server]
listen_addr = "0.0.0.0:18080"
advertise_base_url = ""
access_token = "your_access_token"

[bootstrap]
manager_image = "ghcr.io/russellluo/picoclaw:2026.4.8.1"

[models]
default = "codex.gpt-5.4"

[models.providers.codex]
base_url = "http://127.0.0.1:8317/v1"
api_key = "local"
models = ["gpt-5.4"]
reasoning_effort = "medium"

Review suggestion 2

Somehow I got your point (maybe). Just simplified it to :

csgclaw onboard --base-url <url> --api-key <key> --models <model[,model...]> [--reasoning-effort <effort>]

BTW, I think we can make the initialization steps (with interactions to ask users to type) to onboard in the main csgclaw if no config file is found. Is that a good idea to improve UX?

Review suggestion 3

Not get it, I need more context. But I strongly agree that we should be claw-insensitive.

Review suggestion 4

My bad, comments eliminated.

[RussellLuo]

Who's this API meant for?

[xxx7xxxx]

It is meant for the bot runtime inside the box, mainly PicoClaw manager/worker processes.

More precisely: it is CSGClaw’s internal OpenAI-compatible LLM bridge, so a bot can call a stable /v1/chat/completions endpoint while the server resolves the bot’s actual profile, model_id, and upstream credentials on its behalf.

We don't package workspace/skills/config for now, but we did the LLM bridge for:

• exists to decouple the box runtime from real upstream model configuration.
• give PicoClaw inside the box one stable OpenAI-compatible endpoint
• let CSGClaw resolve the bot’s actual profile, model_id, and defaults on the server side
• prevent exposing real upstream base_url and api_key inside the container
• make per-agent model routing possible without changing PicoClaw (in next change, I want to introduce that every role/agent could have a different model)