The boring question in agent software used to be: did you finish setup?
The newer question is harder: can the product keep setup from becoming a separate ritual at all?
Today's code points at that shift. OpenClaw adds a keyless default web-search provider so search can work without an API key. Hermes moves tool backend installs into the desktop settings panel, exposes every model provider with setup affordances instead of hiding unconfigured ones, and starts surfacing credit state while a session is open. Codex adds a personal-access-token auth path that behaves like ChatGPT-backed account auth while keeping token metadata live and explicit.
The one-sentence map is this: setup is becoming runtime onboarding. Agent products are not only asking users to configure tools before work begins; they are building defaults, install buttons, auth modes, usage meters, and catalog context into the surfaces where the agent is already being chosen, run, or supervised.
Search gets a no-key path
OpenClaw commit 983b65b adds a free Parallel Search MCP provider named parallel-free. The commit registers it beside the paid Parallel provider, documents it as requiring no account or API key, implements a Streamable HTTP MCP client against https://search.parallel.ai/mcp, and adds tests around the transport and provider behavior.
The important movement is not just "OpenClaw added another search provider." The docs now place "Parallel Search (Free)" in the provider table as a key-free path, and the auto-detection section says OpenClaw defaults to it when no API-backed provider is configured. The setup flow was also changed so accepting the default writes the same provider the runtime would auto-detect, rather than a stale or alphabetic fallback.
That matters because search is one of the first places an agent can fail in front of a normal user. A model can have a web_search tool in theory, but if the first real call turns into "go get a key," the tool is not ready in practice. OpenClaw is trying to make the default path do useful work before the user understands the provider market.
The GUI starts running the missing install step
Hermes Agent commit 97524344 shows the same pressure from the desktop side. The toolset configuration panel already handled enablement, provider selection, and API-key controls, but providers with a post_setup hook still sent users back to the CLI. The patch replaces that instruction with a Run setup button.
The new PostSetupRunner calls POST /api/tools/toolsets/{name}/post-setup, polls the resulting action status, tails the log inline, updates the desktop activity rail, and refreshes the parent panel when the install finishes. The commit message names browser Chromium, Camofox, cua-driver, KittenTTS/Piper, ddgs, Spotify, Langfuse, and xAI as examples of backends that can need this post-setup path.
That is the difference between a settings panel that describes configuration and a settings panel that completes configuration. The user still has to make a choice, but the product is absorbing the follow-through: spawn the install, show the log, report completion, and re-check readiness.
Provider lists stop hiding the hard part
A second Hermes commit, e8c837c9, changes model/provider selection. The desktop GUI had been narrower than the hermes model CLI: onboarding showed a curated subset, while Settings often showed only authenticated providers. The patch makes the global model-options endpoint include unconfigured providers, picker hints, and canonical order, then teaches Settings and onboarding how to expose setup paths.
In Settings, selecting an unconfigured API-key provider now shows an inline "paste key -> Activate" flow and can auto-select a recommended default after activation. OAuth or external providers route into onboarding. The onboarding API-key catalog is no longer only a hand-curated list; it derives additional API-key providers from the backend model options and keeps the long tail scrollable.
This is a subtle but important product stance. Hiding every unconfigured provider makes the interface look clean, but it also hides the user's next move. Showing a provider with its auth type, key environment, and activation affordance turns absence into a guided step.
Credits become part of the session surface
Setup does not end once the model answers. Hermes commit fcb1944b is a large usage-aware credits patch that moves spend and access state into the agent experience itself.
The patch adds credit-state parsing, a notice policy, session-open seeding from account state, status-bar notices in the TUI, CLI REPL notices, messaging-gateway notice delivery, and a shared /usage credits block. The implementation has practical guardrails: notices are fail-open, a slow portal fetch should not block session readiness, non-finite money values are rejected, and messaging notices are plaintext one-shot pushes because chat surfaces do not have a persistent status bar.
That belongs in the setup story because cost and entitlement are part of whether an agent is actually usable. A user can have the right provider selected and still be blocked by depleted access, rollover accounting, a missing gauge, or a warning that arrives only after the first failed turn. Hermes is turning account-state visibility into an operational surface, not a billing page someone might remember to open later.
Auth gets a programmatic account lane
OpenAI Codex commit df7818c adds support for v2 personal access tokens through codex login --with-access-token and CODEX_ACCESS_TOKEN. The patch classifies opaque at- tokens separately from legacy Agent Identity JWTs, hydrates required ChatGPT account metadata through AuthAPI whoami, uses the PAT directly as a bearer token, and exposes the mode as personalAccessToken in the app-server protocol.
The careful parts are the story. PAT auth is intentionally stateless: metadata is hydrated in memory and redacted from debug output, while startup performs a live preflight so revoked tokens or changed account metadata are not accepted from stale cache. Codex also keeps unauthorized recovery on refreshable ChatGPT auth paths, not on personal-access-token auth, because a PAT is not the same kind of credential.
This is not a convenience flag bolted onto login. It is a distinct account lane with protocol shape, app-server compatibility, onboarding behavior, tests, and rollback considerations. For teams running agents in more automated environments, "paste a browser-managed login" is not the only setup path the product has to understand.
Catalogs also need product context
A smaller Codex commit, cdc8ec0, sends an OAI-Product-Sku: codex header on authenticated remote plugin-catalog requests. The test updates assert that the header is present when remote marketplace and installed-plugin requests are made.
On its own, this is a narrow plumbing change. In the setup-onboarding pattern, it is another clue: a plugin catalog is not a neutral file listing. It may need to know which product is asking, which account is authenticated, and which marketplace scope is being queried before it can return the right install surface.
The first run is becoming a live contract
The May 31 edition argued that agent tool menus are becoming runtime infrastructure. Today's evidence moves one step closer to the user's first successful run. It is not only whether the menu is truthful; it is whether the product can bridge from menu to working capability without making the user assemble the runtime by hand.
OpenClaw is using a keyless hosted Search MCP as the default path when no configured search provider exists. Hermes is putting post-setup installs, full provider catalogs, inline activation, and usage notices into desktop, TUI, CLI, and messaging surfaces. Codex is making personal access tokens a first-class account mode and sending product identity through plugin catalog calls.
This does not prove setup is solved. It does not prove the default search provider will fit every workload, that every Hermes backend install will succeed, that every provider catalog row is equally mature, or that PAT-backed auth should be treated exactly like browser OAuth. It does show the category consequence for agent products: onboarding is no longer a page before the agent starts. It is a live contract between advertised capability, credentials, install state, account limits, catalog context, and the first task a user expects the agent to finish.
The next thing to watch is whether agent products make that contract inspectable: not just "available" or "configured," but why a capability is ready, which default was chosen, what credential backs it, what cost state can stop it, and what repair step the interface can run without sending the user away.