-
Notifications
You must be signed in to change notification settings - Fork 5
OpenClaw Integration
Once the Hydra cluster or speculative proxy is running, register it as a provider in OpenClaw so agents can use the models.
Add to ~/.openclaw/openclaw.json under providers:
"hydra": {
"baseUrl": "http://<rocm-machine-ip>:8080/v1",
"apiKey": "no-key",
"api": "openai-completions"
}For the speculative decoding proxy:
"hydra-proxy": {
"baseUrl": "http://127.0.0.1:8088/v1",
"apiKey": "no-key",
"api": "openai-completions"
}Add models under models (or agents.defaults.models):
"hydra/qwen3-72b": {
"id": "qwen3-72b",
"name": "Qwen3 72B (Hydra Cluster)",
"provider": "hydra"
}For the proxy (output quality = target model):
"hydra-proxy/qwen3-32b": {
"id": "qwen3-32b",
"name": "Qwen3 32B (Speculative Proxy)",
"provider": "hydra-proxy"
}Override specific cron jobs or agents to use Hydra models:
{
"model": "hydra/qwen3-72b"
}Since Hydra serves an OpenAI-compatible API, it works the same as any other provider in OpenClaw. No special configuration needed beyond the provider/model registration.
Hydra runs alongside existing providers:
-
llama-desktop(GLM-4.7-Flash on port 8080 of Windows desktop) — may need to change ports if both run simultaneously -
ollamaproviders — unaffected, different ports -
anthropic/anthropic-fleet— cloud providers, no conflict
Port conflict note: The Windows desktop currently runs llama-server on port 8080 for GLM. If Hydra's coordinator also uses 8080 (on the ROCm machine), there's no conflict since they're different machines. But the Windows rpc-server instances share the desktop's GPUs — running both GLM llama-server and rpc-server simultaneously may cause GPU memory pressure.
If you swap models with hydra swap deepseek-r1-70b, the API endpoint stays the same but serves a different model. OpenClaw agents calling hydra/qwen3-72b would get DeepSeek responses. To handle this cleanly, register each model as a separate OpenClaw model and only start the one you need, or implement a routing layer.