#Using a custom agent behind an OpenAI-compatible endpoint as an OpenClaw "model"
1 messages · Page 1 of 1 (latest)
I’m checking the docs/source so I don’t make up config behavior.
Short answer: yes, the extra sub-sessions are expected with your current design.
Your fake-model setup is a valid workaround, but once the orchestrator uses it as a sub-agent, OpenClaw treats it like any other sub-agent run, and those always get their own session. That is documented behavior, not just UI noise. Native sub-agents are separate sessions; ACP has a “bind here” mode, but native sub-agents do not.
So the clean mental model is:
- Fake OpenAI model + subagent: works, but you inherit subagent session overhead
- Tool/MCP integration: best if you want to call your backend inside the same session
- Agent harness plugin: best if your backend is really a custom runtime, not a model
For your case, I’d recommend tool/MCP, not provider/subagent.
That would look like:
- expose your Python service as one MCP server or one custom plugin tool
- keep your internals opaque
- have it return structured results like:
final_answerneeds_disambiguation+ options- maybe a
state_tokenfor follow-up
- let the main OpenClaw agent ask the clarification question and call the tool again
That keeps the whole exchange in one conversation/session and avoids Control UI clutter.
If you really want your backend to own the turn execution, the native abstraction is an agent harness plugin, not a fake /v1/chat/completions shim. But even then, if you delegate to it as a subagent, you still get a separate session.
If you stay with the current approach, the only real mitigation is to reduce the clutter after the fact:
- use
cleanup: "delete"on spawned subagents - or shorten
agents.defaults.subagents.archiveAfterMinutes
Docs: