The free tier is created in one place, at boot, only behind HERMES_GUEST_ONBOARDING=1 (NS-847)

[alt-glitch]

Hermes is a personal AI agent. It runs on four surfaces: the hermes command line, the messaging gateway (the bot that answers you in a Telegram, Discord or Slack direct message), the hermes serve backend, and the desktop app. Nous Research builds it and runs the account service the app signs in to (called "the portal" below).

The four PRs beneath this one build a free tier: an anonymous identity the portal issues without a sign-up. It gives an install one free model (nous/welcome) and a token for the connectors (the managed tools that need a Nous identity: web search, browser, Gmail, Linear and the other third-party integrations).

This PR, the fifth and last, decides two things on all four surfaces:

• When the identity may exist: only while the process was started with HERMES_GUEST_ONBOARDING=1.
• Who may create it: one routine, at boot.

With the variable unset, nothing on this page happens. A fresh install behaves exactly as main does today.

Words used throughout

Term	Meaning
free tier	the anonymous Nous identity above: one free model, connectors, no account
guest	what the code calls the free tier (guest_enabled(), nous.guest, HERMES_GUEST_ONBOARDING); identifiers that say anon_, "anonymous" or "welcome" mean the same thing
the portal	the Nous account service; it creates the identity and issues its short-lived tokens
mint	create a new free-tier identity at the portal (POST /api/anonymous/create)
provider	an LLM API vendor an install can use for inference: Nous, OpenRouter, AWS Bedrock, an OpenAI key, ...
own key	an install where the user configured their own provider API key
active_provider	the line in auth.json (the per-install credential file) that names the provider used for inference
the bootstrap	the one routine that runs at boot, checks which credentials exist, and creates the identity
launch gate	the environment variable HERMES_GUEST_ONBOARDING; exactly 1 turns the free tier on
serve	the backend process the desktop app talks to over JSON-RPC; setup.* and free_tier.* below are its methods
profile	a named, isolated Hermes configuration; the desktop can run one serve per profile
shared store	one file per machine (shared/nous_auth.json) that every profile reads, so two profiles on one machine share one Nous identity

The problem

Two problems, independent of each other.

No off switch. The only lever was a developer variable, HERMES_FORCE_GUEST. It turned the tier on, even over a user's explicit nous.guest: false. There was no way to ship the code dark.

Eight places could create the identity as a side effect of doing something else:

1. resolving a provider
2. the CLI's first-run check
3. the CLI's session setup, in the background, beside an own key
4. a connector token read
5. the desktop polling free_tier.status every minute
6. the sign-in precondition
7. the desktop's explicit provision request
8. the two dead-credential replacements (one for inference, one for connectors)

The consequences: a status poll could mint. Provider resolution could use the network. On a fresh install, the CLI first-run check (2) and the desktop status poll (5) raced each other. And every mint set active_provider, so an install with its own OpenRouter key switched to nous/welcome for inference after its first connector call.

flowchart LR
  subgraph Before
    A1["8 sites mint on demand"] --> B1["a poll or a resolve can call the portal"] --> C1["every mint sets active_provider"] --> D1["own-key install switches to nous/welcome"]
  end
  subgraph After
    A2["HERMES_GUEST_ONBOARDING=1?"] -->|no| Z2["today's behaviour, zero portal calls"]
    A2 -->|yes| B2["ONE bootstrap at boot"] --> C2["check first: does anything else do inference?"] --> D2["mint. set active_provider only if nothing else does"] --> E2["one setup.ready event. every other site reads"]
  end

Loading

What the user experiences after merge

Surface	Gate unset	Gate on, nothing configured	Gate on, own API key
CLI first run	provider picker, as today	free tier ready; hermes auth status nous says "Nous · free tier · nous/welcome"; the banner names welcome	your key does inference; one-time "free tier is here" notice
hermes serve boot	no portal traffic	one mint, one setup.ready	one mint (for connectors), active_provider unchanged
hermes gateway run boot	no portal traffic	one mint before adapters connect	one mint (for connectors), active_provider unchanged
Desktop first launch	classic picker	"Hermes is ready." screen + status chip	notice strip above the composer + chip; no ready screen
/login in a DM	not offered	link, code, "Signed in as you@…"	same
Portal calls per boot	0	1 create (+1 token exchange on first use)	1 create

Nothing in this PR changes what a signed-in account sees.

Before (Fresh install)	After (Fresh install)

Before (Own API key)	After (Own API key)

What changes

One gate

• guest_enabled() is the free-tier switch. It returns false unless the process environment has HERMES_GUEST_ONBOARDING=1.
• Only then is the user's nous.guest: false config setting read. That setting can only turn the tier off.
• Every free-tier site already goes through guest_enabled(). One check therefore closes identity creation, routing, the connector token, status lines and the picker row together.
• With the variable unset, a fresh install resolves no_provider_configured and shows the classic provider picker exactly as main does today. Zero portal calls.
• HERMES_FORCE_GUEST and its new re-mint mode are removed.

The desktop decides the gate once at launch, in apps/desktop/electron/guest-onboarding.ts:

• Source: the environment, or --guest-onboarding on the command line for a packaged app.
• It writes the decision as the LAST key into the environment of every backend it spawns: the primary serve, the pooled per-profile serves, and the command it runs over SSH when the backend is on another machine.
• Off is written as an explicit 0. A stray 1 in the parent shell cannot reach a backend the launch decided off.
• The renderer (the app's web view) reads the same value read-only through the existing launch-flags IPC.

One creator

ensure_portal_identity is the only function that calls the portal's create endpoint. It now raises unless called with explicit=True. It has four callers:

Caller	Runs when
hermes_cli/free_tier_bootstrap.py::run_bootstrap	every boot of the CLI, hermes serve, or hermes gateway run (the only caller that runs without a user asking)
free_tier.provision (desktop RPC)	the user retries after a boot that could not create the identity
dead-credential replacement, inference path	the portal retired the credential
dead-credential replacement, connector path	same

Three processes run the bootstrap: hermes serve on a daemon thread beside its other start-up work; the CLI synchronously before the first-run check; the messaging gateway (hermes gateway run) on an executor thread before any platform adapter connects, so a fast first DM cannot arrive with nothing to resolve. Every boot, in this order:

sequenceDiagram
  participant B as bootstrap
  participant R as resolve_provider
  participant P as portal
  participant S as auth.json
  participant C as connected clients
  B->>R: resolve_provider("auto", skip_free_tier=True)
  R-->>B: "openrouter" or AuthError(no_provider_configured)
  B->>P: POST /api/anonymous/create (gate on, and the shared store holds no identity)
  P-->>B: anon_ credential
  B->>S: write providers.nous
  B->>S: set active_provider="nous" only when nothing else resolved
  B->>B: record provider_configured, inference_provider, free_tier, has_identity, other_providers
  B-->>C: setup.ready (one event)

Loading

Everything else became a read:

Site	Before	After
resolve_provider, step 7 of its priority list	uses an existing identity, else blocks on a mint	uses an existing identity only. The free tier is still tried before the AWS Bedrock credential chain: a leftover ~/.aws profile is implicit host state and must not beat the tier on a fresh install
CLI first-run check	mint when nothing else configured	reads the identity the bootstrap made
CLI session setup beside an own key	background mint "so connectors have a token"	prints the one-time notice only
read_nous_access_token (connectors)	blocking mint on a token read	no identity → no token
free_tier.status (desktop poll)	started a background mint	pure read
run_sign_in precondition	minted so there was an identity to turn into an account	no identity → Unavailable

setup.status:

• For the launch profile it answers from the bootstrap's record.
• It blocks up to 8 s while the bootstrap is in flight, so the desktop's first poll returns after the identity exists instead of racing the mint.
• A named profile, or a process that never ran the bootstrap, keeps today's live probe.
• The record's five fields are added to the existing response. No existing field changes.

Identity and inference decoupled

• A mint sets active_provider = "nous" only when the check found nothing else usable.
• An install with its own key gets the identity for connectors and keeps its key for inference.
• Root cause of the own-key symptom: a token refresh used to re-set active_provider to the provider it refreshed. That write is how the own-key install ended up on the free tier after its first connector call. Refresh now writes credentials only (see the reviewer decision below).

The renderer listens instead of polling

• setup.ready arrives through the same path the app's other gateway events already use.
• It triggers one readiness round (setup.status + setup.runtime_check + free_tier.status), so the status chip, the notice strip above the composer and the first-launch overlay update at once.
• The 60 s status tick keeps only getStatus(). Readiness runs once on open, on return from another app, and on setup.ready.

Also in this PR

Each item is its own commit.

• Robin Fernandes' welcome-tier contract work, cherry-picked from the fork so his authorship survives: structured 429 refusals, the x-nous-model-switch header, and explicit provisioning over free_tier.provision.
• nous.guest_setup removed. Robin's commits add that interim config key. A later commit in this PR removes it, because the HERMES_GUEST_ONBOARDING gate does the same job (NS-845, recorded on NS-847).
• Model switch keeps the agent. A server-driven model switch off nous/welcome no longer evicts the cached gateway agent.
• Credits notice. is_free_tier_model learns that a model served from the welcome host is the free tier, so a free-tier identity never sees the "run /topup" notice (the portal reports $0 for it by design). Two tests the earlier prototype branch deleted (test_nous_welcome_host_is_free_without_pricing, test_paid_nous_host_still_needs_pricing_evidence) are restored.
• Banner. The CLI banner names the free tier's model instead of printing "no model configured" before credentials resolve.
• Copy. Sign-in text stops promising a connector transfer (the transfer registry that would make it true is empty, NS-821). The picker's off-state line no longer exposes the config key. The docs page carries the pre-release note. The zh locale gets real Chinese for the freeTier block.

One decision reviewers should weigh in on

A token refresh used to re-set active_provider for every OAuth provider, not just Nous (hermes_cli/auth.py::_save_provider_state_to_source, since commit 87d3fd38ee refactored auth.py). This PR makes refresh write credentials only.

• Why: it is what stops an own-key install switching to the free tier.
• Blast radius: every provider's refresh path. 771 tests across the auth, relay and Nous suites stay green.
• Revert cost: scoping it to Nous only is a two-line change in that function.

Two smaller decisions made inside the PR, recorded on NS-847: free_tier.provision stays as the desktop's explicit retry RPC; free_tier.ack_notice stays (it is a write by nature).

What this deliberately does not do

• No onboarding flow. The first-launch experience is a separate follow-up PR built on this one (NS-848): the intro animation, the guided setup chat on a dedicated hermes-setup profile, the hand-off from that profile into the user's own, and the card that sets up connectors.
• One fork commit left out on purpose. b3511e3af9 ("remove the faked accountless tier") from the hermes-magic fork is not here. Every file it touches belongs to the onboarding flow above.
• No user-facing docs launch. website/docs/user-guide/free-tier.md ships (feat(auth): Nous free tier: free inference and connectors out of the box, one command to sign in #105258 added it) with a pre-release note at the top. The note comes off at GA.
• No connector transfer on sign-in. The copy stops promising one. Whether to build it is a separate decision (NS-776 ruled guest connector policy unrestricted for now).

Where this PR sits

flowchart LR
  P1["#105258 free tier: identity, welcome model, hermes auth upgrade"] --> P2["#105259 sign-in moves the default model off nous/welcome"] --> P3["#105260 the free tier in the desktop app"] --> P4["#105261 /login from a chat DM"] --> P5["this PR: one gate, one creator"]

Loading

Each branch is the base of the next. This PR is built on #105261. The five merge in order as one train.

How to test

scripts/run_tests.sh tests/hermes_cli/ tests/agent/ tests/gateway/ tests/tools/ tests/tui_gateway/ tests/test_tui_gateway_server.py
cd apps/desktop && npx tsc -p . --noEmit && npx tsc -p tsconfig.electron.json --noEmit && npx vitest run

Invariants added:

• Only 1 (or the --guest-onboarding argument) opens the gate. "", 0, true and new leave zero portal calls.
• The bootstrap mints once per process. A second boot reuses the identity the first one made.
• The gateway runs the bootstrap before _start_prefilter_platforms, through the one creator (red on the tree without it).
• An own key keeps inference. The identity stays off active_provider.
• Every former mint site fails loudly if it ever calls the creator.
• setup.status reads the record.
• The sign-in yields Unavailable with no identity and zero portal calls.
• A model served from the welcome host counts as free without any pricing data.
• The spawn env carries 1/0 as its last key and preserves every other key.
• The banner shows the free tier's model when config names none.

Live verification

All cells run real subprocesses, the real serve start-up, or the real GatewayRunner.start against a local stand-in for the portal, in a fresh HERMES_HOME, gate on unless stated. Observed at commit c25611b374; the gateway rows at 8b31d1bc6a. CI on the current head is pending.

Cell	User action	Durable result	Invariant
CLI, gate unset	hermes auth status nous, resolve_provider("auto")	no auth.json entry	0 portal calls; no_provider_configured
CLI, fresh	first command	identity persisted, shared store mirrored, active_provider=nous	exactly 1 create, 1 token exchange on first use
CLI, own key	first command	identity persisted, active_provider unchanged	resolve_provider → openrouter; 1 create
CLI banner	first launch	welcome · Nous Research in the banner	gate off: the red "no model configured" line, 0 calls
serve boot	start-up, then setup.status	record ready=true, free_tier=true in 0.16 s	1 setup.ready frame; free_tier.status is a read
serve boot, gate unset	same	record has_identity=false	0 portal calls
gateway boot	GatewayRunner.start() in a fresh home	identity persisted, resolve_runtime_provider → nous, /login precondition sees the identity	exactly 1 create, before any adapter connects
gateway boot, gate unset	same	no identity, no_provider_configured	0 portal calls
mint once	CLI boot → serve boot → connector token → second CLI boot	one identity	1 create across all four
sign-in settles model	config.yaml on nous/welcome, hermes auth upgrade	providers.nous is the account; default moved off nous/welcome	1 promotion request, 1 token grant, 0 extra mints; no "connectors are kept"
/login from a DM	gateway handler, DM vs group source	account persisted	group refused before any call; DM gets link, code, waiting, "Signed in as…"

Desktop cells (ready screen, notice strip, status chip; gate on and off) are the screenshots under the user-experience table above.

• Each ran the real Electron dev app from the worktree against the same local portal stand-in, in a fresh HERMES_HOME.
• Left column: today's behaviour (gate off). Right column: gate on.
• Own-key cell: the status chip reads Nous · free tier · nous/welcome, active_provider stays unset, inference runs on the OpenRouter key.

[github-actions]

૮ >ﻌ< ა ci review

_{ran on 5554eb6 — fix(aux): vision on the free tier uses nous/welcome too}

⚠️ Warnings

CI timings · View report · View job

Wall time 5m25s vs 1m7s (+385.1%). 1 job(s) slower, 3 faster,

• Detect affected areas: -45.0s
• OSV scan / Emit review status: -4.0s
• OSV scan / Scan lockfiles / osv-scan: +3.0s
• All required checks pass: -1.0s

---

OSV vulnerability scan · View job

80 known vulnerabilities found in pinned dependencies.

• CVE-2026-83608 in package-lock.json
• CVE-2026-83608 in package-lock.json
• CVE-2026-84375 in package-lock.json
• CVE-2026-84375 in website/package-lock.json
• CVE-2026-67213 in website/package-lock.json
• CVE-2026-85062 in package-lock.json
• CVE-2026-85062 in website/package-lock.json
• CVE-2026-83609 in package-lock.json
• CVE-2026-82417 in scripts/whatsapp-bridge/package-lock.json
• CVE-2026-82417 in website/package-lock.json
• CVE-2026-84369 in website/package-lock.json
• CVE-2026-83605 in package-lock.json
• CVE-2026-83605 in package-lock.json
• CVE-2026-75931 in package-lock.json
• CVE-2026-75931 in website/package-lock.json
• CVE-2026-83610 in package-lock.json
• CVE-2026-83610 in package-lock.json
• CVE-2026-83611 in package-lock.json
• CVE-2026-83611 in package-lock.json
• CVE-2026-71554 in uv.lock

How to fix:

Review the findings in the Security tab. Update the affected dependencies if a patched version is available.

[alt-glitch]

This was generated by AI during triage.

@rob-maron Tagging you on this credits-notice item as the soft maintainer (follow-up to #43669).

[andrexibiza]

Reviewed the current stacked head 7f97992963c29012e8b7e61a1e008349ca5cf08a against base e8b90935dc695282b230d6ad913652c72dc55ae6, live main@564aef2946c436500a5e80ee117b66b789b3f99a, the full 64-file diff, the free-tier/auth/provider/gateway seams, the four lower train carriers, the overlapping welcome-tier work, existing discussion, and exact-head hosted CI.

There is one blocking lifecycle hole in the otherwise much stronger “one creator, at boot” design:

P1 — the standalone messaging gateway has no boot owner for the new creator.

This PR deliberately removes minting from every demand-time path: resolve_provider() now only consumes an existing identity; the connector-token read is a read; run_sign_in returns Unavailable when no identity exists; the former background/session/status mint paths are removed. That is the right direction. But the new creator is only actually invoked from two process entries in this diff:

• cmd_chat() calls run_bootstrap() synchronously;
• hermes serve calls start_background_bootstrap() from _lifespan().

The messaging gateway is a separate process path. hermes_cli/main.py::cmd_gateway delegates straight to hermes_cli.gateway.gateway_command; _cmd_run/run_gateway then enter gateway.run.start_gateway. Neither hermes_cli/gateway.py nor gateway/run.py invokes free_tier_bootstrap, and gateway/run.py::_resolve_runtime_agent_kwargs() eventually reaches resolve_runtime_provider() — which this PR intentionally made incapable of creating the missing identity.

So the cold-start sequence is now:

fresh HERMES_HOME + HERMES_GUEST_ONBOARDING=1 -> hermes gateway run -> no bootstrap -> no identity -> resolve_runtime_provider has nothing to consume -> no free-tier inference; and /login has the same problem because its precondition is now read-only and returns Unavailable without an identity.

That contradicts this PR's stated four-surface contract and is especially visible because #105261's feature is precisely the gateway-only user who may never open the CLI or Desktop. The live matrix here drives the /login handler, but it does not cold-boot the messaging gateway; the “mint once” matrix covers CLI/serve/connector/CLI, not hermes gateway run. I also found no gateway run cold-boot regression in the changed test surface.

Required closure: make the real messaging-gateway startup path a consumer of the same bootstrap authority before a first turn or /login can observe “no identity.” Keep the single-creator invariant — do not reintroduce demand-time minting. If it is started off-thread for startup latency, gateway readiness/first-turn eligibility needs to be coupled to the bootstrap record so a fast incoming DM cannot win the race. Please add a fresh-home, gate-on witness through the actual gateway startup seam proving exactly one /api/anonymous/create, persisted/shared identity, free-tier runtime resolution on the first gateway-created agent, and /login no longer returning Unavailable; pair it with gate-off = zero portal calls. Service-managed gateway run should inherit the same path automatically.

I checked the broad OAuth refresh change as well. _save_provider_state_to_source() is a refresh-state persistence seam, not the initial login/election seam, so making refresh credential-only rather than silently re-electing the refreshed provider is coherent with the authority split this PR is trying to establish. I do not see a separate blocker there from the current call graph.

The stacking/provenance shape is clear and should stay explicit. #105258 -> #105259 -> #105260 -> #105261 -> #107697 is the required merge order; these are complementary layers, not duplicates. #105552 is direct overlapping welcome-tier work: this head carries Robin Fernandes' first three commits forward with authorship preserved, then supersedes/refines their interim guest_setup policy into the launch-gated bootstrap. Please keep that lineage intact if the train is rebased or consolidated.

Exact-head hosted proof is green: CI 34527176827, Docker 34527175869, and Nix 34527176013 all succeeded on 7f97992963. The PR has 14 commits, though, and the other 13 current commit SHAs have no hosted workflow run attached, so by exact-commit evidence the surviving train is 1/14 commits proven hosted-green. That is not a code-local blocker to the gateway fix, but it is still a landing condition for this train.

The core architectural move here is good: creation authority is finally explicit, provider resolution is becoming a read, identity is separated from inference election, and the gate is stamped at the desktop process boundary rather than reconstructed downstream. Closing the missing gateway boot edge makes that invariant true across the whole four-surface shape rather than three of four. 🚀

[andrexibiza]

P1 — the creator is wired into hermes serve, but not the standalone messaging gateway. This line gives the serve/Desktop backend a boot owner; hermes gateway run takes the separate cmd_gateway -> hermes_cli.gateway::_cmd_run/run_gateway -> gateway.run.start_gateway path, and neither that path nor gateway/run.py invokes this bootstrap. Because this PR also makes resolve_provider, connector-token reads, and /login preconditions read-only, a fresh gate-on gateway can reach its first turn with no identity to consume. Please route the actual gateway boot through the same bootstrap authority (before first-turn readiness) and add a cold hermes gateway run/start_gateway witness: fresh home + gate=1 -> exactly one create + persisted identity + first gateway runtime resolves free tier; gate off -> zero portal calls.

[alt-glitch]

Confirmed and fixed in 09421f7a01. Your read of the call graph was right: cmd_gateway → hermes_cli.gateway → gateway.run.start_gateway → GatewayRunner.start never touched the bootstrap, and with every demand-time site now a read, a fresh gate-on gateway had nothing to consume.

Reproduced live before the fix by driving the real GatewayRunner.start() in a fresh HERMES_HOME against a local portal stand-in, gate on:

runtime_provider=None  runtime_error="AuthError: No inference provider configured"
has_nous_identity=False  signin_precondition_has_identity=False  portal calls: []

After: the runner calls free_tier_bootstrap.run_bootstrap on an executor thread right after startup recovery and before _start_prefilter_platforms, so no adapter is connected (and no DM can arrive) until the identity exists.

gate on : runtime_provider=nous  has_nous_identity=True  signin_precondition_has_identity=True
          portal calls: ['/api/anonymous/create', '/api/anonymous/token']
gate off: runtime_provider=None (no_provider_configured)  has_nous_identity=False  portal calls: []

Two notes on the shape:

• It is its own boot step, not part of _warm_turn_machinery_sync. The warm-up is an optimisation with an off switch (HERMES_STARTUP_WARMUP_TIMEOUT<=0 skips it); the bootstrap is correctness and has to run regardless.
• No demand-time minting reintroduced. ensure_portal_identity(explicit=True) still has the same four callers; the gateway reaches it only through run_bootstrap.

Test: tests/gateway/test_free_tier_gateway_boot.py pins the order (bootstrap before platform prefilter) and that the seam delegates to the one creator. Red on 5554eb6993, green on 09421f7a01. The PR body's live matrix and user-experience table now carry the gateway rows.

On exact-commit hosted proof: the train's lower rungs each have their own green PR CI on their current heads (#105258 cb3a1f447d, and #105259–#105261 are unchanged since their rebase). Intermediate commits inside a rung don't get their own hosted run on this repo; the PR head is the proven object. Happy to be told the landing bar is different.

[andrexibiza]

Current-head follow-up after the branch advanced from 7f97992963c29012e8b7e61a1e008349ca5cf08a to 5554eb69937e81483040296da0e89a3b6e8376e1 while I was reviewing it.

I inspected the one new commit (5554eb69937e81483040296da0e89a3b6e8376e1, Robin Fernandes / rewbs authorship preserved). Its scope is the welcome-tier auxiliary vision contract: on the welcome host _try_nous(vision=True) now uses the same nous/welcome route rather than skipping Nous, with the corresponding regression and docs change. That is consistent with the stated gateway contract/backing-model repoint and does not create a new blocker in the touched path.

The existing P1 remains fully current and its inline thread at hermes_cli/web_server.py:244 is still live/non-outdated: the free-tier bootstrap has a boot owner for cmd_chat and hermes serve, but not for standalone hermes gateway run. Since the rest of this train deliberately removed demand-time minting, a fresh gate-on messaging gateway can still reach provider resolution and /login without an identity. The required closure is unchanged: wire the real gateway startup/readiness path through the same single creator, and prove the cold gate-on/gate-off gateway path without restoring side-effect minting.

The new head’s hosted workflows are currently running: CI 34529125882, Docker 34529125050, and Nix 34529125054. The immediately previous head was green in all three, but that does not settle this new exact object. With the added commit the train is now 15 commits, so completion still requires exact hosted-green receipts for every surviving current commit, not only an ancestor.

Provenance remains especially important here: this new commit is another direct carry-forward of Robin’s #105552 work, so the #105258 → #105259 → #105260 → #105261 → #107697 train should preserve that authorship while #107697 supersedes/refines the interim creation-policy shape. The new aux change is complementary to the gateway-boot blocker; neither should erase the other.

Once the standalone gateway gets the same explicit boot authority as the other surfaces, the “one creator, at boot” invariant will actually hold end-to-end across the four advertised surfaces. 🚀

[kshitijk4poor]

Post-merge review of the merged head (4bdd64b334 on main). Ran the touched suites locally, traced the new call paths, and reproduced the items below on current main. Three are regressions worth a follow-up; the rest are smaller.

1. _nous_welcome_tier classifies every provider's 429, not just Nous — agent/error_classifier.py::_provider_special_cases calls it first with no provider check, and parse_welcome_refusal only looks at body["reason"]. Reproduced:

classify_api_error(<429 body {"reason":"rate_limited","retry_after":7}>, provider="openrouter")
  -> error_context["welcome_refusal"] set; turn_recovery prints
     "Nous free tier rate limit active — resets in 7s. Sign in with a Nous account ... /login."
classify_api_error(<429 body {"reason":"model_not_free"}>, provider="openrouter")
  -> FailoverReason.model_not_found, retryable=False   (was: rate_limit, retryable)

Fix: if c.provider_slug != "nous": return None at the top of _nous_welcome_tier, plus one negative test (openrouter 429 with reason → plain rate_limit, no welcome_refusal).

2. Gate-OFF CLI boot now pays the Bedrock/IMDS probe — cmd_chat runs run_bootstrap() synchronously before the first-run guard on every start. The bootstrap calls resolve_provider twice (inventory + _resolve_inference); each descends to the Bedrock rung → has_aws_credentials → botocore chain incl. IMDS, and has_aws_credentials walks the chain twice (resolve_aws_auth_env_var already ends with _boto3_chain_has_credentials(); the trailing or _boto3_chain_has_credentials() repeats it). Measured on a blank HERMES_HOME, gate unset, no ~/.aws:

	boto chain walks	wall
pre-PR (_has_any_provider_configured only)	0	~0.8 s
run_bootstrap, AWS_EC2_METADATA_DISABLED=true	4	+0.06 s
run_bootstrap, IMDS reachable-but-timing-out (laptop defaults)	4	+5.2 s

The run_startup.py comment "with the launch gate unset this is a local inventory and no network" doesn't hold. Fix, lightest first: skip run_bootstrap in cmd_chat when not guest_enabled(); derive inference_provider from the inventory call (if other is True its return value is the answer; else "nous" iff guest_carries_inference()) instead of a second resolve; drop the redundant chain walk in has_aws_credentials.

3. run_bootstrap holds _lock across _done.wait(8s) — a second concurrent caller stalls the full 8 s, and because the first caller then can't take the lock to publish, the waiter times out with _record is None, sets _started=True again and runs the inventory a second time. Reproduced: two callers 50 ms apart → 9.1 s total, inventory ran 2×. Gate-on that is a second mint attempt. Only serve+gateway in one process reaches it today, but the docstring's idempotency claim is false under concurrency. Fix: claim under the lock, wait outside it.

4. test_bootstrap_mints_once_records_and_a_second_run_is_free is red on any machine with ~/.aws/credentials — botocore finds them, other_providers=True, inference_provider="bedrock". The two siblings in the class stub agent.bedrock_adapter.has_aws_credentials; this one doesn't. Move the stub into _fresh().

5. Desktop flag pinned on only two spawns — desktopBackendSpawnEnv wraps the two hermes serve spawns and the SSH command; bootstrap-runner.ts, the post-update hermes gateway start, and the other CLI spawns in main.ts still inherit the parent shell's HERMES_GUEST_ONBOARDING. Setting the decided value on process.env once after GUEST_ONBOARDING is computed closes all of them.

Smaller, take or leave: gateway/run_startup.py could overlap the bootstrap with adapter connects and await it in _finish_startup_restore (inbound is already fenced by _startup_restore_in_progress); explicit: bool that must be True is a flag nobody sets — a rename says the same thing; guest_enabled() and has_guest() is inlined at auth.py/main.py where guest_carries_inference() exists; _nous_shared_shape hand-rolls is_guest_state with a raw "anonymous"; ctx["reset_at"] in the classifier duplicates what extract_api_error_context already sets (and that is what nous_rate_guard reads).

Also: the PR body's "blast radius: every provider's refresh path" for the set_active=False change is overstated — _save_provider_state_to_source is reached only through _provider_state_transaction("nous"); codex/qwen/minimax refresh via their own _save_provider_state and still set active. Nous-only, so no cross-provider regression there.