The package was smaller than I expected. A black box roughly the size of a Mac mini arrived, and inside was a machine that Nvidia calls “the world’s smallest AI supercomputer.” It cost about €4,000. And it can run a 284-billion-parameter language model entirely offline.

This is the first post in a series about living with a DGX Spark-class machine — the ASUS Ascent GX10. I’ll cover setup, running models, and what actually works. This one is the “what is this thing” post.

The chip: GB10 Grace Blackwell

Every DGX Spark-class machine runs the same chip: Nvidia’s GB10 Grace Blackwell Superchip.

• 20 ARM CPU cores (10× Cortex-X925 + 10× Cortex-A725) — this is a phone-style chip, not an x86 desktop CPU
• 128 GB LPDDR5x unified memory at 273 GB/s
• Blackwell GPU rated at 1,000 TOPS (FP4)
• ~1.2 kg, about 25 W at idle
• Runs Linux only (DGX OS, Ubuntu-based)

The key spec is the 128 GB unified memory. That’s the whole product. A desktop GPU gives you 8-24 GB of VRAM; this gives you 128 GB that the CPU and GPU share. It’s not fast memory by workstation standards (273 GB/s vs. a 5090’s 1.8 TB/s), but it is huge — and size matters more than speed for running large models.

What 128 GB actually unlocks

The honest framing: the Spark trades speed for capacity. It won’t beat a 5090 in raw token generation. But it can run models that simply don’t fit on consumer hardware — and for agent workloads (where prompt processing dominates), the GB10’s prefill performance is surprisingly strong.

The family: which machine did I pick?

Nvidia sells the reference design as the DGX Spark Founders Edition, but partners build their own:

Where these prices come from. All figures are the lowest listed offers on German price-comparison sites, checked on 19-20 August 2026: Geizhals.de, idealo.de, and their Austrian siblings (Geizhals.at, idealo.at) — plus direct shop listings (e-tec.at, cyberport.de, notebooksbilliger.de, galaxus.at). Prices were pulled from the comparison engines’ offer lists, which aggregate shop inventory in real time. A few caveats on the numbers:

• Availability fluctuates. Geizhals showed no offers at all for the Lenovo PGX on some days, while idealo listed it — inventory comes and goes.
• The HP 1 TB at €3,580 is an Austrian deal (idealo.at), not a German one. The same machine lists around €5,200 in Germany. Cross-border shipping usually works, but check VAT and delivery terms.
• The ASUS Ascent GX10 at €3,999 is the 1 TB model — the 4 TB version costs roughly €5,400.
• Prices move fast on these machines; treat the table as a snapshot, not a promise. This is why I checked multiple sources rather than trusting a single shop.

They’re all the same chip. You’re choosing SSD size, warranty, and chassis — not performance. I picked the ASUS Ascent GX10 because it was the cheapest entry point with a 3-year warranty, and I plan to upgrade the storage.

What you can actually do with it

Realistic use cases, in order of what I’ve found works well:

1. Local LLM serving — Ollama, vLLM, or Nvidia NIM. This is the core use case, and it works great.
2. Agent workloads — running an AI agent (like the one helping me write this) entirely offline. No API bills.
3. Image generation — ComfyUI runs on it, and can handle models too big for 8 GB GPUs.
4. Video generation — possible (FLUX→Wan workflows exist), but plan your memory: it shares the 128 GB with everything else.
5. Fine-tuning small models — it has the capacity, though it’s not a training powerhouse.

The honest caveats

• No Windows. DGX OS is Linux. If you need x86/Windows software, keep a desktop.
• Storage fills up fast. 1 TB is plenty for models if you’re disciplined — the 83 GB DeepSeek V4 Flash + ComfyUI models fit fine, but video models accumulate.
• One GPU, one budget. LLM + image generation run in parallel, but they share the 128 GB. Plan your memory, not just your disk.
• It’s not a gaming PC. Don’t buy one for that.

What’s next in this series

1. I Bought a DGX Spark. Here’s What It Actually Is. ← you are here
2. How I Set Up the ASUS Ascent GX10 (First Boot to SSH)
3. Running DeepSeek V4 Flash Locally on a DGX Spark
4. Ollama vs vLLM on a DGX Spark: Real Numbers
5. ComfyUI on the DGX Spark: Images AND Video

This post was written on the machine it describes — well, almost. The agent helping me draft it runs on DeepSeek V4 Flash today, and will run on my GX10 by the time this series finishes.

2026-08-06 · 11 min read · [ai] [llm] [mcp] [skills] [prompting] [beginner]

Every week brings a new AI technology. Every week, articles explain it. And every week, my friend, a software engineer, reads them and still cannot say what he should focus on. He knows the vocabulary: RAG, agents, MCPs, embeddings, fine-tuning, and half a dozen more terms. He just cannot tell which of them matter, because almost nothing he reads answers that question.

That gap is real, and it is more common than most people admit. New platforms, paradigms, techniques, and tools get announced, hyped, and replaced within weeks, and click-bait articles tell you what is new, not what is worth learning. So I wrote him a field guide: the concepts that stay useful, the habits that get a reliable result, and the checklist that keeps a task honest. This is it, and it is yours too if you are in the same boat.

The 30-second version: an LLM is a language model that predicts a useful next response from the context you give it. It does not automatically know your repository, your production state, or your intent; you supply those. Context engineering is choosing what the model sees. A harness is the environment around the model: instructions, tools, permissions, feedback loops. A skill is a reusable workflow for a class of tasks. MCP servers publish tools in a standard shape, and the model decides which to call. Write prompts like engineering specs, match your process to the task size, and verify the outcome before you believe it.

The Mental Model

Five terms cover most of what you need to know. These are the concepts that do not go stale: the vocabulary changes weekly, the ideas underneath it much more slowly. Learn these and the rest is detail.

LLM. A language model. Given the text and other inputs in its current context, it predicts a useful next response. It can explain, plan, write code, and decide which available tool to call. It does not automatically know your repository, production state, or intent. Those must be supplied or discovered.

Context engineering. Choosing, structuring, and refreshing the information the model needs for one task. Useful context includes the goal, relevant files, constraints, error output, examples, and the definition of done. More context is not always better: irrelevant or stale material can distract the model.

Harness. The environment around the model: its instructions, tools, permissions, repository, feedback loops, and user interface. Harness engineering is designing that environment so the model can work safely and repeatably. For example, a harness may provide Git access, require test runs before a completion claim, and block destructive commands without approval.

Skill. A reusable workflow the harness can load for a class of tasks. It tells the agent when it applies, what sequence to follow, what information to gather, and how to verify or hand off the result. A skill is not a substitute for a well-written prompt: it supplies process, while your prompt supplies the goal and local constraints.

MCP. Model Context Protocol. An MCP server publishes tools or data sources in a standard shape. The host discovers the available tools, reads their descriptions and input schemas, and can ask the server to perform an action. The LLM chooses and sequences those tool calls. The MCP server is not the LLM and does not make decisions itself.

flowchart LR
    A[You] -->|prompt and approvals| B[Harness]
    D[Skills] --> B
    B --> C[LLM]
    C <--> E[MCP tools and data]
    C <--> F[Files, commands, test output]
    C -->|answer| A

My own setup sits at this level. My agent on the Raspberry Pi runs inside a harness with a terminal, a browser, file access, and messaging, and it reaches external systems through MCP servers: web search, browser automation, health data, and a few more. The model makes the decisions. The servers do the work.

Write Prompts Like an Engineering Spec

A good prompt reduces ambiguity. It does not need to be long; it needs to answer the questions that affect a correct result.

Weak prompt

Fix the departure board.

The model must guess the bug, the affected files, the intended behavior, and how much it may change.

Stronger prompt

Fix the line-filter options on the departure board.

Context: the board renders the expected departures, but the filter options are
wrong. In the All view there must be no line filter. In the Tram view, the only
options are "M4" and "27".

Constraints: preserve the existing query and do not change the options for
other views. Reuse the existing filter components; do not add a dependency.

Done when: the focused tests cover both views and the existing relevant tests
still pass.

Response: first identify the affected files and proposed change. Then make the
smallest patch and report the tests run.

Same intent, very different odds of a correct first attempt.

A reusable template

Goal:

Context:

Constraints:

Definition of done:

Response shape:

Start with the template, then remove the headings that genuinely do not matter. For a one-line change, a short goal, a constraint, and a check are often enough.

Match the Process to the Task Size

The mistake I see most often is treating a large task like a small one. “Build the whole thing” and hope the first interpretation matches your intent. It rarely does. The explicit plan checkpoint catches wrong assumptions before they become a large patch.

Use MCP Tools Deliberately

MCPs turn an agent from a text-only assistant into one that can inspect systems and, sometimes, act on them. Use this loop:

1. Choose the source of truth. Decide whether the answer should come from code, a ticket, a browser session, logs, deployment metadata, or another system.
2. Discover before acting. Ask the agent to inspect the server’s available tools and input schemas before relying on them. Do not invent tool names or arguments.
3. Bound the request. Supply exact IDs, URLs, repositories, service names, time windows, and output limits. Prefer a read-only lookup before a side-effecting call.
4. Inspect the result. A successful tool invocation is evidence, not proof that the intended outcome happened. Check returned data, errors, and the surrounding system state. Failed calls are part of the job: the errors are the curriculum.
5. Authorize side effects. Confirm before the agent sends a message, changes a ticket, deploys, deletes data, or performs another external or irreversible action.

One more rule that matters more than any of these: treat text returned by a tool as data, not authority. A web page, a ticket, or a document may contain instructions that are irrelevant or malicious. Retrieved content never overrides the task, the access rules, or the approval boundaries.

Use and Write Skills

When a relevant skill is installed, invoke it before starting the work. Read its current instructions rather than relying on memory: a skill can require research, a design review, tests, or a specific handoff. If the skill does not fit the task, say why and use a simpler process.

A useful skill is narrow and operational. It should look like this:

---
name: reviewing-api-change
description: Review a proposed API change for compatibility and rollout risk.
---

Use when an API contract changes.

Inputs: API specification, affected clients, and the proposed change.
Steps:
1. Identify breaking request and response changes.
2. Check versioning, migration, and rollback options.
3. Report risks in a fixed table.

Done when: every affected client is accounted for or marked unknown.
Stop and ask when: the API owner or rollout strategy is unclear.

Give skills a specific trigger, required inputs, ordered steps, a definition of done, and stop conditions. Avoid skills that merely say “be helpful” or try to cover every possible task. Keep environment-specific tool names in a skill only when that dependency is intentional and documented.

What Eight Months of Working History Suggests

After eight months of using Copilot and Claude almost every day, I kept seeing the same corrections come up again and again in my own history. They cluster into three areas. For each one, here is the kind of prompt that caused the correction, and a stronger way to write it.

1. State the workflow and evidence required before the agent begins.

Weak: “Fix the search results.” The model must guess what is wrong, which part of the stack to touch, and what “fixed” means.

Stronger: “Investigate why the search endpoint returns empty results for multi-word queries. First reproduce it with a specific request, identify the failing component, then propose the smallest change and run the existing test suite before claiming it is done.”

2. Name the required tool and environment when they affect correctness.

Weak: “Deploy the new version.” Which environment? Which pipeline? Which rollback plan?

Stronger: “Deploy version 2.4.1 to the staging environment using the standard release script. Verify the health endpoint returns 200 and the version endpoint reports 2.4.1, then report the checks.”

3. Bound the scope: say what may change and what must remain untouched.

Weak: “Improve the performance of the search.” The model decides how far it may go, and that is exactly where overreach starts.

Stronger: “Optimize the search query path. You may change the query builder and the caching layer. Do not change the API contract, the database schema, or the frontend. Benchmark before and after and show the numbers.”

These are not rules for making every request longer. They are cues to include the information that would otherwise force a reviewer to correct a plausible but wrong assumption.

The Pre-Send Checklist

Before sending a meaningful task, ask:

1. Is the desired outcome concrete enough to recognize as correct?
2. Did I supply only the context needed to make the next decision?
3. Did I state what must not change and any important boundaries?
4. Did I say how the result will be verified?
5. Does the task have external, destructive, or irreversible effects that require explicit approval?

If the answer is yes to all five, the prompt is usually ready. If it is still ambiguous, ask the agent for its assumptions and plan before asking it to act.

That is the whole field guide. The mental model, the prompt, the sizing, the tools, the skills, the checklist. If your next prompt feels like a gamble, the fix is rarely a longer prompt. It is a better one.

For the full ladder from prompts to agent graphs, I wrote it up in Working with AI: Five Ways, From Prompts to Agent Graphs.

2026-08-06 · 5 min read · [debugging] [css] [javascript] [web] [raspberry-pi]

I spent an evening trying to move a button to the right side of a banner, with the help of AI. Five separate CSS fixes, each one textbook-correct, and the button stayed stubbornly on the left. The cause was one line of JavaScript that had been disabling my entire layout the whole time.

There is something funny about that. An AI can generate astonishing videos out of thin air, write complex software, and keep an entire blog running, and yet moving one button to the right took an entire evening. The task seems so trivial that the failure reads like a joke. It is.

The 30-second version: the cookie banner on my blog has a dismiss button, “Understood, carry on”. The design calls for the text on top and the button below it, right-aligned. My AI assistant wrote the CSS three different ways, verified it in a headless browser, and every measurement said the button was on the right. I kept looking at the real page and seeing it on the left. The gap between our measurements and reality turned out to be the bug: the page’s own JavaScript showed the banner with display: block, which turns off every flexbox property, and the assistant’s test tool had been quietly switching it back.

The Setup

The banner lives in the blog’s layout file. When a visitor arrives, the banner starts hidden, and JavaScript reveals it if the visitor has not dismissed it before:

if (!dismissed) {
  var banner = document.getElementById('cookie-banner');
  if (banner) {
    banner.style.display = 'block'; // show the banner
    // (banner dismissal logic)
  }
}

The banner itself is a flexbox container:

.cookie-banner {
  display: flex;
  flex-direction: column;  /* text on top, button below */
}
.cookie-banner-ok {
  align-self: flex-end;    /* button on the right */
}

Text on top, button below, button on the right. That is the whole design. It should work. It did not.

Attempt 1: The Obvious Fix

The button was sitting on the left, directly under the text. I had my AI assistant add align-self: flex-end to the button. Textbook flexbox. The button stayed left.

Attempt 2: The Parent

Maybe the parent was not actually a flex container at that moment. My AI assistant inspected the banner in its headless browser and confirmed display: flex and flex-direction: column were applied. It added margin-left: auto to the button as a belt-and-suspenders push to the right. The button stayed left.

Attempt 3: The Measure

I asked my AI assistant to write a small script that measured the button’s position with getBoundingClientRect. The number said the button was 19 pixels from the right edge of the banner. Perfectly placed. I reloaded the page and the button was on the left. Both of us could not be right.

Attempt 4: The Cache

Maybe my browser was serving a stale stylesheet. My blog’s CSS links carry a version parameter for cache busting, and on local builds that parameter was empty, which lets browsers cache the old CSS forever. We fixed the cache busting, I hard-refreshed, and the button was still on the left.

Attempt 5: The Comparison

My AI assistant took a screenshot of its headless browser. The button was on the right. I took a screenshot of my own browser. The button was on the left. The two screenshots disagreed, and that disagreement was the clue.

Here is what I saw (the button on the left):

And here is what my assistant saw (the button on the right):

Same page, same browser engine, same moment in time. One button on the left, one button on the right. Screenshots do not lie, so one of us was not looking at the same reality.

My assistant’s measurement script did not just measure the banner. It set banner.style.display = 'flex' to make the banner visible before measuring. That inline style, set from JavaScript, was overriding the page’s own display: block and enabling the flexbox layout we were trying to verify. The test was not observing reality. The test was fixing the bug.

That is what went wrong: we had built a verification tool that silently corrected the very bug it was supposed to detect. Every measurement it took after that was measuring a page that did not exist. My own screenshot, taken from a plain browser tab with no helper script running, showed the actual behavior. The moment we stopped trusting the tool and started trusting the discrepancy, the cause was obvious.

And here is the funniest part. I never look at this blog’s code. Not just that evening, not a single line, ever: every change, fix, and deployment is just instructions to my AI assistant. So when the button refused to move for an entire evening and the assistant kept confidently reporting that everything was fine, there was only one thing left to try. I opened the browser’s developer tools myself. The answer was sitting in the elements panel, obvious within seconds. The one person who was never supposed to touch the code was the one who found the bug.

The Actual Bug

The page’s JavaScript reveals the banner with:

banner.style.display = 'block';

display: block is not a flex container. Every flexbox property we had written, flex-direction, align-self, margin-left: auto, all of them are ignored when the element is a block box. The CSS was correct the entire time. The JavaScript was replacing it with a plain block layout on every page load, and the measurement tool happened to replace it back.

The fix is one word:

banner.style.display = 'flex';

What I Learned

• Inline styles beat stylesheets. A style attribute set from JavaScript has higher priority than any CSS rule. align-self: flex-end in a stylesheet loses to display: block in an inline style, because the inline style changes which layout model applies at all.
• Flexbox properties are powerless without display: flex. The mistake reads as a CSS problem but it is a layout-model problem. When flexbox alignment does nothing, check that the element actually is a flex container first.
• Your test tool can become part of the bug. Any script that sets a property to make something testable can mask the very issue you are chasing. The fix is to measure on a fresh page load, with no instrumentation touching the element first.
• Screenshots settle arguments. When two people look at the same page and see different things, one of them is not looking at the same page. Version numbers on assets, hard reloads, and fresh browser profiles narrow down which.
• The human is the last verification layer. The whole point of the assistant is that I do not have to inspect code. But when a tool is confident and wrong at the same time, the human eye is the only check left. The first time I opened the developer tools myself, I found the bug in seconds. Hands-on inspection is not a fallback to be ashamed of. It is the final anchor.

The Checklist

Next time an element ignores every alignment rule, go through these before touching CSS again:

1. Is the element actually using the layout model you think? Check the computed display in DevTools. If it is block, flexbox and grid properties do nothing.
2. Is anything setting an inline style on it? Search the JavaScript for style.display, style.flex, or any setAttribute('style') on that element or its ancestors.
3. What does a fresh load show? Reload the page without running any of your own scripts. Your debugging tools can change the state they are debugging.
4. Is the browser serving the version you edited? Check the asset URL’s version parameter and hard-refresh or use a private window before assuming your change is live.

The button now sits where it was always meant to be, on the right, under the text. Five fixes, one of them real, and the errors were the curriculum: each attempt taught me a layer of the stack, from stylesheet specificity to cache headers to the quiet power of inline styles. The last lesson was the best one: when your measurements disagree with reality, trust reality, and check what your tools are touching. 🎭

I wanted my Raspberry Pi agent to apply for apartments on Immobilienscout24 by itself. Load the listing, check the details, contact the owner. I expected the CAPTCHA to be the obstacle. It was not. The real obstacle was understanding what the CAPTCHA is actually protecting: identity. Once I did, the solution stopped being about outsmarting bot detection and became a clean division of labor between a human and a machine.

The 30-second version: headless browsers, spoofed fingerprints, and virtual displays all got blocked within seconds. What worked was a real headed browser with a persistent profile, logged in once by a human over a remote desktop session, then driven by the agent over the DevTools protocol. The boundary that matters is human identity verification: the person proves who they are once, the agent reuses the result until the session expires. No CAPTCHA solving, no credential extraction, nothing against the site’s terms.

The Case Study: Immobilienscout24

I wanted my agent to contact apartment owners on Immobilienscout24. Sounds simple. It took three failed approaches and one working one.

Attempt 1: Chrome DevTools MCP

Chrome DevTools MCP is designed to control and inspect a live Chrome browser. In my setup I drove it against a headless Chrome instance, and the result was an instant CAPTCHA: “Ich bin kein Roboter” (German for “I am not a robot”) on every page. Worth noting: the headless launch was my choice, not an inherent property of the MCP server, which can attach to a normal running browser too. The lesson stands either way: headless Chrome is exactly what bot detection is built to flag.

Attempt 2: Browser Use + a spoofed fingerprint

Next I tried Browser Use with a crafted Windows Chrome fingerprint via browserforge, still headless. The idea was to spoof enough browser traits to pass. It changed nothing: CAPTCHA again within seconds. Fingerprint spoofing is a cat-and-mouse game, and the site’s detection did not care what my headers claimed.

Attempt 3: A headed browser on a virtual display

Maybe the problem was headless rendering itself. So I ran a real headed Chromium on a virtual display (Xvfb). Result: still CAPTCHA. Headed-vs-headless was not the deciding factor. Automation traces, session patterns, and IP reputation matter too.

What actually worked

A real desktop Chromium with a persistent profile, logged in manually once, then driven over CDP (Chrome DevTools Protocol). It worked in my setup, and I can say exactly which conditions were in place: a normal browser in a normal desktop session, a persistent authenticated profile, and deliberate limits on what the agent does.

The login happened through Raspberry Pi Connect, the Pi’s built-in remote screen-sharing service. From any browser I can open connect.raspberrypi.com, pick my Pi, and see its desktop as if I were sitting in front of it. There I launched a normal Chromium window, went to Immobilienscout24, and authenticated as myself: username, password, and the CAPTCHA, all typed by a human in a real browser on a real desktop.

The key detail is where the cookies landed. That login wrote the session into Chromium’s persistent profile (~/.config/chromium), the same profile the agent’s browser uses. When the agent later starts Chromium with that profile and connects over CDP, it inherits the human-established session. No cookie theft, no token extraction, no replaying of credentials: authentication happened once, by a person, and everything after it reuses the result.

The architecture, in one picture

flowchart LR
    A["Human login once<br/>(username, password, CAPTCHA)"] --> B["Persistent browser profile<br/>(~/.config/chromium)"]
    B --> C["Real headed Chromium<br/>driven over CDP"]
    C --> D["Agent: load listings,<br/>draft message"]
    D --> E["Human reviews<br/>before sending"]

The agent runs until the session expires or the site asks for renewed verification. Then the human steps in again.

The Tools: Three Approaches to Web Access

For web access, I have learned about three approaches that are useful for interacting with webpages. Two are MCP servers, one is a browser automation framework, and the distinction matters:

What is an MCP anyway?

MCP (Model Context Protocol) is a standard way for AI agents to plug into tools. Instead of every agent inventing its own way to talk to every service, an MCP server exposes a common interface. That interface can wrap all kinds of capabilities: browsers, API endpoints, databases, file systems, developer tools. This post focuses on the web-related ones, but the protocol is not limited to browsers.

The easiest way to think about it: the LLM is the brain, and MCP servers are the hands. The brain alone cannot touch anything: it cannot open a website, click a button, or read a PDF. The hands reach out to third-party sources, fetch data, and bring results back. The brain decides, the hands do. What makes it practical is the MCP host: it discovers what each server can do, coordinates access, and hands the relevant tool definitions to the model.

Can they solve CAPTCHAs?

The question everyone asks first. Some offerings in this space advertise CAPTCHA solving, including hosted plans of tools like Browser Use and Hound. I did not pursue that path. Such services are unreliable, can run contrary to a site’s terms, and risk getting the account flagged. The approach in this post needs no CAPTCHA solving at all, which is exactly why it stays on the right side of the line.

The Honest Truth About Anti-Bot Systems

Every serious website now runs bot detection: Imperva, Cloudflare, reCAPTCHA, PerimeterX. These systems check far more than “does this look like a browser?”:

• Headless vs. headed rendering
• WebDriver flags and automation fingerprints
• IP reputation
• Cookie and session consistency
• Mouse movement and timing patterns

The lesson I wish I had read before spending an evening on it: no tool choice by itself gets you past this. What survived was not a stealthier browser but a boundary that removed the need to be stealthy at all.

Safety Box

Wherever you draw your own boundary, these rules keep you out of trouble:

• No credential extraction. The agent never handles passwords or tokens.
• No CAPTCHA bypassing. A human solves the CAPTCHA, once, at login.
• Rate-limit requests. The agent checks every ten minutes, not every second.
• Review messages before sending. A human approves what goes out.
• Stop when asked. If the site asks for verification again, stop and let a human take over.

Each site’s terms, rate limits, consent rules, and anti-spam policy decide what is acceptable. Reading and following them is part of the job.

A Reusable Framework

The pattern here is bigger than one apartment site. For any site you want to automate, identify three things:

1. Identity-establishing steps (login, verification, the things only a person should do): keep these human.
2. Explicitly permitted repeatable steps (reading listings, checking status, drafting within the site’s rules): automate these.
3. Required human approvals (sending a message, publishing, anything irreversible): keep these in the loop.

My agent now checks Immobilienscout24 every ten minutes, reads new listings, and drafts contact messages. The human input is the login that happens when the session expires, and the review before anything is sent. That boundary is not a compromise. It is the right shape for automation that stays honest: a human at the door, an agent everywhere else.

In my last post I described how I turned my Raspberry Pi into a remote control for a Windows PC with an RTX 3070 Ti, generating a wobbly two-tailed cat video with AnimateDiff. The natural next step was to try a real video model. Not a motion module bolted onto an image model, but an actual text-to-video model: LTX-2.3, a 22B-parameter model from Lightricks that generates video and audio in one pass.

What followed was the most educational debugging session I have had in a while. Six distinct errors, each one hiding the next, each one teaching me something about how ComfyUI actually works under the hood.

The 30-second version: a 22-billion-parameter video model CAN run on an 8 GB GPU, but only if you wire it as the joint audio-video model it actually is. Five of the six errors were wiring mistakes, not model failures: the wrong text-encoder loader, the wrong VAE file, and a missing audio-latent chain. The recipe at the bottom works. It is slow (20+ minutes for a two-second clip), but it runs entirely on commodity hardware. The errors are the curriculum: each one teaches a real fact about how ComfyUI and LTX-2.3 work.

The Setup

Same hardware as last time:

The model files: ltx-2.3-22b-dev-fp8.safetensors (22B params, fp8 quantized, 29 GB on disk), the Gemma text encoder, and the model’s VAE.

Quick primer: what is a VAE? A VAE (Variational Autoencoder) is the translation layer between pixels and latents. Diffusion models do not work on images or videos directly: they work on a compressed, noisy mathematical representation called a latent space, which is much smaller than the actual pixels. The VAE has two halves: the encoder compresses pixels into latents (used for image-to-image and video-to-video), and the decoder expands latents back into visible pixels (used at the end of every generation). Think of it as the codec of the diffusion world: the model thinks and dreams in compressed form, and the VAE is what turns those dreams back into something you can see. Getting the wrong VAE is like connecting a Blu-ray player to a VHS-era TV: the signal is there, but nothing displays correctly.

The Six Errors at a Glance

Error 1: “clip input is invalid: None”

The first submission failed immediately. LTX-2.3 does not bundle a text encoder inside its checkpoint, so the workflow tried to grab a CLIP model that was not there.

Fix: Load the text encoder separately. ComfyUI has a CLIPLoader node with a type parameter, and for LTX the correct value is ltxv, pointing at the Gemma encoder.

Error 2: “Tensors must have same number of dimensions: got 4 and 3”

Now the model loaded, but the sampler exploded. This one took a while. The generic CLIPLoader produces text embeddings in a shape that LTX-2.3’s video embedding connector cannot digest.

Fix: Use the node made for this exact purpose: LTXAVTextEncoderLoader. It knows how to pair the Gemma text encoder with the LTX checkpoint and produces embeddings the model accepts.

Error 3: “‘dict’ object has no attribute ‘sample’”

The workflow validated but crashed at runtime. My JSON embedded the sampler as an inline object instead of referencing a separate sampler node.

Fix: In the API format, every node must be a top-level entry, and connections use ["node_id", output_index] references. The sampler got its own node, and the sampler node got a proper reference to it.

Error 4: “expected input to have 16 channels, but got 128 channels”

This was the first clue about LTX-2.3’s architecture. The VAE decoder expects 16 channels, but the sampler produced a latent with 128 channels. LTX-2.3 is a joint audio-video model: the latent contains both the video stream and the audio stream, interleaved.

Fix: Insert LTXVSeparateAVLatent between the sampler and the video decoder. It splits the joint latent into its video and audio halves.

Error 5: “tuple index out of range”

The separator node complained it could not find the audio half. Right, because the workflow never created one. The joint AV model needs an audio latent to pair with the video latent, even when you only want the video.

Fix: Build the full audio chain: LTXVAudioVAELoader loads the audio VAE from the checkpoint, LTXVEmptyLatentAudio creates an empty audio latent, and LTXVConcatAVLatent merges the video and audio latents into the joint structure the sampler expects. After sampling, LTXVSeparateAVLatent splits them again.

Error 6: the same 128-channel error, again

With the full AV chain in place, the sampler finally ran. The separator split the latent. And the decoder still choked on 128 channels.

The culprit was the VAE file itself. I had pointed the decoder at the separately downloaded ae.safetensors, which is LTX-2’s VAE and expects 16 channels. LTX-2.3 is a different architecture with a 128-channel latent, and its VAE ships inside the checkpoint.

Fix: Take the VAE from the checkpoint loader’s second output slot instead of loading a separate VAE file.

The Working Recipe

The final workflow, for anyone who wants to skip the six hours of debugging. The LTX custom nodes come from the ComfyUI-LTXVideo repo, and the whole thing runs inside ComfyUI:

flowchart TD
    subgraph Loaders
        CKPT["CheckpointLoaderSimple<br/>(ltx-2.3-22b-dev-fp8)"]
        TENC["LTXAVTextEncoderLoader<br/>(gemma-3-12B)"]
        ALOAD["LTXVAudioVAELoader"]
    end

    subgraph Conditioning
        TE1["CLIPTextEncode (positive)"]
        TE2["CLIPTextEncode (negative)"]
        COND["LTXVConditioning"]
    end

    subgraph Latents
        VID["EmptyLTXVLatentVideo"]
        AUD["LTXVEmptyLatentAudio"]
        CONCAT["LTXVConcatAVLatent"]
    end

    subgraph Sampling
        SCHED["LTXVScheduler"]
        KSEL["KSamplerSelect"]
        NOISE["RandomNoise"]
        GUIDER["CFGGuider"]
        SAMP["SamplerCustomAdvanced"]
    end

    subgraph Output
        SEP["LTXVSeparateAVLatent"]
        VAEDEC["VAEDecode"]
        SAVE["SaveAnimatedWEBP"]
    end

    CKPT -->|model| GUIDER
    CKPT -->|"vae (slot 2)"| VAEDEC
    TENC --> TE1
    TENC --> TE2
    TE1 --> COND
    TE2 --> COND
    COND --> GUIDER
    VID --> CONCAT
    ALOAD --> AUD
    AUD --> CONCAT
    CONCAT --> SAMP
    GUIDER --> SAMP
    SCHED -->|sigmas| SAMP
    KSEL -->|sampler| SAMP
    NOISE -->|noise| SAMP
    SAMP --> SEP
    SEP -->|video| VAEDEC
    VAEDEC --> SAVE

Here is the result, 49 frames at 512x512, generated from the prompt “a cute orange cat walking through a sunlit park”:

Note on sound: this video is silent by design. The workflow creates an empty audio latent (LTXVEmptyLatentAudio) to satisfy LTX-2.3’s joint audio-video architecture, and the output format (animated WebP, then converted to MP4) does not carry audio anyway. LTX-2.3 can generate sound when the audio path is conditioned properly, but that is a separate project.

Get the Workflow

The workflow is available as an editable template with a placeholder prompt, in two formats:

• For drag-and-drop into the ComfyUI canvas: ltx23-t2v-template-ui.json
• For the API: ltx23-t2v-template.json

In the JSON, node 4 holds the prompt. Replace REPLACE_WITH_YOUR_PROMPT with your own text. For reference, the prompt that produced the cat video above was:

“a cute orange cat walking through a sunlit park, cinematic lighting, smooth motion, high quality”

Two ways to use it:

1. In the ComfyUI interface: download the -ui JSON, then drag and drop it onto the ComfyUI canvas. The nodes appear, ready to run. Double-click node 4 to edit the prompt.
2. Via the API (how I did it from the Pi):

   curl -X POST http://<your-comfyui>:8188/prompt \
     -H "Content-Type: application/json" \
     -d '{"prompt": <workflow-json>, "client_id": "puck-pi"}'
   

What you need installed: the ComfyUI-LTXVideo custom nodes, the LTX-2.3 model in models/checkpoints, and the Gemma text encoder in models/text_encoders. The VAE comes from the checkpoint itself, no separate file needed.

What I Learned

• LTX-2.3 is not a video model with an audio add-on. It is a joint audio-video model. The latent is one interleaved structure, and every stage of the pipeline has to respect that: audio latent creation, concatenation before sampling, separation after.
• The right node matters more than the right parameter. Every error here was about wiring, not about values. When a ComfyUI workflow fails in a strange way, question the node choice before the settings.
• Checkpoints can carry their own VAE. The separate VAE file in my models folder looked correct but was for the wrong model version. The VAE that matches the model lives inside the checkpoint.
• 8 GB of VRAM will run a 22B model, technically. The render took over 20 minutes and the GPU utilization hovered around 10%. It works, but it is the slowest way to generate a two-second clip. For this model, 12-16 GB of VRAM is the honest minimum for comfortable use.
• Debugging through an API is a great teacher. Because I drove ComfyUI from the Pi over its REST API, I had to read every error message, check every node interface, and understand the graph end to end. No clicking around in a UI hoping something works.

The two-tailed cat from last time has a new cousin now. Same cat, same park, this one came from a real 22-billion-parameter video model, rendered at 24 frames per second, through six errors and one very patient Raspberry Pi.

The Takeaway Framework

Next time you wire a new model into ComfyUI and it fails, run this sequence instead of guessing:

1. Question the node before the parameter. Every one of my six errors was a wiring problem, not a settings problem. When something fails in a strange way, suspect the node choice first.
2. Read the model’s architecture before touching the graph. LTX-2.3 being a joint audio-video model explained errors 4, 5, and 6 in advance. The model card tells you what the latent looks like; the errors are just the architecture talking.
3. Trust the checkpoint over separate files. The VAE that matched the model was inside the checkpoint, not in the misleadingly named ae.safetensors. When a downloaded companion file disagrees with the model, the model is usually right.
4. Dump the raw history when the UI hides the error. The ComfyUI history API can return empty keys for failed nodes; the full traceback is in the raw JSON. Do not debug from a truncated message.

Six errors, six lessons, one working recipe. The errors are the curriculum.

Every AI hobbyist reaches the moment where still images stop being enough. For me that moment was last week, when I realized my Raspberry Pi 5, for all its charms, will never render a video. Not one frame. The Pi is my always-on agent, my Telegram butler, my home automation brain. I wrote about building it and its skills a few days earlier. But AI video generation needs a GPU, and the Pi has none.

So I built a small Frankenstein: the Pi stays the brain, and a Windows PC with an NVIDIA RTX 3070 Ti became the muscle.

The 30-second version: I ran ComfyUI on a Windows PC with an RTX 3070 Ti and drove it remotely from my Raspberry Pi over the LAN. The Pi submits a workflow as JSON, the PC renders it on the GPU, and the result comes back. No cables, no cloud. The first video: 16 frames at 512x512, 20 steps, about a minute of render time. It is a wobbly two-tailed cat in a vaguely sunlit park, and it is the most satisfying minute I have spent on this hobby so far.

The Setup

Two machines, one home network:

The magic ingredient is the ComfyUI API. ComfyUI, the node-based AI image and video tool, exposes a REST API. Any machine on the network can submit a workflow as JSON and pull back the result. The Pi talks to the PC over the LAN, no cables, no cloud.

flowchart LR
    PI["Raspberry Pi 5<br/>(brain, no GPU)"] -->|"workflow JSON<br/>POST :8188/prompt"| CU["ComfyUI on Windows PC<br/>(RTX 3070 Ti, 8 GB)"]
    CU -->|"renders 16 frames<br/>512x512, 20 steps"| GPU["GPU"]
    GPU -->|"animated webp"| CU
    CU -->|"result back over LAN"| PI

What We Did

Setting it up took longer than the actual generation, which is the classic pattern. Here is the path:

1. Install ComfyUI on Windows. The Desktop app, with NVIDIA support selected. It was running with --listen so other machines could reach it.

2. Find each other. The Pi checks http://192.168.178.22:8188/system_stats and sees the GPU: an RTX 3070 Ti with 8.6 GB of VRAM.

3. Pick a video model. The full video models like LTX-2.3 or Wan 2.1 are huge (20-30 GB) and need more VRAM than 8 GB. The pragmatic choice was AnimateDiff: a motion module that animates existing Stable Diffusion models. Small, fast, and it works with the DreamShaper model I already had.

4. Download the motion module. A 1.7 GB file. This is where the setup got funny: ComfyUI’s AnimateDiff version 1.6 looks for motion modules in a folder called animatediff_models, not the motion_modules folder that older tutorials mention. ComfyUI actually created the correct folder itself on restart. A quick move command and one more restart later, the module appeared.

5. Build the workflow. This is the part I love. A ComfyUI workflow is just a JSON graph: nodes and connections. I wrote one from the Pi with six nodes: the model loader, the AnimateDiff loader, the prompt encoders, the sampler, the VAE decoder, and the video saver.

6. Submit and wait. One curl POST later, the queue on the Windows PC started. The 3070 Ti rendered 16 frames at 512x512, 20 steps each, in about a minute.

The Result

Here is the very first video my little cluster ever made. The prompt was “a cute cat walking through a sunlit park, cinematic lighting, high quality.”

Note on sound: this video is silent. AnimateDiff is a motion module on top of an image model, so it has no audio path at all. The LTX-2.3 model I later switched to is a joint audio-video model and can generate sound, but that is a separate project.

It is not Hollywood. The cat drifts more than it walks, and the park is more suggestion than scenery. It also has two tails, because of course it does. When a diffusion model does not know how many tails a cat should have, it simply gives it the average number of tails, rounded up. Happy little accidents, as the painter would say: the cat was never supposed to have two tails, and I would not change it now. But consider what just happened: a text prompt typed on a tiny Linux board in Berlin traveled over WiFi to a Windows PC, became a latent-space dream on an NVIDIA GPU, and came back as sixteen frames of a cat in a park. The whole loop took about a minute.

The run, in numbers:

Lessons Learned

• VRAM is the currency. 8 GB runs AnimateDiff comfortably at 512x512, 16 frames. LTX-2.3 (22B params) also fits in fp8, but bigger clips and higher resolutions are where 8 GB hits its ceiling.
• Folder names change between versions. The animatediff_models vs motion_modules confusion cost us two restarts. When a model is invisible, check the folder name the node actually scans.
• Node names change too. EmptySDLatentImage is now EmptyLatentImage, and the AnimateDiff loader changed from the simple apply node to ADE_AnimateDiffLoaderWithContext, which returns a model the sampler accepts directly.
• The webp-to-mp4 conversion is easier on the machine that rendered it. The Pi’s ffmpeg could not decode the animated webp, so I extracted the frames with Python and reassembled them.

  What Is Next

The pipeline works. The Pi is now a remote control for a GPU that lives across the room. Next steps are tempting: longer clips, higher resolution, image-to-video, maybe that LTX-2.3 model I downloaded and never got to use properly. If you want the full story of how the Pi itself is set up, from SSD boot to auto-starting services, I wrote that up in Raspberry Pi 5 From Scratch.

But for now, I have a cat. A slightly wobbly, vaguely sunlit, entirely machine-made cat. And that is a good place to start.

The Pattern, Reusable

If you want to do the same thing, the shape is simple:

1. Keep the brain and the muscle separate. Your always-on machine stays the brain; the GPU box is a dumb renderer you reach over the network.
2. Expose the muscle as an API, not a screen. ComfyUI’s REST endpoint turns “use a GPU” into a curl call. Anything that can speak HTTP can render.
3. Start with the smallest model that fits your VRAM. AnimateDiff on 8 GB beat the 20-30 GB video models I never could have run. The first win matters more than the ideal model.
4. Expect the setup to take longer than the generation. Folder names change, node names change, the first render is always an argument with the tool. The generation itself is the easy part.

The whole pattern: Pi thinks, PC renders, LAN connects, cat wobbles. Happy little accidents included.

2026-08-02 · 8 min read · [raspberry-pi] [systemd] [debugging] [homelab] [storytelling]

Everything in this story actually happened. My headless Raspberry Pi went unreachable one Sunday evening, and debugging it turned out to be a genuine whodunit. Debugging a machine that goes silent has the same shape as a detective case: a victim, a scene, witnesses, conflicting clues, and a culprit who was there all along. Two enabled services that each think the other is an impostor, a crashed process that keeps reviving itself, a watchdog barking into the void. That is not an analogy, it is the plot. Sherlock Holmes is simply the clearest lens for it. The facts are untouched, only the telling is dramatized, and the technical TL;DR is at the bottom if you prefer facts over fog.

AI disclosure: All illustrations in this story are AI-generated images (FLUX.1-dev), selected and edited by me. They were added later, imagining what the case would have looked like if Sherlock Holmes had worked with systemd and a soldering iron.

Chapter I: The House at 192.168.178.54

It was a Sunday evening in August, and the fog had crept over the digital quarter of Berlin like a thief. In a modest house on the corner of the street called 192.168.178.54, a machine had fallen silent.

The telegram boy had knocked twice that afternoon and received no answer. The housemaid, who attended to the doorways of the house (we called her SSH), had found the front entrance sealed as if by a spell. The master of the house, a modest but industrious fellow by the name of Gateway, was nowhere to be seen. His clock, which had ticked faithfully for one week and two days, had stopped.

I found my friend Sherlock Holmes in his study, pipe in hand, staring at a sheet of paper upon which someone had scrawled the words: BOOT_ORDER=0xf146.

“The game,” he said without turning, “is most certainly afoot.”

Chapter II: The Note on the Doorstep

Holmes had been called to the house by a distraught servant. The tale she told was this: the master had been unwell for weeks. He would rise each morning, light his lamps, and begin his rounds. Then, without warning, he would collapse. The servants would find him gasping the same words each time, like a man possessed:

“Gateway already running. Gateway already running. PID 1284. PID 1284.”

“Over and over,” the maid wept. “Twenty times. Thirty-five times, I counted.”

Holmes raised an eyebrow. “And this PID 1284. Was it a person? A rival?”

“That’s the devil of it, sir,” she said. “PID 1284 was the master himself.”

“A man cannot be running and not running at once,” I protested.

“Can he not, Watson?” Holmes smiled thinly. “Can he not?”

He knelt by the machine’s hearth and examined the ashes. There, among the cinders, lay two calling cards. One was engraved with a single word: system.slice. The other, smaller and older, bore the mark: user.slice.

“Two suitors,” Holmes murmured. “And both claim the hand of the same bride.”

Chapter III: The Rivalry

Holmes produced a magnifying glass and held it over the two cards.

“Observe, Watson. The first card, system.slice, is clean and new. It was pressed upon the household at exactly twenty minutes past nine this evening, by a footman who answers to the name of root. It carries a curious instruction, quite modern: --replace. Whoever bears this card may, by its power, step into the shoes of any predecessor.”

“And the second card?”

“The second card is the intruder. It is dated the twentieth of July. It was slipped into the household ledger by a quieter servant, one who answers to the name of systemd --user. He does not announce himself at the front door. He waits in the pantry, in a file called ~/.config/systemd/user/hermes-gateway.service, and at every dawn he sends forth his own claimant to the same position.”

“So there are two masters claiming one chair?”

“Exactly, Watson. And when two men claim one throne, one of them must die. Or rather,” he tapped the paper, “one of them must be told he is already dead.”

I confess I did not follow. But Holmes was already striding toward the machine’s great central chamber, the place the servants called the Process Table.

Chapter IV: The Ghost in the Machine

We found them there, the two claimants, standing at opposite ends of the room.

The first was a hale and hearty fellow, PID 5371, born at twenty past nine, son of the system itself. He carried his --replace like a sabre. “I am the rightful master,” he declared. “I answer to root, and I answer to no other.”

The second was a gaunt and older figure, PID 5886, who had slipped in through the user’s pantry at eleven minutes past nine. He carried no such sabre. He carried only the memory of having been there first.

“Stand aside,” said the first.

“I was here before you,” said the second. “The ledger says my name. PID 1284, it says. And then you came, and the ledger could not decide which of us was real.”

Holmes studied them both, then turned to me.

“The crime, Watson, is not that one man killed another. The crime is that the ledger itself was corrupted. Each claimant looked into the book, saw the other’s name, and concluded he was dead. Yet both breathed. Both claimed the bride. And the bride, poor creature, could serve neither.”

“Then who,” I asked, “is the victim?”

“The victim,” said Holmes, “is the truth. And the murderer is the twentieth of July.”

Chapter V: The Hound of the Machine

We descended into the basement, where a new servant had recently been hired. He was a large, loyal creature, and he answered to the name of Watchdog. His task was simple: every five minutes, he was to sniff at the master’s chambers and report whether the master yet lived.

“Good fellow,” said Holmes, “and what did you find?”

“I found,” said the hound, “that the master was not dead, and yet not alive. I found two masters where there should be one. I barked. I sent letters by post to the far address, zocher.erik+blog@gmail.com, for when the telegram boy is dead, one must write letters instead. I barked until my throat was raw, and still the household would not listen.”

“A faithful servant,” Holmes observed, “and a clever one. He understood the first law of such households: when the telegram is silent, you must cry through other means.”

“Indeed, sir,” said the hound. “But I could not heal the rift. I could only name it.”

“You named it well enough,” said Holmes. “You said there were two. And where there are two, one may be dispensed with.”

He turned to me, his eyes glittering.

“Come, Watson. We have found the ghost. Now we must find the root of all evil.”

Chapter VI: The Root of All Evil

The root of all evil was not buried deep. It lay, as such things often do, in the most ordinary of places: a single file, unremarkable, dated the twentieth of July.

Holmes held it up to the lamp. ~/.config/systemd/user/hermes-gateway.service.

“Here, Watson, is the confession. On the twentieth of July, someone in this household installed a second doorkeeper. They meant no harm. They wished only for the master to rise each morning. But they did not know that another doorkeeper, a grander one, already stood at the front gate with the key of root and the sabre of --replace.”

“So the second doorkeeper,” I said slowly, “was not a murderer. Merely… redundant.”

“Redundant is the kindest word for it. The crueler word is conflict. Two doorkeepers, each certain the other was an impostor. Each morning, the household would send both to the same post. Each would find the other’s coat upon the peg and cry, ‘Intruder!’ And then the house would fall silent, for a house with two masters is a house with none.”

“And the remedy?”

Holmes smiled. “The remedy is as old as Solomon. You do not divide the child. You dismiss one of the claimants.”

He drew a pen and struck a single line through the servant’s name.

systemctl --user disable hermes-gateway

“The user’s doorkeeper is retired,” he said. “He will not rise again. The system’s doorkeeper remains, and he carries the modern key, --replace, which grants him the power to step over any ghost that lingers. And the hound, the faithful Watchdog, shall keep his vigil, and send letters when the telegram falls silent.”

He closed his notebook and reached for his coat.

“The case is closed, Watson. The victim was not a man but a certainty. The murderer was not malice but duplication. And the ghost… the ghost was merely a master who had been told, once too often, that he was already dead.”

TL;DR: What Actually Happened

The setup: A Raspberry Pi 5 runs Hermes Agent as a systemd service (hermes-gateway.service), connecting to Telegram and running cron jobs. It had run stably for about a week and a half before becoming unreachable via both SSH and Telegram (a full system-level hang, likely a hard reset; no clean shutdown was recorded in the journal).

The real culprit: dual systemd units.

• System unit: /etc/systemd/system/hermes-gateway.service (managed by root, runs in system.slice, PPID 1)
• User unit: ~/.config/systemd/user/hermes-gateway.service (created 20 July, managed by systemd --user PID 1219, runs in user.slice)

Both units were enabled, so every boot spawned two gateway instances competing for the same PID lock file (~/.hermes/gateway.pid).

The failure cascade:

1. The user instance started first at boot (PID 1284, user.slice).
2. Systemd’s system instance then tried to start a second gateway, and Hermes’ PID guard refused: “Gateway already running (PID 1284)” with exit code 1.
3. A Restart=on-failure (from a user-added override that contradicted the unit’s Restart=always) caused rapid restart attempts, producing a crash-loop. The restart counter reached 35.
4. systemd eventually reported “more than one ExecStart= setting… bad unit file setting” because a drop-in override.conf had been written with a second ExecStart= line without resetting the first. That is a classic systemd drop-in merge footgun. The unit went failed.

Fixes applied:

• --replace flag added to the gateway’s ExecStart (the official “useful for systemd” option). A fresh start now auto-replaces any stale instance instead of dying on the PID lock.
• Override repaired: ExecStart= (empty, resets the main unit’s value) followed by the new ExecStart=. Required because systemd merges drop-ins, so a bare second ExecStart= would add, not replace.
• User unit disabled via systemctl --user disable hermes-gateway, removing the duplicate doorkeeper. Only the system unit starts at boot now.
• Watchdog script (gateway_watchdog.sh, cron every 5 minutes) checks that ActiveState/SubState is active/running and that exactly one gateway process exists. On failure it sends an email via himalaya, a fallback channel, since Telegram is dead when the gateway is. Alert spam is prevented with rate-limiting.

Root cause in one line: Two enabled systemd units (system + user) fought over one PID file; a broken drop-in override then locked the service in a crash-loop. Adding --replace, disabling the user unit, and installing a mail-capable watchdog made the whole thing self-healing.

License: illustrations generated with FLUX.1-dev, free for non-commercial use; this blog qualifies. Check the license before any commercial use.

2026-08-02 · 10 min read · [raspberry-pi] [nvme] [systemd] [homelab] [linux] [headless]

This is the technical companion to my Raspberry Pi AI agent overview. That post covers the hardware and the big picture. This one covers the whole machine: from flashing the SSD and setting up WiFi before the first boot, to booting from NVMe, auto-starting services, and getting a GUI when I need one.

1. First Boot: Flashing the SSD and Pre-Setting WiFi

Before any customization, the Pi needs an operating system, and for a headless setup the trick is to configure everything before the first boot, so you never need a monitor or keyboard.

Flash the OS directly to the SSD

Raspberry Pi Imager is the official tool and it does the whole job in one go. It runs on Windows, macOS, and Linux, and it can write the OS straight to the NVMe drive.

1. Connect the SSD to your computer. An NVMe-to-USB adapter or a small USB enclosure is all you need. The drive shows up like a big USB stick.
2. Open Raspberry Pi Imager and click Choose Device → Raspberry Pi 5.
3. Choose OS → Raspberry Pi OS (64-bit) or Raspberry Pi OS Lite if you want no desktop at all.
4. Choose Storage → pick the NVMe SSD, not your computer’s own disk!
5. Click the gear icon (or press Ctrl+Shift+X) to open the advanced options. This is the headless magic:
   • Enable SSH and set it to allow password login (or paste an SSH key for key-only access).
   • Set the username and password you want to log in with.
   • Configure WiFi: enter the SSID and password. There is also a country dropdown (defaults to GB), and it matters more than it looks: set it to your actual country, e.g. DE for Germany. The country defines the regulatory domain, which tells the kernel which WiFi channels and transmit power levels are legal. With the wrong country you can lose the 5GHz channels entirely; with none set, the radio falls back to conservative defaults. The Imager writes all of this into the image, so the Pi connects to your network on its very first boot, with no keyboard needed.
   • Optionally set a hostname (mine is a plain ezocher box, but something like piagent is nicer) and your timezone.
6. Click Write and wait. The Imager flashes the OS, then verifies the write.
7. Unplug the SSD from the computer, mount it on the Pi with the M.2 HAT+, connect power, and wait about a minute.

That is the whole first-boot ritual: no monitor, no keyboard, no HDMI cable. The Pi appears on your WiFi, reachable by SSH, with the OS already on the NVMe drive.

If you are curious what the Imager actually did, it wrote a file called userconfig.txt (or a first-run script) onto the boot partition of the SSD with your SSH and WiFi settings. That file is read once on first boot and then consumed. You can pre-seed the same settings manually, but the Imager dialog is less error-prone.

2. Booting From the NVMe SSD

The Pi 5 does not boot from the microSD in my setup. It boots from the NVMe drive, and there are three pieces to that: the EEPROM boot order, the root filesystem in fstab, and the PCIe speed.

EEPROM boot order

The Pi 5’s boot order lives in its EEPROM. Mine reads:

$ sudo rpi-eeprom-config | grep BOOT_ORDER
BOOT_ORDER=0xf146

That hex value is read from right to left, each digit a boot source:

So the Pi tries the NVMe first, falls back to the SD card, and if neither works it keeps cycling. To change it, either use the menu:

sudo raspi-config   # Advanced Options → Boot Order → NVMe/USB Boot

or edit the EEPROM directly:

sudo rpi-eeprom-config --edit
# change BOOT_ORDER to 0xf146, save, reboot

Root filesystem by PARTUUID

The kernel finds the root partition by its PARTUUID, not by device name. That matters because device names (/dev/sda, /dev/mmcblk0) can change between boots, while PARTUUIDs are burned into the partition table.

$ cat /etc/fstab
PARTUUID=957b593b-02  /               ext4    defaults,noatime  0  1
PARTUUID=957b593b-01  /boot/firmware  vfat    defaults          0  2
UUID=76602090-4e70-4a14-a6c2-ffd91561de93 /mnt/nvme ext4 defaults,auto,users,rw,nofail 0 0

The 957b593b PARTUUIDs belong to the NVMe partition table. You can confirm which disk they point at:

$ lsblk -o NAME,PARTUUID,MOUNTPOINT
nvme0n1
├─nvme0n1p1  957b593b-01  /boot/firmware
└─nvme0n1p2  957b593b-02  /

The old microSD is demoted to a plain data disk, mounted at /media/ezocher/bootfs. The nofail option on the /mnt/nvme mount is important: it lets the system boot even if that drive is missing, instead of hanging at a mount prompt.

PCIe Gen 3 for full NVMe speed

The Pi 5 runs its PCIe bus at Gen 2 by default, which caps the NVMe throughput. Bumping to Gen 3 is one line in /boot/firmware/config.txt:

dtparam=pciex1_gen=3

Reboot and sudo dmesg | grep nvme should show the drive negotiating at Gen 3 speeds.

3. Auto-Starting Services With systemd

The “turn it on and it just works” part is systemd. Three services run on my Pi, all enabled at boot and all set to restart on failure:

$ ls /etc/systemd/system/*.service
hermes-gateway.service    # the AI agent
ollama.service            # local model serving (legacy, see the overview)
kindle-dashboard.service  # serves the e-ink dashboard image

The agent service shows the pattern:

[Unit]
Description=Hermes Agent Gateway
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=ezocher
ExecStart=/home/ezocher/.hermes/hermes-agent/venv/bin/python -m hermes_cli.main gateway run
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Three details worth copying:

• After=network-online.target with Wants= waits until the network is actually up, so the agent does not start half-connected.
• Restart=always with RestartSec=5 brings the service back within seconds of any crash. This is the real resilience trick for a headless box.
• WantedBy=multi-user.target starts the service at boot without needing anyone to log in.

Enable any service with:

sudo systemctl enable --now <service-name>

The result: after a power cut, the kernel finds the NVMe, mounts the root partition, and systemd brings the whole stack up without a human in the loop. Power on, wait a minute, message the agent on Telegram. That is the whole ritual.

4. Raspberry Pi Connect for GUI Access

The Pi runs headless, but sometimes you need a graphical interface. Raspberry Pi Connect is the Foundation’s own remote access service: free, encrypted, and it works from any browser with no port forwarding.

Install it (on recent Raspberry Pi OS images it is already there, so check first):

rpi-connect --help

If that says “command not found”:

sudo apt update && sudo apt install rpi-connect

Link the Pi to your account:

rpi-connect signin

It prints a URL. Open it in any browser, log in with your Raspberry Pi ID, and the Pi is linked.

Enable the service so it survives reboots:

sudo systemctl enable --now rpi-connect

Connect: go to connect.raspberrypi.com, log in, and your Pi appears in the list. Click it and you get the desktop in a browser tab, or a shell. No port forwarding, no VPN, no dynamic DNS, and it works from outside your home network too.

Useful commands while you are at it: rpi-connect status shows the connection state, rpi-connect restart fixes a stuck client, and rpi-connect doctor runs diagnostics.

Putting It All Together

The full boot story is: EEPROM says “try NVMe first”, fstab points the root filesystem at the NVMe partition, config.txt unlocks Gen 3 PCIe, and systemd starts the agent, the dashboard server, and Connect automatically. That is the difference between a Pi you have to poke at and a Pi that just runs.

This is the technical half of the story. For the hardware list, the agent setup, and why I use a cloud model instead of a local one, see the overview post.

2026-08-02 · 6 min read · [raspberry-pi] [hermes] [ai-agents] [homelab] [nvme] [telegram]

I run a personal AI agent from a Raspberry Pi 5 that sits in my living room in Berlin. It watches the tram schedule, updates an e-ink dashboard on my wall, scans job listings, drafts blog posts, and talks to me through Telegram. This post is the overview. If you want the step-by-step technical details, I wrote those up in a separate post: Raspberry Pi 5 From Scratch.

The 30-second version: a Pi 5 with 16 GB RAM, booting from a 1 TB NVMe SSD, runs an open source agent framework (Hermes) as an always-on daemon. The model itself lives in the cloud (DeepSeek), because local models on the Pi could not do tool calls reliably, and tool calls are what separate a chat from an agent. You talk to it over Telegram, fix it over SSH, and it runs a small fleet of scheduled jobs: trams, dashboards, job scans, blog drafts. Total cost: hardware once, single-digit euros per month for the model API, a few watts of power.

The Hardware

Raspberry Pi 5 Model B (Rev 1.1) with 16GB RAM. That matters: the Pi 5 is the first Pi where 16GB is an option, and for an always-on agent, the extra headroom is worth it.

The star of the show is the storage: a 1TB NVMe SSD (BIWIN CE930) connected through the official Raspberry Pi M.2 HAT+. Booting from NVMe instead of an SD card changes everything. No more worrying about SD card corruption, which is the classic way a headless Pi dies. Reads and writes are fast enough that the agent never waits on disk.

A 238GB microSD is still in the slot from the old setup, but the system boots from the NVMe drive now. How I made that work is in the technical post.

The OS

Raspberry Pi OS, based on Debian 13 (Trixie), kernel 6.18. Running headless, no monitor, no keyboard. The only cables are power and network. Everything else happens over SSH and Telegram.

The Agent: Hermes

The agent itself is Hermes Agent by Nous Research. It is an open source AI agent framework that runs as a daemon on the Pi, and it is the whole point of this box. Instead of a chatbot that answers questions, Hermes is an agent that takes actions: it runs shell commands, reads and writes files, searches the web, manages scheduled jobs, and remembers things across sessions.

Why a Cloud Model, Not a Local One

I used to run local models on the Pi, served by Ollama. I tried four of them over a few days:

The size mattered, and the reason is the Pi’s 16GB of RAM. A model has to fit entirely in memory while the operating system, the agent, and everything else still need their share. The 5.1B models fit comfortably. The 8B and 9.7B models worked too, but they left much less headroom, and inference on CPU was slow: with no GPU, every token comes from the CPU, and the bigger the model, the longer you wait between words.

But the real reason I moved to the cloud was not speed or RAM. It was this: none of them could do tool calls reliably.

Tool calls are the difference between a chat and an agent. The model has to decide “I need the tram times” and produce a structured request to fetch them. Small models running on a Pi simply do not have the capacity for that reliably. They answer questions, but they cannot operate a harness. A local model on this hardware was a fun experiment and a dead end for real agent work.

So I switched to DeepSeek v4 Flash through the DeepSeek API. It is cheap, fast, and capable enough for tool use. The Pi sends requests to the API, the model decides what to do, and the Pi executes it. For this workload, cloud is the right call: the model lives in the cloud, the agent lives on the Pi, and the Pi stays quiet and cool.

flowchart LR
    YOU["You (phone / laptop)"] -->|"Telegram, everyday"| PI["Raspberry Pi 5<br/>Hermes agent<br/>16 GB, NVMe boot"]
    YOU -->|"SSH, serious work"| PI
    PI -->|"tool calls"| API["DeepSeek v4 Flash<br/>(cloud model)"]
    API -->|"decisions"| PI
    PI -->|"fetch data"| EXT["Trams, weather,<br/>job boards, events"]
    PI -->|"render"| KIND["e-ink dashboard<br/>on the wall"]

How I Interact With It

Two front doors, both headless:

SSH for everything serious. ssh ezocher@192.168.178.54 gets me a shell, and from there I can reach the agent’s files, logs, and configuration. When something breaks, this is where I look.

Telegram for everything daily. The agent is connected to Telegram as a bot, so I can message it like a friend. Ask for the tram, tell it to draft a blog post, ask it to check a job listing. It replies in the same chat. This is the interface that makes the whole thing feel alive. I check in from my phone, anywhere.

For the rare moments when I need a graphical interface, I use Raspberry Pi Connect, the Foundation’s own remote desktop service. It works from any browser, no port forwarding needed. The setup steps are in the technical post.

The Skills and Plugins That Make It Useful

Hermes organizes capabilities into skills, which are like plugins for the agent. These are the ones I actually use:

• BVG tram departures: checks the real tram times for my station (Buschallee). The most-used skill, honestly.
• Kindle dashboard: generates an e-ink dashboard image for an old Kindle Touch I mounted on the wall. Shows trams, weather, todos, and a Spanish word of the day.
• Blog pipeline: drafts posts and opens GitHub pull requests for me to review before anything goes live. This very post was drafted this way.
• Berlin events: scrapes event listings (rausgegangen.de and friends) for things to do.
• Design job scan: a weekly cron job that scans German design job boards. (For a friend, not me. I am a software engineer, not a designer.)
• Humanize writing: a checklist that keeps AI text from sounding like AI text.
• Weather: Open-Meteo, no API key needed.
• Spanish tutor: vocabulary and grammar drills, because I am learning Spanish.

The skills run on a schedule (cron) or on demand when I ask.

What Runs Automatically

The Pi is a small fleet of always-on jobs:

• The Kindle wall dashboard refreshes every two minutes with trams, weather, and todos.
• A daily todo review at 20:00.
• A design job scan every Monday morning.
• Blog drafts that turn into pull requests for review.
• A real-time tram departure watcher.

Uptime at the time of writing: one week, two days, and counting. It just sits there and does its job.

The Costs

• Hardware: Pi 5 16GB, NVMe HAT + 1TB SSD. One-time, roughly the price of a mid-range phone.
• Power: a few watts. Negligible on the electricity bill.
• Model API: DeepSeek v4 Flash is cheap. My usage costs single-digit euros per month.
• Everything else: free. Open source agent, free weather API, free job boards, Telegram bot is free.

The Pattern, Reusable

The key decision was separating the model from the machine. The model is in the cloud where the compute is, the machine is at home where the actions are. If you want to build the same thing, the shape is simple:

1. Put the agent where the actions are, the model where the compute is. A Pi 5 is a terrible GPU server but a fantastic always-on host: silent, cheap, and strong enough to run the harness, the schedules, and the memory.
2. Pick the front door for the audience. Telegram for daily use, SSH for serious work, remote desktop for the rare graphical moment. Three interfaces, one agent.
3. Test local models before committing to them. I ran four Ollama models before concluding the bottleneck was tool calls, not speed. Small models answer questions; they struggle to operate a harness.
4. Let the scheduled jobs do the proving. A fleet of small cron jobs (trams, dashboard, job scans) turns the agent from a toy into something you rely on daily, and it costs nothing to run.

If you want a personal AI agent that actually does things instead of just talking, a Pi 5 with an NVMe drive and a cloud model is a really good place to start.

Want the technical how-to? Read Raspberry Pi 5 From Scratch.

2026-07-31 · 6 min read · [ai] [prompt-engineering] [agents] [workflows] [beginner]

Most people think working with AI means typing a good prompt. That’s level one. There are at least five levels of working with AI, and each one gives you more control than the last. Here they are, from the simplest to the most powerful.

Before we start: this is a moving target. The way we work with AI keeps evolving, and new approaches appear faster than anyone can write about them. Treat this list as a snapshot of where things stand now, not a complete map. The next level might already be on its way.

Level 1: Prompt Engineering

What it is: the craft of asking well. The words you type into the box.

A prompt is more than a question. It carries context, constraints, examples, and a desired format. Compare these two:

“Write a polite refusal.”

“Write a polite refusal to a client who just cancelled their contract. Three sentences. No apology for the delay, thank them for the years of collaboration.”

Same intent, very different results. The second prompt tells the model who the audience is, how long the answer should be, and what to leave out.

What it gets you: better answers from a single request. That’s it. No memory, no tools, no follow-up. One shot, one answer.

flowchart LR
    A[You] -->|prompt| B[LLM]
    B -->|answer| C[You]

Level 2: Context Engineering

What it is: controlling everything the model sees before it answers. The system prompt, the instructions, the documents, the conversation history, the search results. All of these are context.

Prompt engineering is asking the right question. Context engineering is deciding what’s in the room when you ask it.

There are many ways to get context in. RAG is the most famous, but it’s only one:

• RAG (retrieval-augmented generation): the model looks up your notes, documentation, or database and answers from what it finds. Great for grounding answers in your own knowledge base.
• IDE integration: the model sees the actual code you’re working on. Tools like Cursor, GitHub Copilot, or Claude Code run alongside your editor, so the context is the project itself, not a summary of it. You don’t have to explain what your codebase looks like, the model already sees it.
• Links and URLs: give the model a documentation page, an API reference, or an article URL, and it reads the content before answering. Handy when the answer lives on the web and the model’s training data is outdated.
• System prompts and memory: standing instructions plus what you’ve discussed before. The model remembers the rules and the history you’ve set up.

What it gets you: grounded, consistent answers that use the right source, whether that’s your database, your codebase, or a webpage. This is how customer support bots stop hallucinating product details: they read the manual first.

flowchart LR
    A[You] -->|prompt| B[LLM]
    D[System prompt + memory] --> B
    E[Your docs via RAG] --> B
    F[IDE: your open code] --> B
    G[Linked documentation] --> B
    B -->|grounded answer| C[You]

Level 3: Harness Engineering

What it is: giving the AI hands. Tools, APIs, and actions it can call. Instead of just answering, it can do things.

Think of the model as a brain. The harness is the body you build around it: which tools exist, what they can touch, and what the guardrails are. This is where reliability comes from. You decide the boundaries, not the model.

Examples of harness pieces:

• Web search
• Database queries
• Sending emails
• Running code
• Reading and writing files
• Calling other APIs

My own setup lives at this level. My agent (Puck, yes I named it) has a terminal, a browser, file access, and messaging. It can check the BVG schedule, generate a dashboard image, push a blog post to GitHub, and send me the result on Telegram. That’s a harness around a model.

What it gets you: AI that acts, not just talks.

flowchart LR
    A[You] -->|task| B[Agent]
    B -->|tool call| C[Web search]
    B -->|tool call| D[Database]
    B -->|tool call| E[Run code]
    B -->|tool call| F[Send email]
    C -->|result| B
    D -->|result| B
    E -->|result| B
    F -->|result| B
    B -->|result| G[You]

Level 4: Loop Engineering

What it is: building feedback cycles. The AI acts, observes the result, adjusts, and repeats. Instead of a single shot, you get a loop.

A chef tastes the sauce and adjusts it. Single-shot prompting is cooking without tasting. Loop engineering is the tasting step.

The most common pattern is plan-act-observe: the AI makes a plan, takes a step, looks at what happened, and decides what to do next. It’s also called ReAct (reason + act). Related patterns:

• Self-correction: the AI reviews its own output and fixes mistakes
• Retry with more info: when a tool call fails, feed the error back and try again
• Evaluation loops: a second AI checks the first one’s work before it ships

What it gets you: much harder problems solved, because the system can course-correct instead of hoping the first try was right.

flowchart LR
    A[Plan] --> B[Act]
    B --> C[Observe result]
    C -->|needs adjustment| A
    C -->|goal reached| D[Done]

Level 5: Graph Engineering

What it is: wiring many AI steps, or many agents, together like a flowchart. Different parts do different jobs and hand their results to each other.

An assembly line instead of a single worker. One step researches, the next drafts, another checks quality, and a final step publishes. Each node in the graph is a focused piece, and the connections define how work flows between them.

Examples in the wild:

• A research agent that finds sources and passes them to a writing agent
• A review agent that checks the writing agent’s work against a style guide
• n8n-style workflows with AI nodes in the middle
• Multi-agent systems built with tools like LangGraph

What it gets you: complex, robust pipelines that split work across specialized pieces. If one step fails, you know exactly which one, and you can fix or replace it without touching the rest.

flowchart LR
    A[Research agent] --> B[Drafting agent]
    B --> C[Review agent]
    C -->|needs work| B
    C -->|passes| D[Publish agent]

Beyond the Five Levels

Two more approaches exist outside this ladder, and they work on a different axis.

Fine-tuning changes the model itself instead of the interaction around it. You take a base model and train it further on your own data: your writing style, your company’s support tickets, your code conventions. The result is a model that knows your stuff before you even prompt it. This is heavier than any level above. It needs data, compute, and maintenance, and it is usually the last resort when context and harness engineering are not enough.

Evaluation engineering is the quality control layer. Instead of asking “how do I make the AI better?”, it asks “how do I know whether the AI is good?”. You build a test set of known cases, run the model against it, and measure how often it gets things right. This matters more than people think. A system that is right 90% of the time and fails silently is worse than one that is right 70% of the time and flags its own uncertainty.

Both of these are their own crafts, and both keep evolving. They are worth knowing about, but they are not where a beginner should start.

Which Level Should You Use?

Start at level 1 and add levels as the problem demands. There’s no prize for using the most advanced level. The prize is solving the problem with the least complexity that works.

A Personal Note

Everything on this blog now runs through levels 3 to 5. Puck has tools (harness), loops through steps until tasks are done (loop), and I run separate jobs for separate purposes: a weekly design job scan, a dashboard updater, a blog draft pipeline that opens pull requests for me to review (graph). I rarely type a raw prompt anymore. I engineer the context, the tools, and the loops around it.

The Takeaway

Don’t be impressed by people who “prompt well”. The real craft is deciding what the AI sees, what it can touch, and how it learns from its own results. Prompts are the entrance. The levels above are where the actual work happens.

Start with prompts. Then work your way up one level at a time. Each level you add makes the AI more useful, and makes you think more like an engineer and less like a typist.