Hermes + Claude Code + Telegram on a cheap always-on thin client.
Hi, I'm Amir 👋
I'm a DevOps engineer, and a surprising amount of my time goes into work that is important but repetitive.
A server needs patching. A CI/CD pipeline fails. A script needs a small change. A Terraform module needs an update. A tool I built needs one more feature. Tests need to be run, branches need to be checked, and somebody still has to make sure the generated code actually works.
None of those jobs is necessarily difficult on its own. The annoying part is the constant context switching.
I kept thinking:
What if I had a small AI worker that was always online, understood my repositories, could call a real coding agent, verify the result, manage Git, and report back to me on my phone?
That is what this setup became.
I use Hermes as the agentic AI harness and orchestrator. Hermes is connected to OpenRouter, where I use a low-cost DeepSeek Flash v4 model for the orchestration layer. When real coding work is needed, Hermes delegates that work to the Claude Code CLI, which is my main coding agent.
The split is intentional:
Claude helps me think through the problem. Claude Code does the main coding. Hermes runs the workflow, performs QA, manages Git, pushes the repo, and keeps me updated through Telegram.
This is not meant to replace me as an engineer. It is meant to remove the repetitive overhead around the work.
How I divide the work between Claude, Hermes and Claude Code
I deliberately do not ask one AI agent to do everything.
When I have a new idea, bug, or feature, I normally start by talking it through with Claude. I explain what I want, what is currently broken, what constraints matter, and what I do not want changed.
Claude helps me turn that into a clear, compact prompt for Hermes.
Then I hand the task over.
Claude: planning and shaping the task
Claude is where I usually work through questions like:
- What exactly should change?
- What should stay untouched?
- What edge case am I forgetting?
- What is the smallest useful test?
- What should count as PASS?
- What instructions does Hermes actually need?
I don't want a giant five-page prompt. By the time I send the task to Hermes, the thinking should already be distilled into something actionable.
Hermes: orchestration, QA and Git management
Hermes is my manager layer.
Its job is not to out-code Claude Code. Its job is to keep the job moving.
In my workflow Hermes is responsible for things like:
- checking the current repo and branch
- launching the coding agent
- monitoring the task
- running the relevant tests itself
- verifying that the result actually matches the request
- checking Git status
- committing only after the task passes
- pushing the branch
- reporting PASS / FAIL, issues and next steps back to Telegram
That separation matters to me:
The agent that writes the code is not the same layer that decides the job is finished.
Claude Code: the main coding agent
When the work gets into the actual codebase, Claude Code CLI is my primary coding agent.
That is where I want the heavier coding intelligence spent:
- reading the codebase
- implementing features
- fixing bugs
- changing tests
- debugging failures
- reasoning about implementation details
Hermes stays relatively lightweight and cheap. Claude Code does the expensive coding work only when I actually need it.
A real prompt from my workflow
Here is a real example.
After discussing the issue with Claude, this was the kind of short prompt I sent to Hermes:
In text form:
On feature/patch-all: after app restart, an analysis left RUNNING is not
marked INTERRUPTED and Analyze/Patch stay disabled. Startup recovery from
faa2ae6 isn't working on a real DB (schema v7, existing runs). Fix + test
with a DB containing a RUNNING analysis before startup.
Full suite + ruff. Commit after PASS, push. Report PASS/FAIL | issues | next.
I like this kind of prompt because it is short but still gives Hermes everything it needs:
where the problem is → what the failure looks like → what must be tested → when Git operations are allowed → what I want reported back.
Hermes does not just trust the coding agent
This is the part that made the setup useful for me rather than just interesting.
After Claude Code finishes, Hermes still has work to do.
Here is a real result from my Telegram workflow:
In this example Hermes exercised the fallback path, brought up the required containers, reran the integration test against the real environment, cleaned things up, and then handled the Git commit.
That is exactly the kind of repetitive workflow I want the orchestrator doing for me.
I want Claude Code focused on implementation.
I want Hermes focused on:
implement
↓
verify
↓
test
↓
inspect
↓
commit
↓
push
↓
report
Telegram is my remote control
Telegram is what makes the whole setup feel different from simply running an AI coding tool on my laptop.
I can be somewhere else and send something like:
Check the latest branch.
Have Claude fix the regression.
Run the targeted tests.
If everything passes, commit and push.
Report PASS/FAIL, issues, and next.
Then I can put my phone away.
The actual work is happening on the thin client at home.
I don't need a remote desktop session. I don't need VS Code open. I don't need my laptop to stay awake.
Telegram is just the control surface.
The hardware cost me about CAD 200
I deliberately did not build an expensive home server for this.
The machine only needs enough resources to run Linux, Hermes, Git, development tools, containers when needed, and the local Claude Code CLI. The heavy LLM computation happens remotely.
I bought a used Dell Wyse 5070 thin client for about CAD 120.
| Part | My setup | Approx. cost |
|---|---|---|
| Thin client | Dell Wyse 5070 | CAD 120 |
| CPU | Intel Celeron J4105, 4 cores | included |
| RAM | 4 GB physical RAM | included |
| Internal storage | 32 GB | included |
| Wireless | Linux-compatible USB Wi-Fi adapter | CAD 20 |
| External storage | 256 GB external SSD | CAD 60 |
| Approx. total | CAD 200 |
The original 32 GB storage was too small once Docker, repositories, package caches and development tools entered the picture.
I mounted the external SSD at:
/data
and moved the storage-heavy workloads there:
/data
├── docker
├── containerd
├── projects
└── swapfile
My project path points to the SSD:
~/projects -> /data/projects
The Wyse has 4 GB of physical RAM, so I also added a 4 GB swap file on the external SSD.
That gives the OS 4 GB RAM + 4 GB swap to work with.
Swap is obviously not the same as real RAM, but for a cheap orchestration box it gives me useful headroom during temporary spikes.
Installing Hermes on Ubuntu 26.04
I run the box on Ubuntu 26.04.
For Hermes itself, I followed the official installation method from the Hermes Agent website.
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
After installation, the important pieces in my setup are:
- Hermes Agent running on the thin client.
- OpenRouter as the model provider for Hermes.
- DeepSeek Flash v4 as my low-cost orchestration model.
- Telegram connected so I can talk to Hermes remotely.
- Claude Code CLI installed and authenticated as the main coding agent.
- Git / GitHub access configured so Hermes can manage the repository workflow.
The main idea is simple:
Spend the expensive model on the coding problem. Keep orchestration lightweight.
What happens when the first coding attempt fails?
One thing I did not want was this:
Claude Code says "done"
↓
Hermes trusts it
↓
bad code gets pushed
That defeats the point of having an orchestration layer.
My preferred flow looks like this:
If QA fails, Hermes has evidence it can hand back to the coding agent:
- failing tests
- command output
- wrong behavior
- dirty Git state
- integration failure
- missing expected changes
The coding agent gets another chance to fix the actual failure.
Only after Hermes can reproduce a passing result does the workflow move to commit and push.
I find that much more useful than simply asking the coding model:
"Are you sure it works?"
How I keep the running cost under control
The hardware cost is only one part of the story.
What matters more over time is where I spend model tokens.
Hermes mainly needs to do things like:
- inspect the current state
- decide which tool or agent should run next
- wait for a result
- run tests
- check Git status
- retry when something fails
- report back to me
For that layer I use a cheaper model through OpenRouter.
I save Claude Code for the part where the extra intelligence actually matters: understanding and changing the codebase.
Cheap model
↓
orchestration / routing / checking
Expensive coding model
↓
used only when real coding is required
I also don't need to pay for a cloud VM just to keep the agent online because the Wyse is doing that job at home.
My ongoing cost is therefore mostly whatever I spend on Claude/Claude Code and OpenRouter usage rather than another always-on server bill.
Guardrails I use before code gets pushed
I want this system to save time, not create a faster way to break things.
Some rules I like are:
- No commit before QA passes.
- No push before the working tree is in the expected state.
- Test the changed behavior, not just whether the code imports.
- Prefer a small targeted regression test first.
- Use the existing full test suite when appropriate before finalizing.
- Report failures instead of hiding or working around them.
- Keep production credentials and private keys outside prompts and public repos.
- Do not let the coding agent silently change unrelated parts of the project.
For my personal projects, I also try not to turn every small change into a giant enterprise QA exercise.
The goal is enough verification to catch the mistake without spending more time testing than the original task was worth.
Where this setup works well — and where it doesn't
This setup is a good fit for work that is:
- repetitive
- repository-based
- testable
- scriptable
- safe to perform from a development machine
- easy to describe with a clear PASS/FAIL condition
Examples include:
- small internal tools
- bug fixes
- repetitive patching utilities
- CI/CD helper scripts
- Terraform changes in non-production environments
- report generators
- automation around Git and testing
It is not something I would blindly point at production and tell:
"Do whatever you think is best."
For high-risk production changes, security-sensitive operations, destructive database work, or anything with a large blast radius, I still want explicit human review and normal change controls.
The agent is useful because it removes repetitive work.
It does not remove engineering judgment.
A few things I learned while building it
1. The orchestration machine does not need to be powerful
At first it is easy to think "AI agent" means "expensive AI hardware."
In this design, it doesn't.
The thin client mostly needs to stay online, run tools reliably, and have enough storage.
2. Separating coding from verification is valuable
Claude Code is very good at coding.
That does not mean I should automatically accept its own definition of "finished."
Having Hermes independently run the checks gives the workflow a much cleaner boundary.
3. A short prompt can be better than a huge prompt
Because I discuss the idea first, the prompt I send to Hermes can stay focused.
That reduces noise and makes failures easier to understand.
4. Reliability matters more than raw speed
The Wyse is not fast.
But it is always there.
For this use case, always available + predictable is more valuable to me than having a much faster machine that disappears when I close my laptop.
5. The best automation is the one I actually use
The biggest win is not that the architecture looks clever.
It is that I can send a task from Telegram, walk away, and come back to a tested branch instead of spending another hour doing repetitive setup and Git work.
Final thoughts
I did not build this because I wanted an AI experiment sitting in a corner of my house.
I built it because I'm a DevOps engineer and I have repetitive work.
Sometimes the right answer to a repetitive task is a Bash script.
Sometimes it is Terraform.
Sometimes it is a small Python tool.
And now, sometimes I can simply describe the problem, let my agent workflow build or fix the tool, verify the result, and give me the branch when it is ready.
My setup has a very simple division of responsibility:
I bring the problem. Claude helps shape the solution. Claude Code writes the code. Hermes manages the job, verifies it, handles Git, and reports back to me.
The Wyse provides the always-on home.
Telegram gives me access from anywhere.
The cloud models provide the intelligence.
A cheap little thin client became my 24/7 AI DevOps coding worker. 🤖
Source / setup files: Amiri83/hermis on GitHub
Original Gist: My 24/7 AI DevOps Coding Agent
Top comments (0)