How to run Hermes Agent with DeepSeek API from Atlas Cloud

You installed Hermes Agent, the open-source autonomous agent from Nous Research, and now you need a model behind it that is cheap enough to leave running all day and strong enough to handle real tool calls. DeepSeek V4 is an obvious pick on cost, and Atlas Cloud serves the DeepSeek family through a single OpenAI-compatible endpoint alongside 300+ other models. This guide walks through wiring Hermes Agent to DeepSeek on Atlas Cloud, from the base URL and model IDs to a working config.yaml, so the agent runs on production-grade infrastructure without a second SDK.

What you are connecting

Hermes Agent is a persistent, self-improving agent that runs on your own server. It is model and provider agnostic by design, so it does not care whether DeepSeek tokens come straight from DeepSeek or through a gateway, as long as the endpoint speaks the OpenAI API shape.

Atlas Cloud is a full-modal AI inference platform that exposes text, image, and video models through one OpenAI-compatible API key and one billing account. Because the surface is OpenAI-compatible, connecting Hermes is a base URL and key change, not a rewrite.

That pairing matters for a persistent agent. Hermes is built to run for weeks at a time, accumulating memory and reusable skills, so the model behind it is a recurring cost rather than a one-off call. DeepSeek V4 keeps that recurring cost low without giving up tool-calling quality, and routing it through Atlas Cloud means the same key that answers a chat turn can later generate an image or a video clip when a skill needs one. You are not just picking a cheap model, you are picking an endpoint the agent will not outgrow.

Two facts decide the whole setup, and both are worth getting exactly right before you touch a config file:

• The Atlas Cloud base URL is https://api.atlascloud.ai/v1.
• DeepSeek model IDs on Atlas Cloud carry the deepseek-ai/ prefix, for example deepseek-ai/deepseek-v4-pro. This is different from the bare deepseek-v4-pro that Hermes uses with its built-in DeepSeek provider, which points at DeepSeek's own endpoint. When you route through Atlas Cloud, you use the full prefixed ID and a custom OpenAI-compatible provider, not the built-in one.

Step 1: Get your Atlas Cloud API key

Sign in at console.atlascloud.ai, open API Keys, click Create API Key, and copy it somewhere safe. Access is pay-as-you-go, so there is no deposit and no minimum spend. You sign up, get a key, and pay per request.

Keep the key out of version control. Hermes separates secrets from settings on purpose: config.yaml holds non-sensitive structure and is safe to commit or share, while ~/.hermes/.env holds keys and is git-ignored by default. Putting the Atlas Cloud key in .env and referencing it by name from the config is what lets you version your agent setup without leaking a credential.

textCopy
1echo "ATLASCLOUD_API_KEY=your-atlas-cloud-key" >> ~/.hermes/.env

Step 2: Confirm the DeepSeek model IDs you can call

Atlas Cloud publishes its live model list at a public endpoint, so you never have to guess an ID. A quick call returns the exact strings the API accepts.

textCopy
1curl https://api.atlascloud.ai/v1/models \
2  -H "Authorization: Bearer $ATLASCLOUD_API_KEY"

Querying the list first is not busywork. Model IDs drift as new versions ship, and a stale ID from a blog post or an old script is the most common reason a first call fails. The /v1/models endpoint is the ground truth for what the API will accept today, so checking it before you edit a config saves a round of unknown-model errors. The DeepSeek entries you will use most often are these:

DeepSeek V4 Pro lists at $1.68 per million input tokens and $3.38 per million output tokens on Atlas Cloud, while V4 Flash lists at $0.14 input and $0.28 output. That gap is the whole reason to split main and auxiliary work across the two, which the config below does.

Step 3: Point Hermes at Atlas Cloud

Because Atlas Cloud is a custom OpenAI-compatible endpoint rather than Hermes's built-in DeepSeek provider, you define it explicitly in ~/.hermes/config.yaml. The provider block names the base URL and the environment variable that holds your key, and the model block selects the prefixed DeepSeek ID.

textCopy
1inference:
2  provider: atlascloud
3  base_url: https://api.atlascloud.ai/v1
4  api_key_env: ATLASCLOUD_API_KEY
5  model:
6    default: deepseek-ai/deepseek-v4-pro

Save the file, then start the agent.

textCopy
1hermes

If the first message returns a normal reply, the wiring is correct. If you get an authentication error, the key in .env is wrong or not loaded; if you get an unknown-model error, re-check the deepseek-ai/ prefix against the /v1/models output from Step 2.

The single most common mistake here is reaching for Hermes's built-in deepseek provider while expecting Atlas Cloud to answer. The built-in provider is hard-wired to DeepSeek's own endpoint and its bare model names, so it will happily bill your DeepSeek account and ignore Atlas Cloud entirely. Routing through Atlas Cloud is a deliberate custom-provider choice: your own base_url, your Atlas Cloud key, and the prefixed deepseek-ai/ model IDs. Keep those three together and the two paths never get confused.

Step 4: Send cheap work to Flash

Hermes runs a lot of low-value calls behind the scenes: web summarization, vision analysis, context compression, command approval. Paying V4 Pro rates for those is waste. Point the auxiliary slots at V4 Flash so the main loop keeps the stronger model while the background chores run at a fraction of the cost.

textCopy
1auxiliary:
2  web_extract:
3    provider: atlascloud
4    base_url: https://api.atlascloud.ai/v1
5    api_key_env: ATLASCLOUD_API_KEY
6    model: deepseek-ai/deepseek-v4-flash
7  compression:
8    provider: atlascloud
9    base_url: https://api.atlascloud.ai/v1
10    api_key_env: ATLASCLOUD_API_KEY
11    model: deepseek-ai/deepseek-v4-flash
12    timeout: 120

Each auxiliary slot accepts its own provider, model, base URL, key, and fallback chain, so you can tune every background task independently.

Step 5: Add a fallback for resilience

A long-running agent will eventually hit a rate limit or a timed-out connection. A fallback chain keeps it working instead of erroring out. Here the compression task tries V4 Flash first, then falls back to a second Atlas Cloud model before giving up.

textCopy
1auxiliary:
2  compression:
3    provider: atlascloud
4    base_url: https://api.atlascloud.ai/v1
5    api_key_env: ATLASCLOUD_API_KEY
6    model: deepseek-ai/deepseek-v4-flash
7    fallback_chain:
8      - provider: atlascloud
9        base_url: https://api.atlascloud.ai/v1
10        api_key_env: ATLASCLOUD_API_KEY
11        model: deepseek-ai/deepseek-v3.2

Hermes tries each entry in order until one succeeds, so a single provider hiccup does not stall the agent. For an agent that runs unattended on a schedule, this is the difference between a cron job that quietly recovers and one that dies at 3am and leaves you a stack trace in the morning.

When this setup is the right fit

Running Hermes on DeepSeek through Atlas Cloud makes the most sense when you want one key and one bill across everything the agent touches. Because the same endpoint also serves image and video models, an agent that starts out text-only can later generate images or clips without a new integration or a second vendor account. If your agent will only ever call DeepSeek and nothing else, the built-in DeepSeek provider pointed at DeepSeek's own API is the simpler path. The Atlas Cloud route earns its place once you want room to add models across modalities behind a single, OpenAI-compatible surface.

You can confirm every model ID and live price yourself at atlascloud.ai/models before you commit any of this to a config file, which is the habit worth keeping as the DeepSeek lineup evolves.