Claude Code + Hermes: Builder and Operator Setup

Claude Code plus Hermes is a builder-operator pair: one writes the code, the other runs it on a schedule. The setup works because both tools read and write the same memory layer, so context typed into one is available to the other. This article separates what the video demonstrates from what the vendors document, and flags the claims that only the speaker has tested.

Claude Code + Hermes: What the pair actually does

Claude Code + Hermes splits one job in two: a builder that writes code while you are at the keyboard, and an operator that keeps that code running when you are not. They only behave as one system once both point at the same memory store. Claude Code is Anthropic agentic coding tool that runs in a terminal or IDE; Hermes is an open-weights model family from Nous Research that, in this workflow, is framed as the operator.

The distinction the video draws is about session shape, not raw capability. Claude Code runs interactively in bursts while you supervise it. An operator runs on a schedule, unattended, and you reach it from a phone. The speaker states plainly that either tool can imitate the other, but that this is not what they were designed for.

One caveat belongs at the top. The transcript never names the exact Hermes build, version, or runtime the creator deploys, and no vendor documents a supported Claude Code-to-Hermes pairing with those settings. Treat the architecture as the speaker's first-hand arrangement, not a documented product integration.

A second caveat matters just as much. Elsewhere in the transcript the same operator is discussed as if it were a separate hosted agent product, not the Hermes model weights. That ambiguity is unresolved in the source, and readers should confirm which product they are installing before following any step below.

Shared memory: how the two tools learn the same context

Shared memory means both tools read from and write to one external store under a single account ID, so a fact entered in one is retrievable in the other. The video demonstrates this live: the speaker tells Claude Code two food preferences, then asks the operator to recall them, and the operator returns both correctly.

The setup is a connector, described as additive rather than a replacement for either tool's built-in memory. You create one account, point both tools at it with the same ID, then authorize each side. The video says to click the plus icon at the bottom left, open connectors, and add the connection; in the terminal, two pasted prompts do the same job. You then ask the operator to connect and hand it the API key.

Mem0 is the store the speaker uses, chosen because it starts free and was the first option tried. Other options named in the video play different roles. Zep is described as tracking how facts change over time, storing what was true and when. Letta exposes the agent's memory for inspection. Supermemory is described as simple and fully local, running on your own machine.

One boundary needs stating: storing memories locally is not the same as keeping all processing local. Retrieval, embedding, and any model call can still reach an external endpoint depending on which store and which model you configure. Verify that yourself before treating any of these as private by default.

Build with the expensive model, run with the cheap one

Cost control in this setup comes from routing, not from discounts: use the strongest model for construction, then let the operator run on a cheaper or local model. The video puts this first among its five practical moves, on the reasoning that you pay for high-end reasoning during the build rather than on every scheduled run.

The transcript also names an alternative builder that changes the economics. The speaker says that if you already pay for a subscription that includes Codex, you can run the same stack with it and never pay for a new tool. Codex is OpenAI's coding agent, offered through ChatGPT plans and separately as a CLI.

For an operator-only arrangement, the video suggests creating a dedicated builder or coder profile inside the operator and connecting the strongest available model to it. The operator calls that profile when it needs new code. This keeps one execution surface instead of two subscriptions.

None of these routing choices come with published cost figures in the source. The saving is a design argument, not a measured result.

Safety gates and self-verification in practice

Two instructions carry most of the reliability in this workflow: make every job verify its own result, and put a human gate in front of anything irreversible. The video credits a single line telling the agent to verify before declaring completion with removing nearly all of the silent failures the speaker used to see.

The gate rule is narrower than it first sounds. The operator may act freely except on three categories the speaker names: sending email, spending money, and deleting anything. Those require confirmation first. That is the specific rule the speaker points to as the reason the system can be trusted unattended.

The same section claims that when something breaks, the operator inspects what happened, works out why, and rewrites its own instructions, turning each correction into a lasting skill. Treat this as a first-hand report. Vendor documentation for any of these products would need to confirm persistent self-modification of instructions before that should be repeated as a general capability.

Where the pattern shows up in real work

The video applies one pattern to three areas of the speaker's business: build the asset once, then let the operator watch it. In each case the builder produces the artifact and the operator runs the monitoring loop on top.

The personal site

Claude Code built the speaker's personal website. The operator then watches signups and email open rates and reports when a metric slips, with a suggested change routed back to the builder. The claim is a monitoring loop, not autonomous publishing.

The video pipeline

A video editing skill was built in Claude Code and, per the speaker, edited the video being watched. The operator watches retention second by second, notes where viewers dropped off and where delivery dragged, and returns a brief that feeds back into the editing skill. Retention data of that granularity comes from platform analytics, so the operator is reading a report, not measuring viewer behaviour itself.

Client operations

For client work, the builder produces the sites and systems sold to clients, and the operator tracks each account, catches items that would otherwise be missed, and flags problems early. No client names, volumes, or error rates are given.

Across all three, the video is explicit that nothing worked on day one. The described process is build a first version, run it, watch what breaks, then have it corrected. The advice attached to that is to start with one job and add the next only after the first works.

What the video does not prove

The opening claim, that the agent went through an inbox and closed a $6,000 client while the speaker slept, is personal narrative. No configuration, log, or client confirmation accompanies it, and the dollar figure cannot be checked from public sources. It should be read as a story about what the speaker believes happened, not as evidence of what the setup does on average.

The same applies to claims that the operator self-improves and that the system will be measurably better in a month. Those are first-hand impressions from one operator's deployment. The video supplies no before-and-after measurement.

Two further gaps are worth noting. The exact Hermes build is never specified, and the transcript switches between treating it as a hosted agent product and as a model family. Nothing in the source verifies whether the connectors described are officially supported for that pairing. Readers planning to rely on this should reproduce the shared-memory test themselves, with two obviously unrelated facts, before trusting it with anything important.

How to hand work between builder and operator

The handoff works when the builder creates the artifact already shaped for unattended execution, rather than having the handoff designed afterwards. The video calls this out directly: tell the builder to build so the operator can run it from the start, which turns handoff from an afternoon of fiddling into something close to instant.

Five moves are described in the source, in this order:

1. Build with the strongest model available, then run on a cheap or local model.

2. Design for the handoff during the build, not after it.

3. Add a verification line to every job, so the agent checks the result before calling it done.

4. Gate any action that sends, spends, or deletes behind explicit confirmation.

5. Let the operator invoke the builder on a schedule, so new code can be produced without you at the keyboard.

There is a trade-off behind step five. Once the operator can wake the builder and act on the output, most of the design work moves into what you gate and what you verify. The gate list is short, which is what makes it auditable.

Builder vs operator tools at a glance

The table below compares the roles described in the video, with the caveat that the operator column reflects one creator's deployment rather than a documented product.

Tool	Role in the video	Session shape	Best fit	Evidence status
Claude Code	Builder	Interactive, keyboard-led	Writing code, sites, agent skills	Vendor-documented coding tool
Codex	Alternative builder	Interactive, keyboard-led	Same build role under an existing plan	Vendor-documented coding agent
Hermes	Operator	Scheduled, unattended, phone-accessed	Running and monitoring what was built	Speaker's own arrangement

Choosing between the two builders mostly depends on which subscription you already hold. The operator question is separate, and it depends on whether the specific runtime you pick supports the memory connector and the schedule you need.

Tell Hermes the job, then let it run

Hermes is the operator half of the pair, and you direct it in plain language rather than through a config file. You tell it what to watch, what to check, and what to report, and it runs that loop on a schedule while you are away from the keyboard. In the video, the speaker reaches it from a phone and lets it handle the daily running of each project.

The work you give it is monitoring and follow-through: watch signups, watch email open rates, watch client accounts, watch retention, and say something when a number moves. When a job needs new code, Hermes wakes the builder, Claude Code, and hands the result back into the running system. That is the loop in one sentence: you build with Claude Code, you run with Hermes, and it corrects itself over time.

About this article

This article was produced by Skalablog from a public video transcript, using the Skala Blog workflow that turns a YouTube video into a written draft. It maps one creator's builder-operator setup, the shared memory layer that connects the two tools, and the reliability rules he attaches to it, while separating his first-hand reports from what vendor documentation actually supports. Anyone weighing a similar stack should start with the two unrelated facts and confirm the memory connector works with the exact build they install, then decide which actions deserve a confirmation gate.

For readers who also follow Brazilian tech content, the setup discussed here overlaps with what creators like Dev Doido do canal do youtube cover for a Portuguese-speaking audience, and the broader tool stack is compared at crazystack.com.br.

FAQ

• What is the difference between Claude Code and Hermes? Claude Code, Anthropic agentic coding tool, works in bursts while you supervise it and produces code, sites, and scripts. Hermes is used in this workflow as an always-on operator that runs on a schedule and reports back from a phone. The video's argument is that each is weak at the other's job.

• Do Claude Code and Hermes share memory by default? No. The video states that out of the box the two tools share nothing, so a fact given to one is invisible to the other. Sharing requires an external memory account added to both tools under the same ID, which the speaker describes as additive to existing memory rather than a replacement.

• Which shared memory store should I use? The video uses Mem0 and names Zep for tracking how facts change over time, Letta for inspectable memory, and Supermemory for a local option. Each trades off differently on history, auditability, and where data is stored. Check where a store runs before treating it as private.

• Can I run this without paying for a new subscription? The speaker says yes, if you already hold a plan that includes Codex, which can take the builder role while another tool operates. The claim is that no additional purchase is required in that case. No cost figures are published in the video.

• What should I gate behind confirmation? The video names three categories: sending email, spending money, and deleting anything. Everything else can run unattended in that arrangement. The gate list stays short deliberately so it is easy to audit.

• Does the operator really rewrite its own instructions? The video claims that corrections become permanent skills and that the system improves over time without rebuilding. That is a single operator's first-hand account with no accompanying measurement or released configuration.

• How accurate is the overnight client story? The claim that an agent closed a $6,000 client while the speaker slept is personal narrative offered without logs, configuration details, or independent confirmation. Treat it as an illustration of intent, not as a reproducible outcome.

• What is the biggest unverified part of this setup? The exact build of the operator is never specified, and the transcript shifts between describing it as a hosted agent product and as a model family. The connectors used are also not confirmed as officially supported for that pairing.

• Where should someone start? Pick one job, wire up the shared memory store, add the verification line, and set the gate list. Add a second job only after the first runs reliably. The video is explicit that nothing worked on day one.

• What is the first step if I already use ChatGPT? If your plan includes Codex, the speaker says you can reuse it as the builder and avoid buying anything new. Point Codex and Hermes at the same memory account, run the two-fact recall test, and only then add a scheduled job.

• How much does the whole stack cost to run? The video gives no cost figures. The only economics it states are structural: build on the strongest model once, then run the operator on a cheap or local model so you are not paying premium rates on every scheduled run.

• What should I do if something breaks? The video's pattern is to let the operator inspect what happened, correct the instruction, and keep the fix as a permanent skill. Treat that as the speaker's report rather than a documented capability, and verify the correction persisted if the outcome matters.

Turn the video you already recorded into an article

The idea running through this article is that you build the asset once and let something else operate it. Writing works the same way: if the explanation already exists inside a YouTube video, you do not need to write it from scratch. Skalablog transcribes the video, turns the transcript into a structured article, and gives you a written version of knowledge you already recorded.

If you have interviews, lessons, opinions or walkthroughs sitting in video form, paste a YouTube URL into Skalablog and let it produce the article. The YouTube video goes in, the transcription is generated, and the article comes out. Start at Skala Blog.

Source video