Tools on Home

Herdr: Panes for My Folders, One Place for My Agents

Sun, 19 Jul 2026 00:00:00 +0000

Screenshot taken from the Herdr website. Herdr runs coding agents in terminal panes and shows their status in a sidebar

Introduction

I recently came across Herdr, a terminal multiplexer built around AI coding agents, and it has quietly turned into one of the tools I use daily. I did not go looking for it. One of my teammates suggested it to me. After installing it and watching this tutorial, I quickly made Herdr part of my work routine. It helped me get rid of the small, repetitive terminal habits I never bothered to fix.

What Herdr Is

Herdr calls itself “One terminal. The whole herd.” It is a single Rust binary, no Electron, no account, no telemetry, and it sits on the same real PTY pane model that tmux and Zellij use. What it adds on top is agent awareness. Each pane can report whether the agent running inside it is working, blocked on a prompt, done, or idle, and Herdr shows that state directly in a sidebar. It supports Claude Code, Codex, Copilot CLI, Cursor Agent, and more than a dozen others. The project is open source under AGPL-3.0, with a commercial license available for organizations that cannot work with AGPL’s terms, and it is built by a single developer, Ogulcan Celik. Install is a one-liner, brew install herdr on macOS, or a binary download from the GitHub releases page.

Before Herdr, my terminal habits were fine but a bit wasteful. I would open a terminal, cd into a folder I use often, then either open . to get to it in Finder or code . to open it in VS Code. Multiply that by the handful of projects and folders I touch every day, and it adds up to a lot of typing that says nothing new. I assumed there were already tools solving exactly this, and there probably are. What changed for me is that Herdr’s panes gave me a place to put the fix without adopting a separate app for it.

I set up a workspace with panes for the folders I return to most: my Obsidian Vault, my homelab repo, a couple of active coding projects. Each pane opens already sitting in the right directory. Switching between them is a keystroke instead of a cd and a guess at how many ../ I need. It is a small thing, but it removed a piece of friction I had stopped noticing, which is usually the sign that a tool is doing its job.

One Place for All My Agents

The bigger change is with agents. I had gotten into the habit of running Claude Code in one terminal window, Codex in another, and switching to a browser tab for a third, then alt-tabbing between all of them to check which one was still working and which one was sitting there waiting on me. It worked, but it meant I was doing the state-tracking myself, one window at a time.

With Herdr, all of that lives in one terminal. Each agent gets its own pane, and the sidebar tells me at a glance which ones are done, which are still working, and which are blocked on a prompt I have not answered yet. I no longer click into a pane just to find out nothing has changed. That alone has cut down how often I interrupt myself checking on agents that are not actually waiting for me.

Conclusion

This post was meant as a short introduction to a tool I only recently discovered. Herdr can be adapted to different workflows through its plugin system. Moshi adds another option by providing remote access to a terminal running Herdr from a phone or tablet. I have used this setup as well and found it very useful.

For now, the two things that sold me are the ones I described here: panes that remove repetitive folder navigation, and one screen that tells me the state of every agent I am running instead of making me ask.

References

Herdr - herdr.dev
Herdr on GitHub - github.com/ogulcancelik/herdr
Herdr tutorial - YouTube
Moshi - getmoshi.app

Tank OS: Running OpenClaw locally in a safe and open way

Sun, 14 Jun 2026 00:00:00 +0000

Tank OS packages OpenClaw as a rootless Podman workload inside a Fedora bootc VM - AI generated

Introduction

In this post, I want to describe how to run OpenClaw on a laptop using Tank OS, a Fedora bootc image that packages OpenClaw as a rootless workload inside an immutable operating system. This is a different path from the approach in the previous post on Deploying OpenClaw on OpenShift. Tank OS runs on a regular machine through a virtual machine. The result is the same agent, running locally without any cluster dependency.

What is Tank OS

Tank OS was created by Sally O’Malley, a principal software engineer at Red Hat and one of the OpenClaw maintainers. The project was published in April 2026, shortly after OpenClaw’s rise to the most-starred software repository in GitHub’s history. In the TechCrunch article that accompanied the release, O’Malley was direct about the risk: OpenClaw is “an incredibly powerful application” but one that can be “dangerous” without proper configuration. “It’s not a tool that you can use easily unless you do have some sort of technical experience,” she said. Tank OS is her response to that gap.

Tank OS packages OpenClaw inside a Fedora bootc image, which is a complete Linux operating system distributed as a container image. You do not install Tank OS on top of your existing OS. Instead, you build a QCOW2 disk image from the bootc image and boot it in a virtual machine. OpenClaw runs inside that VM as a rootless Podman container, isolated from the host.

Prerequisites

The following steps have been tested on a Apple Silicon MacBook. Before starting, the following must be in place:

Homebrew - the package manager for macOS, used to install QEMU
QEMU version 11 or later - the open source machine emulator used to run the Tank OS virtual machine: brew install qemu
Podman version 5 or later — the container engine used by the smoke-test script to pull the Tank OS image and run bootc-image-builder to produce the QCOW2 disk image
An SSH key pair at ~/.ssh/. The Tank OS image locks the default user’s password, so this key is the only way in.

If you do not have a key at that path, generate one:

ssh-keygen -t ed25519 -f ~/.ssh/github -C "tank-os"

Getting Started

The entry point to Tank OS is slightly unconventional, and worth explaining before running anything.

Rather than providing a traditional setup script, the Tank OS GitHub repository includes an agent prompt at the bottom of its README. The idea is that you copy that prompt, paste it into a coding agent such as Claude Code, and the agent handles the bootstrap: it clones the repository, inspects the structure, and produces the smoke-test.sh script that drives the actual workflow. Instead of reading through setup instructions and editing configuration by hand, you hand the prompt to the agent and get a runnable script back.

This is an uncommon way to explore a new project. The approach makes sense here because the setup involves several environment-specific details, including QEMU firmware paths, the difference between rootful and rootless Podman, and SSH key locations. An agent can adapt these to your machine setup without requiring manual edits to a configuration file.

Building, Booting, and Running OpenClaw

Once the agent has produced the smoke-test.sh script, the rest of the workflow runs through that script in four phases.

Phase 1: Building the Disk Image

First, make sure the default Podman machine is running:

podman machine init
podman machine start

Then run the build phase:

./smoke-test.sh build

This phase does several things automatically. It reads your SSH public key from ~/.ssh/github.pub and writes a config.json file that embeds the key into the disk image at build time. Without this step, the VM boots with no login path because the openclaw user password is locked in the default image.

Next, the script establishes a rootful Podman connection, required by the bootc-image-builder to write to the container storage, pulls the Tank OS image into the rootful store, and runs the bootc-image-builder as a privileged container to produce the QCOW2 disk image.

The output is then resized to 20 GB. The default 10 GB is not enough once the 3.5 GB OpenClaw container image and the OS are both on disk.

The build takes a few minutes. When it finishes, the QCOW2 file is in the output directory out-tank-os, ready to boot.

Terminal output once the build step completes.

Phase 2: Starting the VM

./smoke-test.sh vm

This starts QEMU with Apple’s Hypervisor Framework for acceleration, four virtual CPUs, 4 GB of RAM, and port forwarding from localhost:2222 to port 22 inside the VM. The VM boots using the UEFI firmware that Homebrew installs alongside QEMU.

The terminal shows the VM console as the OS starts. The OpenClaw Podman service launches automatically as a systemd user unit.

Phase 3: Connecting to OpenClaw

Open a second terminal and wait for the VM’s SSH daemon to accept connections, then log in:

until ssh -o ConnectTimeout=3 -o StrictHostKeyChecking=no \
 -i ~/.ssh/github -p 2222 openclaw@localhost true 2>/dev/null; do
 echo 'Waiting for VM...'; sleep 5
done && ssh -o StrictHostKeyChecking=no -i ~/.ssh/github -p 2222 openclaw@localhost

Once logged into the VM, verify the agent is running with:

podman ps

Terminal output shows OpenClaw running as Podman container inside the Fedora VM

Once inside the VM, retrieve the gateway authentication token:

jq -r '.gateway.auth.token' ~/.openclaw/openclaw.json

If the command returns nothing, generate a token first, then repeat:

openclaw doctor --generate-gateway-token

In a third terminal, open the SSH tunnel so the OpenClaw web interface is reachable from your browser:

ssh -N -o StrictHostKeyChecking=no -i ~/.ssh/github -p 2222 \
 -L 18789:127.0.0.1:18789 \
 -L 18790:127.0.0.1:18790 \
 openclaw@localhost

Open http://127.0.0.1:18789 in a browser. Paste the gateway token when prompted. The OpenClaw dashboard appears and the agent is ready.

OpenClaw Gateway Dashboard running locally

Adding a Model Provider

Tank OS stores API keys as Podman secrets rather than in configuration files. From inside the VM, create a secret for your provider:

printf '%s' "$ANTHROPIC_API_KEY" | podman secret create anthropic_api_key -
printf '%s' "$OPENAI_API_KEY" | podman secret create openai_api_key -
printf '%s' "$GEMINI_API_KEY" | podman secret create gemini_api_key -
printf '%s' "$OPENROUTER_API_KEY" | podman secret create openrouter_api_key -

Then sync it to the OpenClaw configuration and restart the service:

tank-openclaw-secrets
systemctl --user restart openclaw.service

This updates the OpenClaw configuration and restarts the service.

OpenClaw Dashboard running locally, configured to use Anthropic Claude Sonnet model

Conclusion

Tank OS is a practical way to get OpenClaw running on a laptop without modifying the host system. The agent runs inside a virtual machine on an immutable Fedora base, which limits what a misconfigured agent can reach on the host. Updating is also clean: pull a new bootc image and reboot, and the system reflects the new state.

For teams that already have OpenShift running, the claw-installer approach from the previous post is faster to deploy and integrates with cluster authentication out of the box. Tank OS is the right choice when you want a self-contained local setup that does not depend on a cluster, a cost-effective way to explore OpenClaw, or a portable environment to run a demo.

References

Tank OS - GitHub repository - link
Deploying OpenClaw on OpenShift - link
Sally O’Malley - GitHub Profile - link
Red Hat’s OpenClaw maintainer just made enterprise Claw deployments a lot safer - TechCrunch - link
Running the Red Hat AI Inference Server on OpenShift - link
Fedora bootc documentation - link

Hermes Agent: A Personal AI That Gets More Useful Over Time

Sat, 02 May 2026 00:00:00 +0000

How Hermes Agent Works: From Closed-Loop Learning to Multi-Platform Deployment - AI generated

Introduction

I came across the Hermes Agent project in early March 2026 and deployed it a couple of days later. A couple of weeks in I am still using it daily, and the use cases keep expanding rather than converging. Most tools settle into a narrow routine or fall off altogether. What keeps this one going is that the agent gets more useful the longer you run it. The project is young and moving fast, with new releases every few days. The initial setup requires patience: getting the configuration to a point where it actually saves time takes effort, and the frequent updates occasionally introduce breaking changes. That said, it is genuinely fun to use, and you learn a fair amount along the way.

Hermes Agent is an open-source, self-hosted AI agent framework built by Nous Research, an independent AI research lab based in New York. Nous Research is best known for the Hermes model family, a series of open-weight models fine-tuned on Llama that are used widely in the open-source AI community. The agent framework shares the name but is a separate project. It is MIT-licensed, model-agnostic, and runs on your own infrastructure, either as a self-hosted Python service or as a containerized deployment.

How It Works

The part that makes Hermes Agent different from most agent frameworks is the skill system. The agent ships with a set of preconfigured skills covering common tasks. Beyond that, you can ask it to create a skill from something it just did: it writes a structured Markdown document capturing the approach, what worked, and describes possible edge cases. The next time a similar task appears, the agent loads the relevant skill rather than starting from scratch. Skills can be triggered directly by asking Hermes to run one, or set on a schedule and executed automatically at defined intervals. Over time this turns completed work into a growing library of reusable operating knowledge. Version v0.12.0 added an Autonomous Curator to keep that library from growing unwieldy. It runs on a seven-day cycle by default, grades skills by usage, consolidates overlapping ones, and removes those that have stopped being useful. A short report is written after each run, so you can see what changed and why.

Alongside the skill system, the agent maintains three layers of memory: a persistent store for completed tasks and notes, a full-text search index across prior sessions, and a user model that accumulates preferences over time, coding style, communication tone, timezone, tools. The idea is that the agent gets more useful the longer you run it, not just better at individual tasks in isolation.

My Setup

Hermes Agent runs in my homelab as a service on a dedicated Linux host. Keeping it on a separate machine gives me direct control over what the agent has access to. Incoming traffic is routed through Traefik. I access it through three entry points depending on where I am and what I am doing. The primary interface is the Matrix chat protocol, which means I can reach the agent from any Matrix client on any device. I also connected it to a dedicated email inbox, so it can handle certain tasks asynchronously. For longer sessions at my desk I use Open WebUI, which gives a more comfortable interface for extended conversations.

The model configuration is versatile: the agent supports various AI services and model providers.

What I Gave It Access To

I gave the agent access to three local knowledge sources: my bookmarks, a structured knowledge base, and a local mirror of Red Hat’s product documentation.

The first is my bookmarks folder. I have been saving links as Markdown files in Obsidian for several years. The agent can search and cross-reference that collection when doing research, which means it draws on context I actually care about rather than training data alone.

The second is a knowledge base built on the LLM Wiki principle described by Andrej Karpathy. The idea is to maintain a curated set of structured Markdown files that an AI agent helps write and update over time. Topics, entities, comparisons, each in its own file. The agent both contributes to this knowledge base and draws from it when working on research tasks.

The third is a local mirror of Red Hat’s product documentation. A team mate built a tool called rh-mastery that pulls documentation from docs.redhat.com, converts it to Markdown, and stores it in a structured local directory. Pointed at that directory, Hermes can query accurate, version-tracked product documentation without touching the internet. For someone who spends a lot of time with Red Hat products, this closes a gap that is easy to overlook until you actually need it. More on rh-mastery in an upcomming post.

Practical Uses

The combination of bookmarks, structured knowledge, Red Hat’s product documentation, and the skill system makes the agent genuinely useful for research. When I ask it to investigate a topic, it starts with what I have already collected: prior notes, bookmarks, and documentation. If that is not enough, and when asked, it reaches out to the web to fill the gaps. The result is something grounded in material I collected and curated myself, which makes the output in most cases very useful.

One use I did not expect to find as useful: slide generation. I integrated Marp, a Markdown-based presentation framework, into the workflow. When I need to put together a presentation and am staring at a blank file, I can ask the agent to draft an initial structure. Getting past that first empty screen is often the hardest part. Whether I keep most of what it produces is a different question, but having something to react to is worth more than nothing to start from.

Skills and Subagents

The agent can develop and add skills on its own as it works, but skills can also be added manually or loaded from the community hub at agentskills.io. More interesting to me is the subagent capability: the agent can delegate tasks to specialized subagents, each backed by a specific AI service or holding a particular context. This makes it possible to compose workflows where different parts of a task go to the most appropriate model.

Conclusion

Several weeks in is not a long track record, and the project is still moving fast enough that some things will break between releases. That said, the architecture is sound and the development pace is truly impressive. Whether I will keep running it long-term, I genuinely do not know. For now, it is pulling its weight. For anyone already running a homelab and looking for a self-hosted agent that gets more useful over time rather than staying flat, Hermes Agent is worth the setup time.

Peter Steinberger, the creator of OpenClaw, another widely-used AI agent framework, put it well in a recent TED talk: “The bottleneck is no longer typing. It’s thinking.” That observation fits. The agent handles the mechanical parts of research and structuring. The judgment about what matters and what to do with it still has to come from someone. For now, a human in the loop is still necessary.

References

Hermes Agent on GitHub - link
Hermes Agent Documentation - link
Nous Research - link
Matrix - link
OpenRouter - link
Andrej Karpathy LLM Wiki concept - link
Marp - link
agentskills.io - link
Peter Steinberger TED talk - link

Tools on Home

Herdr: Panes for My Folders, One Place for My Agents

Screenshot taken from the Herdr website. Herdr runs coding agents in terminal panes and shows their status in a sidebar

Introduction

What Herdr Is

Panes Instead of Folder Navigation

One Place for All My Agents

Conclusion

References

Tank OS: Running OpenClaw locally in a safe and open way

Tank OS packages OpenClaw as a rootless Podman workload inside a Fedora bootc VM - AI generated

Introduction

What is Tank OS

Prerequisites

Getting Started

Building, Booting, and Running OpenClaw

Phase 1: Building the Disk Image

Terminal output once the build step completes.

Phase 2: Starting the VM

Phase 3: Connecting to OpenClaw

Terminal output shows OpenClaw running as Podman container inside the Fedora VM

OpenClaw Gateway Dashboard running locally

Adding a Model Provider

OpenClaw Dashboard running locally, configured to use Anthropic Claude Sonnet model

Conclusion

References

Hermes Agent: A Personal AI That Gets More Useful Over Time

How Hermes Agent Works: From Closed-Loop Learning to Multi-Platform Deployment - AI generated

Introduction

How It Works

My Setup

What I Gave It Access To

Practical Uses

Skills and Subagents

Conclusion

References