Running Multiple AI Coding Agents with OpenClaw: Custom Provider Setup & Cross-Agent Memory Challenges

A developer on r/openclaw shares their experience running multiple coding agents via OpenClaw using a third-party API provider to avoid Anthropic rate limits and costs. They configured a custom provider in openclaw.json with DeepInfra, set the API token in .zshrc, and restarted the gateway.

Issues and Fixes

1. API key resolution failure: openclaw doctor showed "apiKey resolution failed" because the env variable wasn't in the daemon's scope. Fixed by adding export to /etc/environment (system-wide) and rebooting the entire system, not just the gateway.

2. DeepSeek V4 Pro timeout: First requests timed out with 120+ seconds TTFT in max reasoning mode. OpenClaw's default LLM_REQUEST_TIMEOUT=60 killed requests before the model finished thinking. Bumped to LLM_REQUEST_TIMEOUT=180 in .env.

3. Context caching not working: The provider supports caching, but OpenClaw requires cacheRead and cacheWrite values in the cost block of the provider config. After adding them, cache hits appeared in logs from the second request with identical MEMORY.md content.

Current Setup

• Backend agent: DeepSeek V4 Pro
• Frontend agent: Qwen3.5 122B A10B
• Migration agent: V4 Flash

Cross-Agent Memory Isolation Problem

Each agent has its own memory.md file in the workspace, but they cannot reference each other's memories when needed. For example, the backend agent writes a schema change to its memory; the migration agent starts later and has no knowledge of that decision. Symlinking memory files causes file lock conflicts because OpenClaw's memory manager uses file locks that clash when multiple agents access the same file simultaneously. OpenClaw's flat file system lacks built-in cross-agent memory queries.

The author asks for solutions short of moving to a vector DB (e.g., ChromaDB) and considers writing a custom skill that reads other agents' memory files and surfaces relevant context.