Adding a Fallback Model to Hermes with Amazon Bedrock
I already have Hermes running against a model I configured on Azure AI Foundry, and to be fair it works. The catch is in the word "already": one provider means one point of failure. A quota cap, a throttled endpoint, or a bad afternoon on someone else's cloud, and the assistant I lean on all day just sits there returning errors. Leave the Azure AI Foundry setup exactly as it is, then wire Amazon Bedrock in behind it as a fallback, so Hermes has somewhere else to go when the primary provider is not answering
Series: Amazon Bedrock Usage and Applications (2 articles)
- 2Adding a Fallback Model to Hermes with Amazon Bedrock This article
A few other reasons pushed me into it as well:
- Redundancy that does not need me. If Azure is throttled or out of quota, I want Hermes to fail over on its own instead of waiting for me to notice.
- A wider model catalogue. Bedrock hosts models Foundry does not, so running two providers means I can pick a model to suit the task rather than settling for whatever my single provider happens to offer.
- Region and cost control. Bedrock lets me pin a specific region and track spend separately, which matters once one provider starts getting expensive for a particular workload.
- Learning the mechanics before I need them. Figuring out how Hermes handles a provider chain is much nicer on a quiet Tuesday than during an actual outage.
- What follows is exactly what I did, including the part where I built the whole demo around a model my account could not even use.
What follows is exactly what I did, including the part where I built the whole demo around a model my account could not even use.
Before you start, you will need three things: a machine with Hermes already installed and a working primary provider configured, an AWS account with access to Amazon Bedrock in a region you can actually use, and permission to create long-term API keys in that account. Budget around thirty minutes if nothing goes wrong, and an extra hour if you pick a model your account cannot call.
One thing that made this easy to justify: Bedrock bills on demand, per token. A fallback provider that never gets invoked costs nothing beyond the requests it actually serves, so the insurance is close to free until the day you need it.
Where the fallback sits. Every request goes through the Hermes gateway to the primary provider; only when that provider is unavailable does the chain continue to Bedrock.
Part 1: Deploying a Model on Amazon Bedrock
The first half of this job happens entirely inside the AWS console and has nothing to do with Hermes yet. All you are really doing here is making sure your AWS account can serve a model, and that you hold a credential Hermes can authenticate with later.
The whole setup in five moves. The first two happen in the AWS console (orange); the rest happen on the Hermes machine (blue).
Sign in to the AWS Management Console, open Amazon Bedrock, and go to the model catalogue.
Click View Model Catalog. This lists every foundation model AWS exposes in your currently selected region. Check that region label at the top of the console before going any further, because availability genuinely differs from one region to the next, and this is the detail that came back to bite me later.
Next, pick the model you want to deploy and use with Hermes. Write down the exact model identifier rather than the friendly display name, because the identifier string is what shows up later on the Hermes side.
Fill up and submit the Use Case details form. AWS asks for this before it will grant access to certain models, and a couple of honest sentences about what you are building and who will use it is enough. Most models are approved almost instantly; a few sit in review for a while.
With access granted, generate a long-term API key. Bedrock will happily give you a short-term key too, but those expire, and an expired credential means your fallback quietly stops being a fallback right when you need it. Copy the key somewhere safe the moment it appears, because AWS will not show it to you twice.
Part 2: Adding Bedrock to Hermes as a Fallback
With the AWS side sorted, everything else happens on the machine running Hermes.
Run hermes fallback add on the Hermes-enabled machine. When it prompts you for a model provider, choose AWS Bedrock. Worth noting: this is the fallback command, not the primary model command, so your existing Azure AI Foundry configuration is left completely alone. Nothing you do in this step can break what is already working.
Enter the AWS region your Bedrock models live in, then authenticate using the long-term API key you generated earlier. If authentication fails at this point, check the region before you start suspecting the key. In my experience the region is wrong far more often than the credential is.
Once authentication succeeds, Hermes shows you the models your account can actually reach and asks which ones you want to use. You can select more than one, and the order is not cosmetic: Hermes walks down the chain from top to bottom whenever the provider above is unavailable. Treat that list as a priority order, not a shopping basket.
Part 3: Promoting Bedrock to the Primary Model
At this stage Bedrock is sitting in the back seat as a backup. I wanted to reverse the arrangement and make Bedrock the primary while Azure AI Foundry slides down into the fallback slot, partly because I preferred the Bedrock catalogue and partly because I wanted proof the chain works in both directions.
The promotion, in effect. Nothing is added or removed; the two providers simply trade places in the chain.
There is no dedicated "promote" command in Hermes, so the manual route is a short sequence of steps rather than a single instruction:
- Select the fallback provider/model as the new primary: hermes model
- Remove the now-duplicate model from the fallback chain: hermes fallback remove
- Optionally add the old primary model as a fallback: hermes fallback add
- Restart the messaging gateway: hermes gateway restart
- Verify the result: hermes status / hermes fallback list
That sequence works, and it is good to know what is happening underneath. But since I already had a working provider configured, I would rather just ask Hermes to rearrange itself. This is the part I genuinely enjoy about the tool: the configuration is something you can talk to, not only something you type commands at.
Prompt: Okay now please make the Model I configured for AWS Bedrock into the main model, and make the Azure one to be the fallback model!
The screenshots above show Hermes reconfiguring the provider chain on its own, and the confirmation it returns once the swap is done.
Part 4: Testing the Switch
Configuration you have not tested is just an assumption with extra steps, so the next thing is to confirm Hermes really is talking to Bedrock.
Type /model to bring up the model picker. You will be prompted to select a provider first. Pick bedrock-mantle or BEDROCK, then choose the specific model from the list underneath it.
The active model should switch straight away. Send it a plain "Hello" to check that the model actually responds, rather than just looking correct in the menu. Appearing in a dropdown and serving a request are two very different things, as I was about to find out.
Part 5: The Obstacle, and What It Actually Taught Me
This is where skipping the research caught up with me. Claude Sonnet 5 is not available to my account in this region, so the exact model I had built the entire walkthrough around refused to serve a single request. The catalogue happily showed it to me; entitlement was another matter entirely.
Rather than guessing again, I asked Hermes to tell me what my account could genuinely reach. That produced a much more useful list:
Verified available:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
• DeepSeek: deepseek.v3.1, deepseek.v3.2
• Kimi: moonshotai.kimi-k2.5, moonshotai.kimi-k2-thinking
• GLM: zai.glm-4.6, zai.glm-4.7, zai.glm-4.7-flash, zai.glm-5
• Qwen:
• qwen.qwen3-235b-a22b-2507
• qwen.qwen3-32b
• qwen.qwen3-coder-30b-a3b-instruct
• qwen.qwen3-coder-480b-a35b-instruct
• qwen.qwen3-coder-next
• qwen.qwen3-next-80b-a3b-instruct
• qwen.qwen3-vl-235b-a22b-instruct
• Mistral:
• mistral.devstral-2-123b
• mistral.magistral-small-2509
• mistral.ministral-3-3b-instruct
• mistral.ministral-3-8b-instruct
• mistral.ministral-3-14b-instruct
• mistral.mistral-large-3-675b-instruct
• mistral.voxtral-mini-3b-2507
• mistral.voxtral-small-24b-2507
• NVIDIA Nemotron:
• nvidia.nemotron-nano-12b-v2
• nvidia.nemotron-nano-3-30b
• nvidia.nemotron-nano-9b-v2
• nvidia.nemotron-super-3-120b
• OpenAI GPT-OSS:
• openai.gpt-oss-120b
• openai.gpt-oss-20b
• openai.gpt-oss-safeguard-120b
• openai.gpt-oss-safeguard-20b
• Gemma 3: google.gemma-3-4b-it, google.gemma-3-12b-it, google.gemma-3-27b-it
• MiniMax: minimax.minimax-m2.1, minimax.minimax-m2.5
• Writer: writer.palmyra-vision-7b
I switched to moonshotai.kimi-k2.5 and it worked on the first try. The lesson is cheap enough to hand over for free: verify model availability for your specific account and region before you design anything around a particular model. A catalogue page tells you what Bedrock offers, not what you are entitled to use. Five minutes of checking would have saved me a rebuilt demo. If you would rather not click through the console, aws bedrock list-foundation-models --region <your-region> returns exactly what your credentials can see, which is the only list that matters.
There is a silver lining here that is worth stating plainly. Because the fallback chain was already in place, a model that flatly refused to work did not take the assistant down with it. That is precisely the scenario this whole exercise was meant to cover, and it turned up on day one without me having to simulate it.
How Hermes Differs from OpenClaw
The two get compared constantly, and it makes sense, because they solve the same broad problem: sitting between the chat surfaces you already use and whichever model providers you have credentials for. Once you actually run them, though, the differences show up quickly. What follows is based on my own Hermes deployment, so treat the Hermes side as one person's observation rather than official documentation.
| Dimension | Hermes | OpenClaw |
|---|---|---|
| Provider failover | A named feature with its own commands: add, remove, list and verify the fallback chain | Supported through model failover and auth profile rotation, configured closer to the file layer |
| Configuration style | Conversational. Describe the outcome and Hermes rearranges itself | Declarative. Edit openclaw.json and restart the gateway, which reviews better in version control |
| Channel reach | Focused on the gateway and CLI experience | Around two dozen chat channels via plugins: WhatsApp, Telegram, Signal, Matrix, Teams and more |
| Model providers | Enterprise endpoints such as Azure AI Foundry and Amazon Bedrock, with region pinning and quota governance | Deliberately agnostic: hosted APIs, subscription-backed accounts and local models via Ollama |
| Licence and ecosystem | Closed and curated, easier to defend to a security reviewer | MIT-licensed under a non-profit foundation, with a public skills marketplace |
| Best suited to | Governed cloud setups that need provider failover working in minutes | Developers who want their assistant on every chat app, with full control of the source |
In practice the split is less about which tool is better and more about who is doing the asking. Hermes suits a governed environment where resilience and auditability matter; OpenClaw suits someone who wants their assistant everywhere and wants to read the source that runs it. Plenty of people will reasonably end up running both.
1
2
3
4
5
6
7
8
9
Command Cheat Sheet
Everything used in this walkthrough, collected in one place:
hermes fallback add: attach a provider to the fallback chain
hermes fallback remove: drop a provider from the chain
hermes fallback list: show the chain in priority order
hermes model: set the primary model
hermes gateway restart: restart the messaging gateway after a change
hermes status: confirm which provider is currently live
/model: switch models from inside a running session
Conclusion
Adding Amazon Bedrock as a fallback behind my existing Azure AI Foundry setup took an afternoon, and most of that was spent recovering from my own bad assumption about model access. The work itself is small: deploy a model, generate a long-term key, run hermes fallback add, authenticate, pick your models. The payoff is that Hermes no longer depends on one provider staying healthy.
Three things are worth carrying away from this:
- Check entitlement, not availability. The Bedrock catalogue shows what AWS sells. It does not show what your account and region are allowed to call. Confirm that first, before you build anything on top of a specific model.
- Order your fallback chain deliberately. Hermes works down the list from top to bottom, so the sequence you choose during setup is the failover policy you are going to live with. Put the model you actually trust at the top.
- Use long-term credentials for anything meant to be a safety net. A fallback secured with an expiring key stops being a fallback a few hours after you set it up, and you will not find out until the day it matters.
The switch from Azure primary to Bedrock primary also proved the chain runs in both directions, which is the real point. Provider redundancy is only useful if you have watched it work. Next on my list is deliberately breaking the primary provider to confirm the failover triggers on its own, without me typing a single command.
Series: Amazon Bedrock Usage and Applications (2 articles)
- 2Adding a Fallback Model to Hermes with Amazon Bedrock This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article