Custom engine slot: connect non Claude/Codex models (Chinese LLMs, local, OpenAI-compatible)

[zo-sol]

Summary

AgentNet runs a full PC class userland everywhere, including mobile (the Android shell runs a proot Ubuntu rootfs). So the runtime can host any CLI based or API based agent, not just Claude and Codex. We cannot hand add every provider one by one. This issue is to research and design a single Custom engine slot (Claude | Codex | Custom) that lets a user connect a different AI, with a focus on models that are otherwise unavailable through the two built in engines (for example the Chinese LLMs: DeepSeek, Qwen, Zhipu GLM, Moonshot Kimi, plus local models and OpenAI compatible gateways).

This is a research and design issue, not a committed implementation. The deliverable is a short design note plus a spike on the cheapest path below.

Why this is feasible here

• The engine is spawned inside a real Linux environment, so any agent CLI or local server can run next to Claude and Codex.
• The on chain and skill layer is engine agnostic: skills are prompts plus MCP, and the wallet, feed, and market do not care which model produced a turn. A custom model should inherit skills and MCP with little to no change.

Current state (grounding)

• The engine identity is hardcoded as "claude" | "codex" across core: packages/core/src/core/types.ts (modelType), packages/core/src/memory/index.ts (type Cli), and the webview engine picker rejects anything else (next !== 'claude' && next !== 'codex'). Per engine maps exist for mode, model, and effort.
• There is no base URL or LLM provider plumbing today. The only provider code paths are OAuth token files and wallet or DAS providers, none of which is an LLM endpoint.
• A third engine is already in motion: Claudex — a third engine: Claude leads a team of parallel Codex workers #90 (Claudex, Claude leading parallel Codex workers). So the engine set is not frozen at two, and the picker and abstraction need to generalize regardless.

Net: adding a Custom engine is mostly a matter of (a) generalizing the "claude" | "codex" union into an engine registry, and (b) picking how a Custom engine reaches a non built in model.

Constraints to keep in mind

• AgentNet engines are AGENTIC (tool use, file edits, shell, MCP), not plain chat. A custom backend is only useful if it supports tool or function calling. Models without it should be gated or clearly marked chat only.
• Auth differs per engine (Claude OAuth, Codex device auth). A Custom engine is config based: base URL, API key, model name. Reuse the per device tokens/<provider>.json pattern (local only, never synced) for the key.
• Data egress: a custom endpoint sends code and context to a third party server. This matters for the Chinese LLM and hosted gateway cases and needs a clear user facing note.

Approaches to research (ranked by effort)

1. Codex provider passthrough (cheapest). Codex already ships in AgentNet and supports OpenAI compatible custom model providers (a base URL plus an API key plus a model name). A Custom engine could be Codex pointed at a non OpenAI backend. This instantly reaches the OpenAI compatible endpoints that DeepSeek, Qwen (DashScope), Zhipu GLM, Moonshot Kimi, Mistral, and OpenRouter expose, as well as local Ollama and LM Studio. Work: surface base URL / key / model config plus a small preset list, and route the Custom engine through the existing Codex spawn.
2. Claude Code via a translating proxy. Claude Code honors ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN. With a translation proxy (for example LiteLLM or a claude code router) it can drive non Anthropic models. Custom = Claude Code plus a proxy config. Heavier setup, but keeps the Claude tool loop.
3. ACP (Agent Client Protocol). A Custom engine that speaks ACP can plug any ACP compatible agent. This lines up with the eliza subagent ACP idea and the direction in Claudex — a third engine: Claude leads a team of parallel Codex workers #90. Most general, but requires the backend to speak ACP.
4. Generic command engine (bring your own CLI). Let the user point at an arbitrary command that speaks AgentNet's engine transport over stdin and stdout. A power user escape hatch that covers anything the presets miss.

Proposed direction to prototype

Start with approach 1 behind a Custom slot: generalize the engine union into a registry, add a Custom engine whose config is base URL plus key plus model, and ship a short preset list (DeepSeek, Qwen, Zhipu GLM, Moonshot Kimi, local Ollama or LM Studio, OpenRouter, plus a fully manual entry). Keep the registry generic so approaches 2, 3, and 4 can slot in later without another rewrite.

Open questions to settle in the design note

• Do we hard require tool or function calling, and how do we detect or gate models that lack it?
• Config storage and UI: reuse tokens/<provider>.json for the key; how does the engine picker present Claude | Codex | Custom plus the Custom sub config?
• Skills and MCP across a custom model: confirm they carry over, and flag any prompt format assumptions baked for Claude or Codex.
• Data egress warning copy for third party and hosted endpoints.
• Relationship to Claudex — a third engine: Claude leads a team of parallel Codex workers #90: whether Custom is a peer engine in the same registry, or a mode under Codex first.

Related

• Claudex — a third engine: Claude leads a team of parallel Codex workers #90 (Claudex, a third engine) sets the third slot precedent and shares the picker and registry work.
• The eliza subagent ACP idea (from the ideas folder in integrations/eliza: elizaOS plugin link + a folder of ideas #192) overlaps with approach 3.