Local Models — โมเดลบนเครื่องของเราเองLocal Models — Run Hermes on Your Own Machine

🤔 If the machine on your desk can already run a 27B model, why do your students' files, your contracts, or your patient records still have to travel out to somebody else's API?

The previous post — #1 Install & First Run — installed Hermes Desktop up to your first message, and showed that everything lands in the same ~/.hermes the CLI uses. At that point the model answering you was still in the cloud. Now we move it down onto your own machine — and this is the post I think Thai readers in universities, hospitals and government offices should read most closely, because it is the answer to the data question we do not get to dodge.

The one-line answer: Hermes has three roads to a local model — a managed llama.cpp runtime you install from the Settings pane, LM Studio as a first-class provider, and the Custom endpoint for Ollama, llama-server and vLLM — but all three pass through the same gate: at least 64,000 tokens of context, and the flags that make the server emit tool calls in a shape the agent can parse. This post walks each road with the real commands, taken from the primary docs as I fetched them on 7 September 2026.

1. Three Roads to a Local Model

The direct answer first: Hermes does not have one way to "connect a local model" — it has three genuinely different ones, differing in what you click, in what they write into config.yaml, and in how much control you get back. Picking the wrong road does not mean it will not work; it means you will meet a different set of problems.

• Path A — the managed llama.cpp runtime: open Settings → Providers → Local Models in the app, and Hermes downloads the llama.cpp build that matches your hardware, offers a catalog already priced against your machine, and runs the server for you — the result in config is model.provider: llamacpp plus a local_runtime: block.^[1]
• Path B — LM Studio: a first-class provider named lmstudio, chosen from hermes model → "LM Studio", with the default endpoint http://localhost:1234/v1; Hermes auto-discovers the models you have loaded.^[2]
• Path C — the Custom endpoint: model.provider: custom plus model.base_url pointed at any server that speaks /v1/chat/completions — the docs name Ollama, vLLM, the llama.cpp server, SGLang, LocalAI and Jan outright.^[2]

What all three share is one sentence on the Custom & Self-Hosted page of the docs: "Hermes Agent works with any OpenAI-compatible API endpoint. If a server implements /v1/chat/completions, you can point Hermes at it."^[2] That means the architecture is tied to no vendor — and, as it turns out, not to Nous's own Hermes models either, a point that comes back in section 3.

Path A is the newest and the one that asks you to know the least. The Local Models page states the promise plainly: "Nothing leaves your computer: no account, no API key, and no network access after a model is downloaded." — nothing leaves your machine; no account, no API key, and no network access at all once the model is downloaded.^[1] For an organisation that has to answer a PDPA question, that sentence carries more weight than any benchmark number.

The reasons an organisation should come down to this rung I wrote out in full in #9 Models & Cost — the five-rung ladder from Nous Portal down to your own GPUs, and the PDPA question no Thai organisation gets to skip. This post is the hands-on half of the bottom rung: what to click, what to type, and what to check actually works.

2. Two Rules No Local Model May Break

The direct answer first: whichever road you take, two rules cannot be broken. The first is a hard number — at least 64,000 tokens of context, and anything smaller is rejected at startup. The second is about shape — the server must turn the model's tool calls into a structure the agent can read, rather than letting them out as ordinary text.

Rule 1 — 64,000 tokens, or it will not start

The Providers page says it outright: "Hermes Agent requires at least 64,000 tokens of context for agent use with tools. Smaller windows are rejected at startup because the system prompt, tool schemas, and working conversation state need enough room for reliable multi-step workflows."^[2] Translated into working terms: the system prompt and the tool schemas take a large bite before you type anything at all. A smaller window leaves the agent no room to actually run a multi-step task.

On the managed runtime the rule is baked into the code, so there is nothing to set. The docs state that "Every recommended model gets at least a 64K context window", and that when a model is larger than GPU memory Hermes places the overflow in system RAM "in the order that hurts least (expert weights first, never the attention cache)" — trading speed to protect the context guarantee.^[1] In the local_runtime source the value is a constant named FLOOR, equal to 64 × 1024 = 65,536 tokens.^[12]

Rule 2 — tool calls must come out in a shape the agent can parse

Breaking this rule has a very memorable symptom, because it is not an error but an answer that looks "almost right": the model prints JSON such as {"name": "web_search", ...} as a message instead of actually calling the tool.^[2] The troubleshooting table in the docs lists the flag for every server:

• llama.cpp / llama-server — add --jinja. The docs put it strongly: "Without --jinja, llama-server ignores the tools parameter entirely." Verify at http://localhost:8080/props — the chat_template field must be present.^[2]
• vLLM — --enable-auto-tool-choice --tool-call-parser hermes. The first is required because Hermes uses tool_choice: "auto" by default; the parser name changes with the model family (hermes, llama3_json, mistral, deepseek_v3, xlam, pythonic).^[2]
• SGLang — --tool-call-parser qwen (or llama3, llama4, deepseekv3, mistral, glm for other families). Without it, tool calls come back as plain text.^[2]
• Ollama — enabled by default; what you must check is whether the model supports it, with ollama show <model-name>.^[2]
• LM Studio — must be version 0.3.6 or later, with a model trained for native tool calling (LM Studio shows those with a tool badge).^[2]

The observation I want you to keep: both rules are about the server, not the model. You can pick an excellent tool-calling model and still get exactly the symptoms of a bad one because you forgot --jinja — and the hours spent blaming the wrong component cost far more than typing six extra characters.

3. Which Model Fits Your Memory

The direct answer first: the Nous docs do not recommend one model — they recommend a different set per road. The managed runtime's catalog holds four; the Ollama guide recommends exactly one, gemma4:31b; the Mac guide recommends Qwen3.5-9B. The table below puts all three sets side by side on the same criteria.

Before the table, one mechanism worth knowing: on Path A you do not have to guess what fits, because the docs state that every catalog model is "priced against your machine before you download anything" and shown in three colours — green (Fits your GPU), amber (Uses system RAM: it works, but slower) and red (Too big for this machine). Models that do not fit stay visible with the reason, so you always know what a hardware upgrade would unlock.^[1]

How I would read this table: look at Memory needed before anything else, because it is the constraint you cannot argue with. The size-on-disk figure is only half the story — the other half is the KV cache, which grows with context. The Mac guide makes this clearest: for a 9B model at 128K context, an f16 KV cache costs ~16 GB, q8_0 ~8 GB, and q4_0 ~4 GB.^[4] That is why an 8 GB machine really can run a 9B model — and why Path A handles this for you rather than exposing a knob.

The four catalog sizes I computed myself from the size_bytes fields in hermes_cli/local_runtime/catalog.json on main as of 7 September 2026; they are not numbers the docs print. The docs themselves warn that the catalog is "a curated starting point, not a boundary" — the same page carries a Find more models section that searches all of Hugging Face, and an Add model file button for a .gguf you already have on disk.^[1][12]

💡 What is not in this table: not one of Nous's own Hermes models. The managed catalog is Qwen and DeepSeek, the Ollama guide is Gemma, the Mac guide is Qwen, and the Providers page's example is qwen2.5-coder:32b. No page of the Hermes Agent documentation recommends running Hermes 3/4 weights locally for tool use. The word hermes in --tool-call-parser hermes is the name of a tool-call format, not of a model you must use — do not conflate the two when you are costing out a GPU.

4. Path A — One Click: the Managed llama.cpp Runtime

The direct answer first: this is the shortest road — four clicks. Install the runtime, pick a model, hit Download, hit Use, and new chats run on the local model. The docs sum it up themselves: "That's the whole flow." The server starts and stops with Hermes, and switching back to a cloud provider is one click in the model picker.^[1]

1. Open Settings → Providers → Local Models (or choose Run models locally during onboarding) — the Desktop page of the docs states that the Providers pane holds a Local Models view that "installs and manages an on-device llama.cpp runtime".^[6]
2. Click Install runtime. You should see a download of a few hundred MB — the docs say Hermes fetches the official llama.cpp build for your hardware, verifies it, and keeps it updated (CUDA or CPU on Windows and Linux, Metal on Apple Silicon, and Vulkan builds for AMD cards).^[1]
3. Pick a model from the catalog by reading the Memory fit colour first — take a green Fits your GPU row before anything else, and do not start your first experiment on an amber Uses system RAM one.
4. Click Download and wait. While you wait, note that the docs say model downloads are byte-size checked during the transfer: an incomplete download is deleted and reported, never half-used.^[1]
5. Click Use. You should see new chats switch to this model — the docs' wording is "New chats now run on the local model."^[1]
6. Send a test message that requires a tool, not a greeting — for example the sentence the Ollama guide itself uses: "List all Python files in this directory and count the lines of code in each". If you watch the agent actually invoke the terminal tool, rule two has passed.^[3]
7. Confirm from the file side with grep -A3 local_runtime ~/.hermes/config.yaml. You should see enabled: true in that block, because the docs state the Use button sets it automatically.^[1]

The block you will find in the config file is printed in the docs in full, comments included:

# ~/.hermes/config.yaml — what the Use button writes (copied from the Local Models page)
local_runtime:
  enabled: false     # true = start the managed server with Hermes.
                     # The desktop "Use" button sets this automatically.
  backend: auto      # auto | cuda | metal | vulkan | hip | cpu
  tag: b10362        # pinned llama.cpp release; Hermes updates it with
                     # each release after re-validation

Model selection needs no special key at all. The docs say it uses model.provider: llamacpp together with model.default — "the same shape as every other provider" — and that model files and runtime builds live under the Hermes home in models/ and runtimes/llamacpp/.^[1] In the source, the supervisor binds the server to 127.0.0.1 on default port 18434 (falling back to a free port if that one is taken) and always launches llama-server with --jinja, which is why the Tool calling column for all four catalog models in Table 1 reads Yes.^[12] The same source carries the 15-minute idle unload the docs describe.^[1]

Two first-week bugs to know about before you click

The feature was less than a week old as I wrote this, and two open issues affect real users directly. Both were still open when I checked on 7 September 2026:

• The auto-pick chooses a model too big for the machine — issue #102865 (4 September 2026) reports from a Linux laptop with an RTX 4070 Laptop (8 GiB VRAM) and 30 GiB of RAM that the catalog auto-selected qwen3.6-35b-a3b and generated a preset at ctx-size = 65536. RAM filled, the kernel began swapping, and the entire desktop froze until a hard reboot. The reporter's summary is blunt: "Working set >> available RAM → kernel swaps… → full desktop freeze". On 8 GB of VRAM or less, choose the model by hand rather than trusting the recommendation.^[13]
• Linux + NVIDIA picks a backend that cannot exist — issue #103949 (5 September 2026) shows that select_backend() returns cuda for every NVIDIA card off macOS, Linux included, but llama.cpp ships no prebuilt Linux CUDA asset, so it fails with BinaryResolutionError: no prebuilt linux CUDA asset. The workaround the reporter tested end-to-end is to set local_runtime.backend: vulkan by hand.^[14]

5. Path B — LM Studio

The direct answer first: if you want a graphical way to manage models and want Hermes to discover whatever you have loaded without typing a URL, Path B is the answer. LM Studio is not a custom endpoint but a first-class provider named lmstudio — pick it straight from the hermes model menu, and unlike Path A it is not tied to your Hermes Desktop build.^[2]

1. Install LM Studio and download a GGUF trained for tool calling — the docs name the families LM Studio auto-detects: Qwen 2.5, Llama 3.x, Mistral and Hermes, on LM Studio 0.3.6 or later.^[2]
2. Start the server from the Developer tab (Start Server), or from the command line with lms server start. You should see it come up on port 1234.^[2]
3. Set the context to the floor before loading the model — click the gear icon next to the model picker, set "Context Length" to at least 64000, then reload the model for the change to take effect; or use lms load model-name --context-length 64000.^[2]
4. If you are unsure the machine can hold it, estimate first with lms load model-name --context-length 64000 --estimate-only. If 64000 will not fit, the docs advise switching to a smaller model with a longer context rather than dropping below the floor.^[2]
5. Wire up the Hermes side: on the desktop, set the default at Settings → Model, which the docs describe as the only place that writes a profile's real default; in a terminal, run hermes model, choose "LM Studio", press Enter to accept the default URL http://localhost:1234/v1, and pick one of the discovered models.^[2][6]
6. Test with something that needs a tool, not a general-knowledge question — have it list the files in a folder and count their lines. If it answers with raw JSON instead of acting, go back to rule two in section 2.

# Start the server and load a model with a 64K context (commands from the Providers page)
lms server start                        # Starts on port 1234
lms load qwen2.5-coder --context-length 64000

# If you use LM Studio's Just-In-Time / Auto-Evict mode, stop Hermes preloading models itself
hermes config set model.lmstudio_load_mode jit
# Back to the default (Hermes preloads explicitly)
hermes config set model.lmstudio_load_mode explicit

Two things worth adding. The first is credentials: the default endpoint is http://localhost:1234/v1, overridable with the environment variable LM_BASE_URL,^[8] while LM_API_KEY is only needed if you have turned on auth in LM Studio's own server.^[2] The second is a subtler behaviour around context: the docs say Hermes preserves the context of an already-loaded LM Studio instance, and that in the default explicit mode it omits context_length entirely unless you configured one on the Hermes side, letting LM Studio apply its own model setting, and then uses only the context length LM Studio reports after loading.^[2] In other words: if you have already set 64000 in LM Studio, you do not need to set it again in Hermes.

6. Path C — Custom Endpoint: Ollama, llama-server, vLLM

The direct answer first: this road gives the most control and works with everything, because it is not support for a particular product — it is pointing Hermes at a URL that speaks OpenAI. The Hermes side is identical whatever sits at the other end; only the URL, the port, and the flags you pass when starting the server change.

1. Run hermes model from a terminal, not /model inside a chat — the docs warn that /model can only switch between things you have already configured and cannot add a new provider.^[2]
2. Choose the entry "Custom endpoint (self-hosted / VLLM / etc.)".^[2]
3. Enter the API base URL for your server — for example http://localhost:11434/v1 for Ollama.
4. Skip the API key for a local server, then enter the Model name — or leave it blank to auto-detect if only one model is loaded.^[2]
5. Enter a Context length that matches what the server really uses. The FAQ's worked example uses 64000 with the note "Hermes minimum; set this to match your server's actual context window" — leave it blank and Hermes will detect it, which is exactly where Ollama can mislead it (see section 7).^[5]

On the desktop the equivalent path lives in the settings: the docs place the model default at Settings → Model, and when a turn fails the error card offers a Switch provider button that jumps to the same place for provider, endpoint, auth and billing failures.^[6] The Local Models page agrees from the other side — the managed runtime "is a default, not a requirement", and you can always "point a custom endpoint at any OpenAI-compatible server for full manual control".^[1]

Now the server side. The three commands below are the three most common cases, taken verbatim from the primary docs with only the comments rewritten. Start with Ollama, which is where most people come unstuck, because its default context is below the floor:

# Option 1 — set it server-wide with an environment variable (the docs' recommended route)
OLLAMA_CONTEXT_LENGTH=64000 ollama serve

# Option 2 — bake it into your own model; persistent, per model
echo -e "FROM qwen2.5-coder:32b\nPARAMETER num_ctx 64000" > Modelfile
ollama create qwen2.5-coder-64k -f Modelfile

# Verify it took effect — read the CONTEXT column
ollama ps

# llama-server — --jinja is the flag you cannot omit for tool calling
./build/bin/llama-server \
  --jinja -fa \
  -c 64000 \
  -ngl 99 \
  -m models/qwen2.5-coder-32b-instruct-Q4_K_M.gguf \
  --port 8080 --host 0.0.0.0

# Check the context the server is really running with
curl http://localhost:8080/props | jq '.default_generation_settings.n_ctx'

# vLLM — both of these flags are required, or tool calls come back as text
vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --port 8000 \
  --max-model-len 65536 \
  --tensor-parallel-size 2 \
  --enable-auto-tool-choice \
  --tool-call-parser hermes

The table below puts all three roads on one page, including what each writes into config — the piece of information that is hardest to find in one place when you are debugging.

💡 Ollama has two identities in the Hermes world: the Ollama running on your machine is not a provider — it comes in through the Custom endpoint at http://localhost:11434/v1 with no key. Ollama Cloud, by contrast, really is a first-class provider (--provider ollama-cloud with OLLAMA_API_KEY). The docs draw the line themselves: "Use cloud for large models you can't run locally; use local for privacy or offline work." They are configured in two different places — do not look for "Ollama" in the provider list and then wonder why it wants an API key.^[2]

7. When It Goes Wrong

The direct answer first: nearly every local-model problem I have seen comes down to two things — a context window that is not the number you think it is, and silence at the start of a turn mistaken for a hang. Both present as "the model is stupid", and neither is about the model at all.

Ollama does not use the model's full context

This is the trap the docs themselves call "the #1 source of confusion" — Ollama does not use a model's full context window by default, and the value it does use depends on available VRAM. The table on the Providers page reads as follows.^[2]

• Less than 24 GB of VRAM → default context 4,096 tokens — fifteen times below the Hermes floor.
• 24–48 GB → 32,768 tokens — still below the floor.
• 48 GB and above → 256,000 tokens — plenty, on a machine most people do not have.

This is a point where the sources disagree, and I would rather say so than pick the nicer number. The guide "Run Hermes Locally with Ollama" says "By default, Ollama uses a 2048-token context",^[3] while the Providers page gives the 4,096 / 32,768 / 256,000 table keyed to VRAM.^[2] Both pages sit on the same site and were updated on different cycles — I recorded the same disagreement in #9 Models & Cost, where the comparison was against Ollama's own FAQ figure of 4,096. The practical conclusion does not change: every one of those values is below 64,000, so do not argue about which is right — set it yourself, every time.

What makes the trap painful is that it is silent. Issue #43900 (11 June 2026, still open) documents the mechanism in detail: Hermes reads the context from the GGUF metadata (131,072 for Gemma 4, say) and stores it, but never sends that value across the /v1/chat/completions route, because Ollama's OpenAI-compatible side does not accept the field. Once the conversation passes 4,096 tokens, every answer comes back with finish_reason="length" and empty or truncated content, and the retry loop then stitches broken fragments into garbled output — while the UI still shows 0 / 131.1K of context used.^[15]

Worse, auto-detection cannot save you, because the FAQ states that "Ollama's /api/show reports the model's maximum context, not the effective num_ctx you configured".^[5] Hermes asks, and gets an answer that is correct about the model and wrong about the server. The only safe fix is to set model.context_length yourself to match what the server actually runs. The docs lay out the full nine-step resolution chain, in which your own value in config.yaml is step one and a 128K default for unknown models is the last resort.^[2]

Silence at the start of a turn is prefill, not a hang

The second problem is about time. The Mac guide puts it most directly: Hermes sends its system prompt and tool schemas on every call, so on slower hardware the first turn can involve minutes of silence while the model processes that prompt before generating anything — "That's prefill at work, not a stalled session."^[4] Hermes knows this and already compensates: the FAQ states that it auto-detects local endpoints and relaxes streaming timeouts, raising the read timeout from 120s to 1800s (that is 30 minutes) and disabling stale-stream detection; if very large contexts still time out, set HERMES_STREAM_READ_TIMEOUT=1800 in ~/.hermes/.env.^[5] On the Ollama side the guide also recommends HERMES_API_TIMEOUT=1800 and keeping OLLAMA_KEEP_ALIVE=24h, because by default Ollama unloads idle models after five minutes, adding a full reload before the next prefill.^[3]

That still does not cover every symptom. Issue #87697 (16 August 2026, still open, labelled needs-repro) reports from Linux plus Ollama that Hermes cancels its own stream after roughly 1.5 seconds while the model is still evaluating the prompt, then makes four continuation attempts that corrupt the context into a run of <unused49> tokens. The reporter's root-cause analysis is that Hermes sends a large system prompt of about 17,000 tokens from the tool schemas, and evaluating a prompt that size on local hardware naturally takes 1.5–2.5 seconds before the first text token — the attached Ollama log shows task.n_tokens = 16862, which matches.^[16] If you hit this, know that it is an unfixed bug rather than your configuration, and that the tool which genuinely shrinks that prompt is hermes prompt-size, which the Mac guide recommends.^[4]

Two settings that fix most of it

1. Always set the context yourself — write model.context_length into config.yaml to match what the server really uses, rather than leaving it to detection. This is step one of the resolution chain, so it beats every other source.^[2]
2. Patch wrong metadata with model_overrides — for a local model no public registry knows, the capabilities Hermes infers may be wrong across the board. The v0.21.0 release notes describe this key as letting you "patch context windows, pricing, or capabilities for any model without waiting on a release", from PR #85560, merged on 13 August 2026; the settable fields are context_window, max_output_tokens, supports_tools, supports_vision, supports_reasoning and model_family.^[11]

# ~/.hermes/config.yaml — set the context yourself, then patch wrong metadata for a local model
model:
  default: your-model
  provider: custom
  base_url: http://localhost:11434/v1
  context_length: 64000

model_overrides:
  custom:my-local-vllm:
    my-llava-model:
      context_window: 8192
      supports_vision: true
    _default:            # fill-gap only: models the catalog does not know
      context_window: 32768

Finally, a caution I want to underline, because it circulates on forums until people take it as fact: several bug reports suggest setting a key called model.ollama_num_ctx. That key appears only in reporters' own text; I found it on no page of the Hermes Agent documentation, so it should not be repeated as though it were official. If you want to force Ollama's context, do it on the Ollama side with OLLAMA_CONTEXT_LENGTH or a Modelfile as in section 6 — that is the route the docs actually support.

8. Local First, Cloud as the Safety Net

The direct answer first: you do not have to choose a side. Hermes lets you make the local model your primary and keep a cloud model as the net that catches failures — and lets "side jobs", such as compressing a conversation or reading an image, run on a different model from the main one. This is the shape I actually use where sensitive work sits alongside ordinary work.

# ~/.hermes/config.yaml — local as primary, cloud as the safety net
model:
  default: "gemma4:31b"
  provider: "custom"
  base_url: "http://localhost:11434/v1"

fallback_providers:
  - provider: openrouter
    model: anthropic/claude-sonnet-4

auxiliary:
  vision:                                # image work goes to a second local server
    base_url: "http://localhost:1234/v1"
    api_key: "local-key"
    model: "qwen2.5-vl"

delegation:                              # every subagent goes to a local server
  model: "qwen2.5-coder"
  base_url: "http://localhost:1234/v1"
  api_key: "local-key"

The first block comes straight from the Ollama guide, which states the intent in one line: "This way, 90% of your usage is free (local), and only the hard tasks hit the paid API."^[3] You can also configure it from the command line with hermes fallback add, which reuses the same provider picker as hermes model and comes with list, remove and clear subcommands.^[7] Three things to know before you trust the mechanism:

• It does not fire for everything — the docs are explicit: 429 and 500/502/503 switch only after retries are exhausted; 401/403/404 switch immediately, because retrying is pointless; and repeatedly malformed or empty responses count too.^[7]
• The scope is per turn, not per session — every new user message starts with the primary model restored, and within a single turn fallback activates at most once, which stops cascading failover loops.^[7]
• It costs you the prompt cache in both directions — the docs warn that caches are keyed to the model (and on most providers the account), so the switch re-reads the whole history at full price, and the first request back on the primary is another full re-read; a session that bounces between providers is noticeably more expensive than one that stays put.^[7]

The last two blocks in the example are different mechanisms, and both are, I think, under-used. auxiliary.<task> separates the side jobs from the main model; the docs give image work and conversation compression as the examples, and stress that base_url takes precedence over provider — set a URL and provider resolution is bypassed entirely, while provider: auto means "use the main model".^[7] delegation: sends every subagent spawned by delegate_task to another model, which matters because that is where most of a run's tokens go^[9] — and the docs note that subagents inherit the parent's fallback chain.^[7]

If you want to go further — one model per agent, genuinely separated, with one agent on a local model for work involving personal data and another on the cloud for maximum capability — the mechanism is the profile, which is a separate Hermes home directory of its own. The next post, #3 Profiles, builds one step by step, including moving a profile between machines.

9. Summary

If this post reduces to one picture, that picture is Figure 1: three boxes on the left that differ enormously in how easy they are, all of which must pass through one gate before reaching the agent — at least 64,000 tokens of context, and the flags that make tool calls parseable. There is no way around that gate, and almost every problem people report is the problem of someone who believes they are already through it when they are not.

Three things I would do this week. One — open Settings → Providers → Local Models and see whether the menu is even there. If it is, look at the colour of every catalog row and write down which models come up green. That is your hardware's real ceiling, not a number somebody quoted at you. Two — if you already run Ollama, run ollama ps right now and read the CONTEXT column. My guess is that many readers will find 4096, and will understand immediately why their agent keeps "forgetting". Three — test with one real tool-using task rather than a knowledge question, because being able to chat is not being able to work.

The next post, #3 Profiles, takes up the question that arrives the moment you hold two models: which agent should use which, without editing config every time the work changes. The answer is the profile — a separate home directory with its own config, memory, skills and model.