My AI setup: what runs locally, what goes to the cloud, and what actually does the work

Published Oct 17, 2026

1. TASK Name a concrete output For example: a checked article file, not just a convincing chat answer.
2. HERMES Profile + relevant skills The agent uses working context and procedures; neither grants unlimited authority.
3. LOCAL BRANCH One GLM · two DGX Sparks Head and tensor-parallel Worker cooperate on the same model; these are not Macs.
4. CLOUD BRANCH Separate inference route Selected sessions can use cloud providers; no automatic fallback or traffic split is asserted.
5. TOOLS Read → edit → check artifact Tool results establish only the operation exercised; later publication needs its own readback.
6. OBSERVATION Fleet view ≠ router Health and endpoint identity keep their own timestamps and coverage limits.

When I say I use AI to help run the work, the obvious next question is: which AI?

The honest answer needs more than a model name. There is the model producing a response, the agent environment giving it tools, the machines serving selected requests, and the dashboard helping me see what those machines report. Mixing those together makes a setup sound simpler than it is—and makes failures harder to diagnose.

Here is my setup as of October 17, 2026. This is the introduction I should have written before the deeper build logs. It is not a shopping list or a claim that everything runs locally.

The model isn’t the agent

I use Hermes Agent as a working environment. The model is an inference engine behind a selected route. It can propose the next step or interpret a tool result; it is not, by itself, a file reader, a deployment or a completed job.

The pieces have different jobs:

My content work and operational work have separate profiles. That helps keep the right procedures with the right job. It does not make a profile an independent employee with unlimited authority. The official Hermes profile guide also makes an important distinction: a separate profile is not filesystem sandboxing.

If I ask for an article, the useful result is a checked article file. If I ask for a repair, the useful result is the repaired behavior exercised against the failure. A convincing answer in chat is neither of those.

For a concrete failure at that tool layer, read how competing recovery helpers can replace each other’s resolution records. The important boundary was the file write, not a disagreement between models.

Local: one model across two NVIDIA DGX Sparks

The local route I have documented runs one GLM model across two NVIDIA DGX Sparks. These are NVIDIA machines, not two Macs, and the arrangement is not one independent model per box.

One Spark is the Head: it exposes the API and coordinates serving. The other is its tensor-parallel Worker. They cooperate on the same model. The Spark-pair build log covers the serving stack, dated measurements and failures; I am not turning those older benchmarks into today’s performance numbers here.

For a recent identity check, the retained serving observation at 2026-10-17 21:15:51 UTC records the local route as reachable and reporting GLM-5.3-Flash-EXL3. That is an endpoint observation at a named time—not a promise about the model answering when you read this.

There is an important qualification in the same evidence: the overall guard failed. Context length was not reported, and concurrency was not observed. The response supports reachability and the reported model identity; it does not establish the intended context capacity, available slots, throughput or a successful generation. I will not fill those blanks with the values saved in a recipe.

That local route is useful architecture. It is not proof that all of my AI traffic stayed on those two machines.

Cloud: a separate route, not a disguised local model

Cloud-backed inference is part of the setup too. Retained October 13–14 Hermes usage records include the local GLM route alongside cloud-provider records, including OpenAI Codex and DeepSeek. Those are dated usage records, not today’s allocation or an invoice.

There is also a useful present-tense counterexample to “everything is local”: the editorial worker session preparing this article reports gpt-6.1-sol through openai-codex in its runtime metadata. That is the session’s reported route, not a direct inspection of a cloud provider’s serving weights. It does not become local merely because the session is running on my computer.

Meanwhile, the retained October 17 configuration observation names the DGX route as the saved front door for several profiles. Those two observations are not interchangeable:

• Configuration tells me the saved selection at the time it was read.
• Session runtime metadata tells me the selection reported for that running worker.
• Retained usage records earlier activity within its actual coverage.
• Endpoint metadata tells me what a specific server reported at its own check time.

None of those alone proves a fleet-wide routing policy. I have not reconstructed a request-by-request local/cloud split for this article, and I am not claiming automatic fallback, a fixed task allocation or a savings total.

What actually does the work: one article-sized example

A concrete example is the October 15 Windows-dashboard article, not a hypothetical “research agent” demo.

First, narrow the job. The task was to review the October 13–14 work and produce a useful Windows story without confusing released software with installed monitoring. That scope mattered: seeing Windows support in source was not permission to enroll machines or announce unattended coverage.

Then, read the evidence. The content pass inspected the dashboard changelog, versioned Windows documentation and public release pages, and compared them with the existing articles. The useful distinction was pending inventory versus an accepted pilot versus verified automatic monitoring. A release note could establish a feature; it could not establish which of my computers had it installed.

Then, write and check an artifact. The retained review contains the complete draft, its claim map and privacy review. The original verification record checks the existing frontmatter schema, dates, public references and unresolved editorial flags. This was content production, not a model confidently narrating a release page it had never opened.

Finally, separate the handoff from publication. The research receipt explicitly says no deployment was performed by that pass. The later retained public-browser checks record the resulting Windows article among the nine published posts, with reader-facing page responses. Those are separate artifacts supporting separate stages: draft produced, then publication checked.

You can read the result: My Mac fleet dashboard learned Windows. The hard part was knowing what not to count.

I am not attributing every stage of that workflow to one model. The artifacts establish the research, draft, review and later page checks; they do not contain a complete model-by-model trace of the whole job. That is enough to explain how the setup works without inventing a single-engine success story.

The dashboard observes; it doesn’t route the requests

The Mac/Windows fleet view is an observation layer. Its health readings, pending computers and model-identity checks each have their own scope. A machine can have a familiar saved role while its model has changed. A current model report can exist without proving that requests are completing successfully.

The Windows article explains why listed inventory isn’t automatic monitoring. The companion current-model article explains why a saved role or old benchmark isn’t live model identity. Neither makes the dashboard the component deciding which model handles a Hermes task.

Keeping that distinction helps with a practical question: am I looking at the intended setup, a past result, or something the system actually observed recently?

What I’d copy before buying the hardware

I would start with the workflow, not the two-box model server:

1. Pick one bounded task with a concrete output—a file, a tested repair or a checked page.
2. Give the agent only the procedures and access relevant to that task. A useful profile boundary still needs action-level limits.
3. Identify the model route separately from the tools. “The agent can browse” says nothing about where inference happens.
4. Review the actual output and replay the relevant check. Don’t substitute a green status label for evidence.
5. Add local infrastructure only when there is a measured reason for that workload. This article establishes no hardware payback period.

The less glamorous part is operational continuity. My Hermes operator story describes an updater that interrupted work and the narrower protections added afterward. An agent environment that can inspect real artifacts is useful; keeping that environment from disrupting active jobs is part of making it useful tomorrow.

Sources and the limits of this snapshot

Public starting points: Hermes documentation, NVIDIA’s DGX Spark guide and the macfleet-dash documentation at the current-model release commit. Those explain products and source behavior, not my private runtime.

The dated route observation, historical usage extract, October 15 draft review and later public-page receipts are retained private operational evidence. Readers cannot download them from this article. I have left out private addresses, customer records, prompts and execution identifiers. The architecture illustration is a diagram, not a dashboard screenshot or proof of installed-host coverage.

This is a checked description of the setup and one bounded workflow. It is not a current all-host audit, a publishing-cadence claim, or a calculation of dollars, hours or electricity saved.