0 · What Problem Each System Is Solving

The previous two articles covered the architecture of Claude Code and Hermes, each on its own. This one does exactly one thing: it puts them side by side and looks at two answers to the same question.

0.1 Each in Two Sentences

0.2 “Is the User Present?” Is Where Every Disagreement Starts

The last row of that table is the key to every difference between the two systems.

0.3 Where the Weight Is, by Code Volume

Look at the single largest file in each system and you can see directly where the effort went:

0.4 How This Article Is Organized

0.5 A Warning: Don't Copy

1 · Mechanism by Mechanism

This chapter takes four core problems and looks at how each system answers them. Every section follows the same shape: what the problem is → the two solutions → where the difference comes from.

1.1 Context Management

The problem

A large language model has a “context window” — there is a hard limit on how much text it can look at in one go. The longer the conversation, the more of it is used up, until nothing more fits. And every turn re-sends the entire history, so long context isn't just “it will fill up” — it's “every turn burns money.”

Claude Code: a five-rung ladder

The point of the five rungs is that each rung loses more information and costs more to run than the one before it. The system always starts with the gentlest tool and only escalates when that isn't enough.

On top of this there's a private Anthropic capability, cache_edits: delete specific content from the cache server-side while the local message list stays completely untouched. This lets “compaction” happen without breaking the prompt-cache prefix — a capability outside developers can't get.

Hermes: a pluggable engine

class ContextEngine(ABC):        # a 490-line abstract base class
    def should_compress(...)      # abstract: is it time to compress?
    def compress(...)             # abstract: how to compress
    def select_context(...)       # abstract: which messages to send this turn

Hermes doesn't prescribe a compaction strategy; what it prescribes is “what a compressor has to look like.” It ships a default implementation called compressor, and you can swap in your own through config.

It also splits the action into two orthogonal verbs:

Where the difference comes from

1.2 Permissions and Safety

The problem

An agent runs commands, edits files, and makes network requests. How do you stop it from doing irreversible damage?

Claude Code: a 10-step cascade

Every tool call goes through a 10-step decision chain. The most important design element is “bypass immunity”:

Hermes: red lines + environment isolation

The first layer is 12 hard-coded red lines (HARDLINE_PATTERNS), backed by a fairly sophisticated parser:

The second layer is the execution environment: 7 backends (local / Docker / Modal / Vercel / Daytona / Singularity / SSH). This is the only true hard boundary — every rule above is “guessing whether this command is dangerous”; only isolation is “even if it is, it can't get out.”

Where the difference comes from

1.3 Multi-Agent

Claude Code: three forms

Those 4 fork-caching tricks deserve a separate mention: for the subagent's request prefix to be identical to the parent's byte for byte, the system has to guarantee that the system prompt, tool definitions, tool ordering, and message serialization are all exactly the same. A single differing byte invalidates the whole cache and multiplies the cost several times over.

Hermes: delegation + kanban

MAX_DEPTH = 1                          # only one level allowed
_DEFAULT_MAX_CONCURRENT_CHILDREN = 10  # at most 10 concurrent
_RECENT_SUBAGENTS_CAP = 200            # cap on the history record

Plus runtime controls: interrupt_subagent (interrupt) / steer_subagent (inject instructions) / set_spawn_paused (stop spawning but let the existing ones finish).

The other mode is kanban: several peer agents share one task board and each claims work from it. Paired with the kanban_heartbeat heartbeat — a task that was claimed and then died automatically goes back to unclaimed.

Where the difference comes from

1.4 Extension Mechanisms

A pattern both use: progressive disclosure

1.5 One-Page Cheat Sheet

2 · The Consensus They Reached Independently

The last chapter looked at differences. This one looks at something more valuable: two teams, two languages, two sets of goals — and the conclusions they arrived at independently that turned out to be the same.

Consensus 1 · Context Is the Scarcest Resource

Not compute, not storage, not network. How much text the model can look at in one go.

Consensus 2 · Progressive Disclosure

A direct corollary of Consensus 1, but worth listing on its own, because it applies far more widely than you'd expect.

Pattern: catalog resident (cheap) + contents on demand (expensive, but you pay only when needed)

Claude Code uses it for: tools · skills · MCP · memory directory · file reads
Hermes      uses it for: toolsets · skills (81) · memory prefetch · environment output

And both sides found the same secondary conclusion: “the quality of a catalog entry's description decides everything.” Because that is the only information the model has for deciding “do I need to expand this one?”

Consensus 3 · Safety Must Be Layered, and No Layer Is Reliable

Consensus 4 · The Default Must Be “Fail Closed”

“Fail-closed” means: when the system isn't sure, it refuses rather than allows.

The Hermes v1 → v2 evolution is especially telling: in early versions the memory checkpoint was “best effort” (if it failed, skip it and keep going). Later an explicit version number was added, PRE_COMPRESS_CHECKPOINT_API_VERSION = 2, and the v2 semantics are “if it fails, abort the compaction.” That is a deliberate correction from fail-open to fail-closed.

Consensus 5 · Kill a Whole Class of Problems With a Hard Limit

Consensus 6 · Abstract “What to Do,” Query “What Can You Do,” Never Ask “Who Are You”

Both sides independently use this pattern in several places:

// Hermes platform adapters
adapter.supports_threads()      instead of  if platform == "slack"
adapter.supports_reactions()
adapter.supports_editing()

// Hermes model providers
provider.supports_prompt_caching()   instead of  if provider == "anthropic"

// Claude Code tool capability groups
tool.isConcurrencySafe()        instead of  if toolName == "Read"
tool.isReadOnly()

Consensus 7 · Errors Must Be Classified, Because Different Kinds Need Different Strategies

Consensus 8 · Claim-Type Operations Need a Lease

Both sides independently ran into, and solved, the same distributed-systems problem:

2.9 The Eight Points on One Page

3 · The Cost of Every Choice

The first two chapters covered differences and consensus. This one covers something that gets talked about far less: what each design choice gave up.

3.1 What Claude Code Pays

Cost 1 · A fixed context strategy you can't swap out

A concrete example: the “snip” rung drops the oldest tool results first. In a coding scenario that's usually fine (a file you already read can be read again when needed). But if your scenario is a long-lived, stateful conversation (say, a project-management assistant that runs for weeks), the oldest information may be exactly the most important constraint.

Cost 2 · The double edge of compile-time feature flags

89 feature() flags + dead-code elimination
→ a disabled feature is [physically absent from the binary]

Cost 3 · A single form of entry

Claude Code is a terminal tool. It has 4 launch forms, but all of them live in the terminal. No chat-platform integrations, no webhooks, no scheduled tasks.

What that buys: the entire interaction design can assume “there is a TTY, a human is watching, ANSI escape sequences work, Ctrl-C works.” The 347 KB input-box component can exist precisely because it only has to serve one kind of terminal.

Cost 4 · Closed source

3.2 What Hermes Pays

Cost 1 · The weight of the abstraction layer

ContextEngine abstract base class:  490 lines of interface definition
Built-in compressor implementation: 419 KB

→ Interface-to-implementation ratio: 490 lines : 419 KB

Cost 2 · Insecure by default

Cost 3 · The ongoing maintenance burden of 22 platforms

There's a related hidden cost: testing. Each of the 22 platforms needs a real test account, test workspace, and test credentials. Full regression testing is extremely expensive and very likely infeasible in practice.

Cost 4 · Python's distribution problem

296 MB sounds big, but what it buys is “one file, double-click, it runs.” And anyone who has ever shipped a Python application knows how often you hear “it works on my machine.”

3.3 Costs Both Sides Share

Shared cost 1 · Complexity is irreversible

Shared cost 2 · Heavy dependence on model behavior

Both systems write lots of “you must do it this way” constraints into their prompts:

• Claude Code's “three laws of thinking,” and the “do not call any tool” rule during compaction (every tool named exhaustively, plus the consequences spelled out)
• Hermes's injection detection, and its skill-description matching

Shared cost 3 · The cost of observability

Claude Code has 660 event types and 1,093 instrumentation points. That code has to be written, maintained, and kept in sync during refactors. Hermes has an event system, a delivery ledger, skill-usage statistics, and execution history.

But this is a cost that must be paid — because agent systems fail mostly by “behaving wrong” rather than “throwing an error,” and without instrumentation there is no way to investigate at all.

3.4 Cost Comparison Summary

4 · How to Choose When You Build Your Own

This chapter turns everything so far into decisions you can act on. Not “which one to learn from,” but “under your constraints, which design is right.”

4.1 The First Question: Is the User Present?

This is the dividing line. Answer it first and half the remaining decisions settle themselves.

4.2 The Second Question: Is the Workload Uniform or Varied?

4.3 The Third Question: Who Will Extend It?

4.4 Eight Things You Must Do Whichever Road You Take

This is the action version of the eight consensus points from Chapter 2:

4.5 The Interview: How to Talk About All This

4.6 Finally: A Decision Framework You Can Take With You