How I Built a 24/7 AI DevOps Coding Agent for About CAD 200

Amir Amiri — Fri, 02 Oct 2026 05:20:49 +0000

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

🛡️ Real-World Security + Automation = IPloader 🔧

Amir Amiri — Thu, 10 Apr 2025 18:10:15 +0000

A few years ago, while working at a fintech company, I faced a tough challenge.

Every day, our security team sent us a list of hundreds of IPs to be blocked on our FortiGate firewalls — attackers constantly trying to breach our edge.

💡 The problem?

We couldn’t be sure every IP was 100% malicious — some might have even belonged to customers
We didn’t want to block them permanently
And manually managing these lists was a nightmare

So I built a tool: IPloader

✨ What it does:
✔️ Verifies each IP against AbuseIPDB to assess threat level
🗃 Stores IPs in SQLite with expiration dates (for temporary blocks)
🔁 Removes duplicates and keeps the list clean
🌐 Generates a local file that can be served to FortiGate as a dynamic block list

This tool helped automate the entire process — giving our security team confidence in what was being blocked with no guesswork.

👉 The code is here: https://github.com/Amiri83/IPloader
I hope it helps someone else as much as it helped me.

DEV Community: Amir Amiri