The obvious fix is to bind the dashboard to 0.0.0.0 and open the port. Don’t. That puts your agent control panel on the public internet. The better move is to keep the dashboard bound to 127.0.0.1 on the server and tunnel that port to your laptop over SSH. Your browser hits localhost, SSH carries the traffic, and nothing is ever exposed.

Three steps.

1. Open an SSH tunnel

From your local machine, connect to the server with a local port forward:

ssh -L 9119:127.0.0.1:9119 root@your-server.example.com

The -L 9119:127.0.0.1:9119 part is the whole trick. It says: take local port 9119 on my laptop and forward it to 127.0.0.1:9119 on the remote side. Anything I send to localhost:9119 here comes out as a connection to 127.0.0.1:9119 there.

Leave this SSH session open. The tunnel only lives as long as the connection does.

2. Start the dashboard on the remote

Inside that same SSH session, on the server, run:

hermes dashboard --host 127.0.0.1 --port 9119 --no-open

Two flags matter here:

• --host 127.0.0.1 keeps the dashboard private to the box. It’s not listening on any public interface — only the loopback address that our tunnel targets.
• --no-open stops Hermes from trying to launch a browser on the server. There isn’t one, and without this flag it’ll complain.

3. Open it in your local browser

Back on your laptop, go to:

http://localhost:9119

The request travels down the tunnel and lands on the dashboard running remotely. You get the full Kanban view — boards, channels, gateway status, sessions — exactly as if it were running locally.

Takeaway

Keep the dashboard bound to 127.0.0.1 on the server and let SSH do the reaching. One -L flag, no open ports, no reverse proxy, no auth layer to bolt on. Close the SSH session when you’re done and the tunnel disappears with it.

Hermes Agent is what I switched to when I wanted the same general promise, but less setup drama and fewer updates that turned into an afternoon.

Setup should not be a side quest

This was the first difference. Hermes was easier to get running and easier to keep running.

That sounds like a small thing until you use these tools every day. Then it is the thing.

Hermes feels agent-first

A lot of tools bolt agent behavior onto a chat wrapper. Hermes feels built around the agent loop itself: tools, memory, skills, cron jobs, delegation, real workflows.

That matters. I do not want a demo. I want a system.

The learning loop is the real feature

The killer feature for me is that Hermes can turn solved work into reusable skills.

Do something once, save the workflow, load it next time. The system gets better because I used it, not because I waited for a product update and hoped nothing else broke. Strange concept, I know.

Memory that does useful work

Another thing Hermes gets right is memory.

It automatically keeps track of useful context, organizes it, and makes it available later when I need it. That sounds obvious until you use tools that forget everything the moment the session ends.

It means less re-explaining, less copy-pasting, and a better shot at building on previous work instead of recreating it from scratch.

Stability wins

OpenClaw updates kept breaking enough things that I stopped trusting the ground under my feet.

Hermes has felt more stable, more composable, and generally better thought through from a security and operations point of view. Not perfect. Just less brittle, which is the adult version of exciting.

Why I stayed

I switched for easier setup.

I stayed because Hermes helps me build a repeatable system around AI work instead of starting fresh every session.

That is the difference between a fun tool and infrastructure.

Links:

• Hermes Agent: hermes-agent.nousresearch.com

What it shows

One terminal window, every running agent at a glance. For each Claude Code and Codex CLI session it tracks:

1. Tokens used and context window fill % — per-session bars with warnings when one is getting close to full. This is the headline feature for me.
2. Rate limit status — your quota in real-time, so you stop guessing whether you’ve been throttled.
3. Child processes and open ports — if an agent spawned a dev server and forgot to kill it, you’ll see the orphan port and can clean it up with one key.

It also catches subagents, git status, and the current task each session is on. All read-only — no API keys, no auth.

Why this matters

The dumb thing about running multiple agents is that you can’t actually see them. Each one lives in its own terminal pane, you have to switch around to check status, and there’s no system-level view of who’s burning tokens or about to compact. abtop is the missing system view. One screen, every session, live.

Installing it

macOS or Linux, one line:

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/graykode/abtop/releases/latest/download/abtop-installer.sh | sh

Or via Cargo if you have Rust set up:

cargo install abtop

Then just run abtop. Recommended terminal size is 120x40 or larger.

Windows users — it needs Unix tools (ps, lsof), so run it inside WSL.

Bonus: tmux integration

If you already work in tmux, this gets better. abtop discovers sessions across panes, and pressing Enter on a row jumps you straight to the terminal running that agent. So the flow is: scan abtop → see the one at 87% context → Enter → you’re there, ready to wrap up or compact.

That’s it. Tiny tool, dead-simple install, and once it’s in your stack you’ll wonder how you managed running parallel agents without it.

Links:

• Repo: github.com/graykode/abtop

With Conductor, it’s closer to ten.

What it is

A Mac app that runs Claude Code agents in parallel. Not a new model, not a new IDE — a harness. It reuses my existing ~/.claude setup verbatim: skills, hooks, MCP servers, RTK, CLAUDE.md. No re-onboarding.

One overview, many agents, many projects

Every workspace across every project, one window, status at a glance.

Right now: one agent writing this post, one on a Jekyll deploy script, one on a flaky test in another repo, one drafting a PR. Three projects. I know who’s blocked on me without clicking in.

The loop: plan → implement → review → PR → merge → archive

Every task moves through the same six steps. My job is two of them — approving the plan, reviewing the diff. The rest is the agent.

Worktrees + setup/run scripts

Every task gets its own git worktree. Own branch, own checkout. Three versions of the same site can run side by side with no collisions. Each workspace runs my project’s setup script (deps, env) and run script (dev server) on demand. Testing a branch is one click.

Staying out of the IDE

The unexpected win. When the editor is in front of me I twitch — rename things, fix a semicolon, lose an hour. Conductor keeps me one step back, on intent and review.

When I actually need code, the diff viewer is right there. “Open in IDE” and “open terminal in this worktree” are one click each. No access lost — just no default pull.

GitHub issues in, PRs out

Point Conductor at an issue. It opens a workspace with that context, plans, executes, opens a linked PR. Backlog turns into throughput.

So is it smarter than Claude?

No. That’s the point. Conductor isn’t a better model — it’s the safety rails (worktrees, PRs, structured review, archive) that let me run a lot of Claude at once without it turning into chaos.

If your bottleneck moved from “the AI is too slow” to “I can only supervise one of these at a time,” try it.

That’s where RTK comes in. It’s a small tool I’ve started leaning on to keep my Claude Code context lean, and it’s quietly become one of the highest-leverage things in my workflow.

Why bother saving tokens?

A few reasons it matters more than people think:

1. Better answers. Smaller, more focused context means the model isn’t fishing through noise. The signal-to-noise ratio is what actually drives output quality.
2. Longer sessions. Every token you save is a token you can spend later — on more code, more iteration, more back-and-forth before you hit a wall.
3. Lower cost. Tokens aren’t free. On long agentic runs, the savings add up fast.

What RTK actually helps with

The top things I use it for:

• Trimming tool output before it hits context — big file reads and command output get summarized down to what matters, not the full dump.
• Reusing context across sessions — instead of re-feeding the same project background every time, RTK keeps a compact version on hand.
• Pruning stale turns — older parts of the conversation that no longer matter get cleaned out so the live working set stays sharp.

Installing it for Claude Code

Dead simple:

npm install -g rtk
rtk init

Then point Claude Code at it once and you’re done. From there it runs in the background.

What it looks like in practice

That’s it. Short post, but if you’re hitting context limits in Claude Code, RTK is worth ten minutes of your time.

Real plugin. Well-built. Permanent in Claude Code setup now.

What it do

Caveman is Claude Code skill from Julius Brussee. Strip output to fragments — no articles, no filler, no pleasantries, no hedging. Technical content stay intact. Padding die.

Repo tagline: “why use many token when few token do trick.” Tells most of story.

Why worth doing

Reasons stuck:

1. Output compress hard. Public benchmark avg 65% fewer output tokens. Range 22–87% depending on prompt.
2. Brevity may help accuracy. March 2026 paper: constrain big models to brief responses, accuracy up 26 points on certain benchmarks. Less rope to hang model with.
3. Compress memory files too. Sub-skill Caveman Compress rewrite CLAUDE.md into caveman-speak. Cut ~46% off input tokens every session. Input side dominate real coding work.

Honest caveat: headline number misleading. Typical 100,000-token session, prose responses ~6,000 tokens. Compress save ~4% total. Real wins: readability, speed, compress-CLAUDE.md trick.

Install it

Two commands in Claude Code:

/plugin marketplace add JuliusBrussee/caveman
/plugin install caveman@caveman

Restart Claude Code, and the skill loads at the start of every session. Trigger with /caveman, or just say “caveman mode” or “less tokens please” — Claude understands.

There are three intensity levels: /caveman lite drops filler, /caveman full switches to fragments, /caveman ultra goes maximum terse. I live in full. Ultra is funny for about ten minutes.

The honest take

There’s a fair counter-argument floating around — that saving a couple hundred output tokens is negligible when coding sessions burn through hundreds of thousands of tokens. Fair. But for me the win isn’t really the dollar savings. It’s that responses are faster to read, my CLAUDE.md is half the size, and the model seems to get to the point quicker.

Install takes a minute. If it doesn’t click, uninstall is also a minute. Worth a try.

Wait — you done already?

Notice how fast the first half of this post went down? That was caveman. Same point, half the words, and your eyeballs are already at the bottom of the page wondering where the rest of the article went.

There is no rest of the article. Caveman ate it. Cave brain happy. Token meter happy. Your lunch break, miraculously, intact.

Links:

• Repo: github.com/JuliusBrussee/caveman

2024 was about prompt engineering—learning how to talk to AI. 2025 was about context engineering and agents—learning how to make AI useful. 2026 will be about something bigger: scaling AI across the entire company.

Not just for developers. Not just for data teams. Everyone.

I’m sharing three perspectives on what this means:

1. Multi-agent orchestration — The shift from single agents to coordinated teams of specialized agents working in parallel.

2. Enabling AI company-wide — Why CTOs must make safe, effective AI tools available to everyone—before shadow AI fills the gap.

3. Everyone builds their own agents — The most important shift: empowering every employee to create and own AI agents that automate their work.

These aren’t speculative. They’re pragmatic bets on where the value will come from in 2026.

1. Multi-Agent Orchestration

2024 was the year of prompt engineering. 2025 was the year of context engineering and AI agents.

My take: 2026 will be the year of multi-agent orchestration—multiple specialized agents working in parallel with shared memory and context.

Here’s what that means in practice:

An architect agent reasons deeply about a problem and creates a plan. It then delegates individual tasks to the right agents for the job. Writing straightforward code? A fast, lightweight agent. Testing whether a new feature actually works? That might need deep thinking and multimodal capabilities to understand the UI, the logs, and the expected behavior.

The skill isn’t just “use more agents.” It’s knowing which agent for which task—and orchestrating them effectively.

What this means for developers:

Your value shifts from writing code to delivering value faster. You’ll spend more time directing agents, verifying results, and catching what matters: bugs and security flaws.

Clean code aesthetics? They matter less now—AI can read and refactor messy code just fine. But buggy or insecure code is the real risk. When you’re not writing the code yourself, how do you catch the problems? That’s the skill to develop.

Legacy code you don’t understand? Just ask AI to explain it—or better yet, have it make the changes for you.

Software craftsmanship isn’t dead. But it’s no longer the differentiator. In 2026, what sets you apart is the combination of judgment, the courage to push limits, and the ability to compress time to value. The landscape is shifting fast—and the most valuable skill is constantly discovering what’s possible and helps to deliver value more effectively.

2. Enabling AI Across the Company

As a CTO in 2026, your job isn’t just to adopt AI for engineering—it’s to enable everyone in the company to use AI. Not optional. Not “nice to have.” This is an imperative.

Here’s the reality: 78% of AI users bring their own tools to work—and 52% won’t even admit they’re doing it (CloudSphere, 2025). They’re not being malicious. They’re trying to be productive. And if you don’t give them approved tools, they’ll find their own.

Shadow AI is already inside your company. The question is whether you’re going to fight it or channel it.

What this means for CTOs:

Give people tools they can safely use with company data. This doesn’t mean chasing whatever went viral on LinkedIn last week—it means providing tools that do the job well, with proper security and data governance. If the approved option is good enough, people won’t go looking elsewhere.

Rethink how you train people to use AI. Forget scheduled training sessions that are outdated by the time they happen. AI is moving too fast. Instead, build a culture of continuous knowledge sharing—colleagues learning from each other, pairing with AI-savvy team members, sharing what’s working in real time.

And set a goal: every employee tries to use AI to solve a problem at least once per quarter. Make it a company KPI. If it doesn’t work today, things will have progressed enough to solve it next quarter. The point is to keep pushing, keep experimenting, and keep learning—because standing still means falling behind.

This isn’t a one-time initiative. It’s ongoing. The tools will keep evolving, and your people need to evolve with them.

3. Everyone Builds Their Own Agents

Here’s my most important prediction for 2026: everyone in the company—not just developers—needs to be able to build and own their own AI agents.

Not “use AI tools someone else built.” Build their own. To automate the boring, repetitive tasks that drain their time and energy, so they can focus on creating value.

The numbers back this up: knowledge workers could automate 30–70% of their current tasks with AI (McKinsey). Organizations using workflow automation are reducing operational costs by up to 30% (Gartner, 2025). And by 2026, business-user developers will outnumber professional developers 4:1.

This isn’t about job loss. It’s about job evolution. AI agents won’t take over the world—but they might take over your inbox. And that’s a good thing.

What this means for CTOs:

You need to provide three things:

1. Tools and platforms — Give people no-code or low-code tools to create and orchestrate agents. Make it easy to start, with templates and guardrails built in.

2. Training and knowledge sharing — Help people figure out what to automate and how. This isn’t a one-time workshop—it’s continuous peer learning and idea sharing.

3. Expert support — Pair business users with AI-savvy team members who can help them set things up and solve problems. Not gatekeepers—enablers.

Yes, this creates governance challenges. Yes, you’ll need guardrails to prevent a mess of ungoverned automations. But the alternative—centralizing all AI development in IT—is too slow. The companies that win will be the ones that trust their people to build, with the right support and oversight in place.

Everyone creates. Everyone owns. That’s how you scale AI across the enterprise.

The Bottom Line

The companies that win in 2026 will be the ones that trust their people to build.

Not just use AI. Build with it. Own it. Push its limits.

The landscape is shifting fast. What works today won’t work in six months. The most valuable skill isn’t mastering any specific tool—it’s constantly testing what’s now possible.

2026 won’t reward the companies with the best AI strategy on paper. It will reward the ones that move fastest, learn continuously, and put AI in the hands of everyone.

That’s the bet I’m making. What’s yours?

A Picture Paints a Thousand Flavors

It began on a lazy Sunday evening when I stumbled upon an image of the ingredients of one of the best cocktails I ever tasted. The name? Señor Smokey. The ingredients were listed right there, but the proportions? That remained the drink’s tantalizing secret.

The listed ingredients were:

• Mezcal
• Grapefruit
• Lime juice
• Falernum
• Agave
• Chocolate bitters
• Egg white
• Chilli salt

Just reading the ingredients again had my taste buds tingling. But how could I unlock the perfect blend of these flavors?

Enter ChatGPT: My Digital Bartender

With the ingredient list in hand, I turned to ChatGPT, the digital marvel by OpenAI. I fed it the list, and voila! It swiftly provided a recipe that promised a smooth, smoky cocktail sensation.

Here’s the magic potion it crafted for Señor Smokey:

1. 2 oz Mezcal
2. 1 oz fresh grapefruit juice
3. 0.5 oz fresh lime juice
4. 0.5 oz falernum
5. 0.25 oz agave syrup (you can adjust to taste)
6. 1-2 dashes of chocolate bitters
7. 1 egg white (from a fresh egg)
8. Chili salt (for rimming the glass)

ChatGPT even provided the instructions:

1. Glass Prep: Begin by rimming your glass. Wet the rim with a grapefruit or lime wedge, then dip into the chili salt to coat the rim. Set aside.
2. Dry Shake: In a shaker, combine the egg white, mezcal, grapefruit juice, lime juice, falernum, agave syrup, and chocolate bitters. Shake without ice first (this is known as a “dry shake”) to emulsify the egg white and create a foamy texture.
3. Wet Shake: After the dry shake, add ice to the shaker and shake again until well chilled. This is referred to as a “wet shake.”
4. Strain & Serve: Strain the mixture into your prepped glass. You should see a nice, foamy layer on top from the egg white.
5. Garnish (Optional): If desired, you can add a small piece of grapefruit or lime peel or wheel for visual appeal.
6. Enjoy responsibly!

The combination of ingredients you provided suggests a delightful balance of smoky, tangy, sweet, and bitter flavors with a silky texture from the egg white. The chili salt adds an extra layer of spicy kick to each sip. Enjoy your Señor Smokey!

The First Sip

With bated breath, I followed the concoction’s steps, and as I took the first sip, a smoky, tangy, sweet symphony played on my palate. The Señor Smokey was every bit as divine as I remembered!

The Power of Technology (and a Good Palate)

My journey with Señor Smokey taught me that with the right tools and a little determination, the world of mixology is right at our fingertips. Whether you’re a budding bartender, a cocktail connoisseur, or just someone who loves a good drink story, never underestimate the power of technology paired with human curiosity.

So the next time you’re eyeing a drink on social media, remember my tale of Señor Smokey. And who knows? You might just find your next favorite cocktail. Cheers! 🍹

Lean Startup and Design Sprint

In the early stages of a startup, the ability to rapidly prototype, test, and pivot is vital. The Lean Startup methodology encourages iterative development, allowing businesses to validate their ideas and learn quickly from mistakes. In parallel, running design sprints facilitates the rapid prototyping of ideas and solutions. Applying these methodologies effectively is skill that can be taught hands-on.

Tech 101 for Non-Tech Founders

The tech landscape can be daunting for non-technical founders. However, having a basic understanding of tech concepts and terminologies is crucial for the effective management of a tech-oriented business. I would provide non-technical founders with essential knowledge to bridge the communication gap with their technical team and make informed decisions.

Building a Minimum Viable Product (MVP)

The essence of a startup lies in its product. An MVP serves as the heart of a startup’s offer, allowing the company to bring a product to market quickly for user testing and feedback. I would focus on how to strategically choose features, set priorities, and leverage Agile methodology for product development.

Understanding and Implementing Agile Methodology

Agile development emphasizes flexibility, customer satisfaction, and cross-functional collaboration. Understanding and implementing Agile, including Scrum, can enhance project management efficiency and product quality. I would guide startups on how to effectively manage and plan their software development projects.

Choosing the Right Tech Stack

A startup’s tech stack is a significant determinant of its scalability, performance, and growth potential. Factors such as the startup’s industry, team expertise, and product features all play into this decision. With proficiency in AWS, Java, React, Next.js, and serverless technologies, I can guide startups on how to make the best tech stack choices to suit their specific needs.

Introduction to Data Science and AI

Data is the lifeblood of today’s businesses. Understanding how to leverage data through AI and machine learning is increasingly becoming a competitive advantage in the startup world. I would introduce the basics of these powerful technologies and show how startups can leverage them.

TL;DR

These topics were identified based on my experience in technology and leadership roles. They’re intended to equip startups with the skills and knowledge they need to develop, validate, and refine their business ideas. By instilling a robust understanding of these key areas, startups should be well-prepared to start generating revenue and scaling their models effectively.

Let me know what other topics would be essential from a tech perspective!

Asking the right questions early in the process can help you assess potential risks and make informed decisions about AI service providers. Here are ten questions to ask, along with some potential red flags to look out for:

Data Security and Privacy

Question: Is the AI service provider compliant with GDPR and other applicable data protection and privacy regulations? What mechanisms do they have in place to protect data during transmission and at rest?

What to look for: You’ll want to see evidence of robust data protection measures, such as data encryption and secure data transfer methods. Compliance with relevant regulations and standards is non-negotiable.

Data Usage

Question: Will the AI service provider have access to our data? If so, how will this access be controlled? Will our data be used to train or improve the provider’s AI models?

What to look for: Clear policies about how your data will be used and controlled are crucial. Beware of providers who might use your data to train models that could be used by competitors, which might lead to leakage of your company’s proprietary knowledge.

Data De-identification

Question: How does the provider ensure that data used to train or improve AI models is properly de-identified or anonymized?

What to look for: The provider should have robust procedures for de-identifying data, reducing the risk of data being re-identified later. If a provider can’t assure you of this, it could pose a significant risk.

Bias and Fairness

Question: What measures does the provider take to ensure that the AI models are fair and do not exhibit or perpetuate bias?

What to look for: The provider should be transparent about their methods for preventing and detecting bias in their models. AI models that are biased can lead to unfair outcomes and potential legal issues.

Transparency and Explainability

Question: How transparent is the AI model’s decision-making process? Can the provider offer insights into how the model makes decisions or predictions?

What to look for: Transparency and explainability are essential for trust and accountability. Providers should be able to explain in understandable terms how their models work.

Accountability

Question: Who is responsible if the AI service makes a decision that leads to harm or violates laws or regulations?

What to look for: The provider should be clear about accountability. If they avoid taking responsibility for their model’s decisions, that’s a red flag.

Review and Auditing

Question: Can the provider’s data handling and AI practices be audited? Does the provider have mechanisms in place for regular review and improvement of its AI practices?

What to look for: You’ll want a provider who is open to external audits and has a commitment to continual improvement.

Exit Strategy

Question: If the contract with the AI service provider ends or if the provider goes out of business, how will our data be handled? Can we easily retrieve or delete our data?

What to look for: Ensure there is a clear exit strategy that includes retrieving or securely deleting your data.

Training Data

Question: Is the data used to train the AI model ethically sourced and free of copyright restrictions?

What to look for: The provider should be able to confirm that they have the necessary rights to use the training data and that it was obtained ethically.

Quality Assurance

Question: How does the provider ensure the accuracy and reliability of the AI model?

What to look for: Look for providers with robust quality assurance processes that include regular testing and validation of their models.

TL;DR

By asking these questions and understanding what to look for in the answers, you’ll be well equipped to navigate the complex landscape of generative AI integration with data security and privacy in mind. Remember, a good AI provider should be able to answer these questions to your satisfaction, demonstrating their commitment to data security, privacy, and overall ethical AI practices.

Let me know if I am missing any essential questions!