Venice Overview

Venice is a direct-API LLM provider you can layer onto an Intern in addition to the runtime's default Anthropic-shaped proxy. Unlike Hermes, it does not replace the runtime — it adds a venice block to whichever runtime is active so the agent can call api.venice.ai directly.

The same hand-edits apply to both runtimes. Which runtime's config you touch is decided by active_agent in /root/config/config.json.

Where it lands

┌─ Intern device ───────────────────────────────────────────┐
│                                                            │
│  /root/config/config.json                                  │
│   └─ venice_inference_api_key + venice_inference_model     │
│      persisted so a later agent swap auto-replays Venice   │
│                                                            │
│  Active runtime gets the venice block:                     │
│   ┌───────────────────────┐   ┌─────────────────────────┐  │
│   │  openclaw.service     │   │ hermes-gateway.service  │  │
│   │  /root/.openclaw/     │   │ /root/.hermes/          │  │
│   │   openclaw.json       │   │  config.yaml            │  │
│   │   models.providers    │   │  providers.venice       │  │
│   │     .venice           │   │  model.default + .provider │
│   │   agents.*.models     │   │                         │  │
│   │     "venice/<id>": {} │   │                         │  │
│   │   agents.*.model      │   │                         │  │
│   │     .primary          │   │                         │  │
│   └───────────────────────┘   └─────────────────────────┘  │
└────────────────────────────────────────────────────────────┘

What the install does

Provisioning Venice on a device boils down to:

1. Pick the Venice baseUrl, transport, and model id you want — these are values you fetch from api.venice.ai/api/v1/models or copy from venice.ai's docs.
2. Write the venice block into the active runtime's config file (openclaw.json or config.yaml).
3. Persist venice_inference_api_key and venice_inference_model into /root/config/config.json.
4. Restart the active gateway (openclaw or hermes-gateway).

The installation walkthrough runs these by hand from an SSH session.

What survives an agent swap

The Venice key and selected model are stored on the device itself, not just in the runtime config. When you later run Hermes setup on an OpenClaw device that has Venice provisioned (or vice versa), intern-server re-applies the venice block to the freshly-written ~/.hermes/config.yaml from the saved key — no re-install needed.

This replay is best-effort: failure is logged and surfaced to the maintainer chat, but it does not roll back the agent swap. Re-running the SSH install is the documented retry.

Concern	Reused across agent swap?
venice_inference_api_key in config.json	yes
venice_inference_model in config.json	yes — used to set model.default on hermes / model.primary on openclaw
baseUrl / transport / model list on disk	partially — the existing on-disk entries stay, replay reuses the values from config.json and you re-write any extra models you want

There is no symmetric replay on Hermes → OpenClaw — if you swap back, the saved key stays in config.json but the runtime config doesn't get the venice block until you re-run the install.

When to add Venice

You want Venice if any of:

• You need access to Venice-only models (e.g. uncensored variants) that aren't on the default LLM proxy.
• You're running an evaluation comparing Venice models against the default Claude lineup without switching the whole runtime.

You can skip Venice if:

• The default llm_base_url / llm_model from pairing already covers what you need.
• You don't want a second LLM bill — Venice is billed directly by venice.ai using the key you provision.

Where to go next

1. Manual Install over SSH — write the venice block into the active runtime's config, persist the key, restart.
2. Configuration — where Venice lands in openclaw.json and ~/.hermes/config.yaml, the persisted keys in config.json, how to inspect, edit, and remove a Venice provisioning by hand.

Prerequisite: the device must already be paired and have a working llm_base_url — Venice is layered on top of the base setup, not a replacement for it. SSH access is also required; see Developer Edition → SSH Access (standard Interns don't ship openssh-server).