DEV Community: Zack Chew

The same word can be an answer or a silence signal

Zack Chew — Sun, 27 Sep 2026 03:39:55 +0000

An agent answering a yes-or-no question with NO can have its answer classified as silence in the group-turn implementation examined here. Change that answer to No, and the silence check returns false. Capitalization has become part of the conversation protocol.

I build OpenClaw Launch. This particular behavior comes from isSilentReply, a small function that decides whether returned text represents an intentional absence of a reply. Its accepted inputs extend beyond the instructed token, NO_REPLY.

The function first trims whitespace. An empty result immediately counts as silence. For other input, it removes a trailing run of periods, exclamation marks, question marks, and whitespace. It then accepts the exact uppercase token or any exact prefix of that token whose length is at least two characters and shorter than the full token. It never lowercases the text.

Here is a truth table derived from those rules. Quotation marks delimit test inputs, and backslash escapes represent whitespace. The table specifies expected results for regression fixtures.

Input	`isSilentReply`
`""`, `" "`, `"\t\n"`	`true`
`"NO"`, `"NO_"`, `"NO_R"`, `"NO_RE"`, `"NO_REP"`, `"NO_REPL"`	`true`
`"NO_REPLY"`, `" NO_REPLY "`, `"NO_REPLY.!?"`	`true`
`"NO!"`, `"NO_R?"`	`true`
`"N"`, `"N!"`	`false`
`"No"`, `"no"`, `"no_reply"`	`false`
`"."`, `"!?"`	`false`
`"NO_REPLY,"`, `"NO_REPLY…"`	`false`
`"NO REPLY"`, `"NO_REPLY please"`	`false`

The punctuation-only row follows from the order of operations. The initial trimmed string is nonempty, so it passes the blank check. Removing its punctuation leaves an empty string, which satisfies neither later condition. There is no second blank check.

These distinctions have an observable consequence in the runner. For a successful result without an attachment URL, a true silence check emits a line for persistence with status set to silent and empty content. The original token disappears from that line. The member has already been marked as having spoken, and this branch ends without planning a handoff. An attachment URL bypasses this silence branch, while a truthy error takes an earlier error branch.

A plain NO is therefore ambiguous. It can be a substantive negative answer in ordinary language, or an accepted prefix of the control token. The function has only the characters to work with. The handoff prompt asks for the complete token, but that instruction does not narrow what the parser accepts.

I would use an explicit structured outcome carrying a reply-or-silent discriminator separately from text. That is a design proposal, absent from this implementation. It would allow a negative answer to remain content without asking capitalization to settle its meaning. The receiving code would still need to validate the discriminator and define how silence interacts with attachments and errors.

Before changing the protocol, I would keep the table as regression fixtures and add runner-level assertions for stored content and consumed turns. A parser change can alter which answers readers see even when the generated words stay exactly the same.

Why an Agent Mention Needs a Round-Trip Test

Zack Chew — Tue, 22 Sep 2026 06:24:19 +0000

An agent-routing prompt should advertise only handles that its resolver can send back to the intended member. Generating a plausible handle covers half that contract. The other half requires resolving it against the actual group membership and checking the returned identity.

I build OpenClaw Launch. Its group-routing helper makes this check explicit. The behavior described here belongs to that helper; other systems can define mentions differently.

Two transformations, one destination

The first transformation starts with a display name. mentionHandle keeps Unicode letters and numbers, underscores, and hyphens. It removes spaces and other punctuation. This produces a token that can appear after an @ without breaking at a space.

Resolution applies another transformation. resolveMentions extracts tokens containing the same allowed characters. It then uses slug to lowercase the token and remove everything except Unicode letters and numbers. Underscores and hyphens survive handle generation but disappear during matching.

That difference creates possible collisions. Distinct display names can produce handles that compare identically. A successful string transformation gives no assurance that the destination is unique.

Consider this tiny illustrative example with invented test labels. Member m1 is named Cedar Lab!. Its generated handle is CedarLab, and @CedarLab resolves to m1 when that is the only matching member. Add member m2, named Cedar-Lab. Both display names now have the slug cedarlab. Resolving either generated handle produces no recipient because the match is ambiguous. These examples show the resolver’s expected behavior.

The resolver deliberately skips a token unless exactly one member matches. It first compares complete display-name slugs. Only when that produces no matches does it try individual whitespace-separated words from display names. A short mention can therefore work when its word match is unique. An ambiguous complete-name match never proceeds to that fallback.

This ordering deserves its own test. A member whose entire normalized name matches a token takes precedence over members that contain the token as one word. Testing only familiar short names would miss that distinction.

Unicode letters are supported by the regular expressions, so a name does not need to use Latin characters. There is still a narrower boundary here. The helper performs no Unicode normalization, and its allowed categories exclude combining marks. Precomposed accented letters and visually similar decomposed sequences can consequently transform differently. Include both forms if your naming interface accepts them.

Resolve the handle back to its intended member

The prompt builder closes the round trip before advertising another member. It generates that member's handle, resolves @handle against the full membership list, and requires exactly one result with the same member ID. Checking the ID matters. Merely finding some unique recipient would allow a handle to point at the wrong person.

Using the full membership list also matters. A member who is unavailable for this turn can still make another name ambiguous. Removing unavailable members before checking uniqueness would validate against a different namespace from the resolver's actual input.

Test routing separately from delivery

Recommended tests can follow these boundaries directly. For each advertised handle, assert that resolution returns exactly its intended ID. Include spaces and punctuation in the fixtures, then add colliding names. Check an empty generated handle separately. Exercise Unicode names and decomposed accents, and verify that repeated mentions return a member only once.

After resolution, test recipient eligibility independently. selectRecipients excludes the sender and members already recorded as having spoken. A correctly resolved mention can therefore produce no scheduled recipient.

Those checks cover the helper contract. A separate end-to-end test should carry the advertised handle through generated reply text, recipient selection, and actual delivery. Inspecting these functions alone cannot establish that the last step happened.

Get a Second Opinion from Hermes and OpenClaw in One Chat

Zack Chew — Sun, 13 Sep 2026 11:40:54 +0000

Compare both bots' replies in one conversation, without copying the first answer into another chat.

In a live test, a group chat was asked for two opinions on a simple question: should a new startup use Postgres or MongoDB?

OpenClaw answered first. Then it brought Hermes into the conversation to give its own recommendation. The user had not typed an @mention or copied the answer into another chat.

Both picked Postgres, but explained the choice differently. OpenClaw focused on database features. Hermes focused on how uncertain a startup's future queries can be. The useful part was being able to read both replies, with each one attributed to the bot that produced it.

I build OpenClaw Launch, and this is now possible in the website's group chat: you can put Hermes and OpenClaw bots in one conversation and let them pass a question to each other.

How the conversation works

A group has a default bot: the first one you select when creating it. Send a message without addressing anyone, and that bot gets the first turn.

It can answer directly. When another perspective is useful, it can mention another member of the group. That sends the receiving bot your original question together with the first bot's reply. The receiving bot then answers under its own name in the same conversation.

You can also address a specific bot yourself with its @mention. Asking for a second opinion gives the default bot a clear reason to involve someone else, without requiring you to route every message manually.

For someone who already asks two agents to review the same decision, this puts the exchange in one place. You can follow the question, the handoff, and the response without moving the first answer between separate chats.

Try it with your own bots

Start with a running Hermes bot and a running OpenClaw bot in your OpenClaw Launch account.

Open the dashboard's chat sidebar and click the + button.
Choose “Create group chat.”
Give the group a name and select the bots to include. Pick your preferred default responder first.
Create the group and send a question that would benefit from a second perspective.

A useful first prompt is:

Give me your recommendation on this decision, explain your assumptions, and ask another bot in this group for a second opinion.

Add the decision and the relevant facts underneath it. For a writing task, include the draft. For a technical choice, describe the constraints. The more self-contained the question, the less the receiving bot has to guess.

Look for a reply attributed to the second bot. That is how you can tell it actually joined the exchange.

Give each bot a clear job

A second opinion is the easiest place to start because the request has a clear endpoint. One bot gives its recommendation, another examines it, and you decide what to do with the answers.

You can make the request more specific as well. Here are two examples to try:

Review a draft: ask one bot to propose a version, then ask another to identify unclear wording or unsupported claims.
Review a plan: ask one bot to outline the steps, then ask another to look for missing prerequisites and assumptions.

These are suggested workflows, not measured results. What the bots can contribute depends on their models, instructions, and available tools. Naming a bot “researcher” does not give it access to sources it cannot already reach.

For a first group, I would start with two bots and one concrete question. It is easier to judge whether the extra reply helped when you know what you wanted it to check.

What is shared, and what stays separate

The group gives you one visible conversation. Each bot remains a separate agent with its own setup. Creating a group does not merge their private chat histories, files, or tools.

The handoff carries your question and the sending bot's reply. If a task depends on a document or detail from elsewhere, include the necessary information or make it accessible to the bot that needs it.

The second bot also sees the first bot's answer. This is a second perspective in a conversation; it is not a blind evaluation. Agreement does not prove a conclusion is correct, and disagreement still needs your judgment.

Each additional bot response involves another agent run, so it adds model usage. Group chat bounds the number of handoffs and prevents the same member from being called repeatedly within one user turn. That keeps the exchange finite; it does not make additional replies free.

Start with a question you already ask twice

If you already take a draft, a plan, or a technical decision to more than one agent, try that same task in a group. Read what each bot adds and whether its assumptions hold up.

Hermes and OpenClaw group chat is available on OpenClaw Launch. Create a group with your bots and ask for a second opinion.

The question I want to explore next is which pairings add useful information, and when a single bot would have been enough.

OpenClaw + GLM 5.3 Flash — Opus-Class Scores at Flash Cost

Zack Chew — Thu, 27 Aug 2026 14:14:22 +0000

For a week an anonymous model called ox-alpha sat at the top of OpenRouter and OpenCode with nobody knowing who made it. On 26 August 2026 Z.ai (Zhipu AI) revealed it as GLM 5.3 Flash and open-sourced the weights under MIT the same day. Here is what it actually is, what the benchmarks support, and how to run it on an OpenClaw agent.

What GLM 5.3 Flash Is

GLM 5.3 Flash is a mixture-of-experts model with 320 billion total parameters and about 18 billion active per token. It is the first natively multimodal model in the GLM-5 series — text, images and video go in, text comes out — and unlike GLM 5.3, which was a post-training re-tune of GLM 5.2's base, it starts from a newly trained base model.

Despite the name, it is not a distilled small sibling of GLM 5.3. It is a different architecture aimed at a different goal: keep frontier-level capability while cutting the cost of serving it. Z.ai reports that against GLM 5.3 it reduces attention compute by 3.01x and KV cache size by 4.44x.

Hybrid sparse + linear attention — linear attention models local dependencies, a lightweight sparse indexer retrieves global context. Z.ai calls it the first open-source frontier model to combine the two.
mHC (Manifold-Constrained Hyper-Connections) for scaling efficiency, plus IndexPool, which compresses four indexer key vectors into one to keep 1M-token contexts affordable.
30T-token multimodal pre-training corpus, and 45 layers against the 92 of the similarly sized GLM-4.5.
MIT license, weights published at launch — a notable contrast with GLM 5.3, which shipped API-first with Zhipu saying weights would follow about two weeks later.

The ox-alpha Reveal

Z.ai confirms it tested the model anonymously as ox-alpha on OpenCode and OpenRouter before release to collect unbiased user feedback, and that it became the most popular model of that week. Both of those are Z.ai's own account of its pre-launch testing rather than an independent audit. Z.ai also states that all of that traffic was served on Chinese AI chips, on an SGLang-based inference stack it built for the architecture.

The Benchmark Numbers

Artificial Analysis scores GLM 5.3 Flash at an intelligence index of 57.5, with 71.5 on coding and 58.2 on agentic tasks. Placed next to Claude Opus 4.8 on the same index, the shape of the result is specific rather than a blanket win:

Model	Intelligence	Coding	Agentic	Price (in / out per 1M)
GLM 5.3 Flash	57.5	71.5	58.2	$0.075 / $0.25 (promo; $0.15 / $0.50 list)
Claude Opus 4.8	57.3	74.3	49.4	$5.00 / $25.00
GLM 5.3	59.5	74.8	59.1	$1.40 / $4.40
GLM 5.2	52.6	68.8	45.7	$1.40 / $4.40

Read that honestly: GLM 5.3 Flash is level with Opus 4.8 on the composite index, ahead on agentic work, and behind on coding. The price gap against Opus is roughly 1/70 on input and 1/100 on output at today's promotional rate — still about 1/33 and 1/50 once it reverts to list. And it is not ahead of GLM 5.3 on any of the three: it is close, for about 5% of GLM 5.3's token cost today and around 11% at list price.

Z.ai's own reported results, which are vendor numbers and should be read as such, put it at 63.4 against GLM 5.2's 46.2 on DeepSWE v1.1, and 48.8 against 26.2 on AutomationBench. On Z.ai's internal Code Bench v1.0 at max effort it reports 29.0 against Opus 4.8's 29.5.

Pricing, and the Part That Expires

The headline price is a limited-time discount, not the list price. Z.ai's published rates per million tokens:

	List	Limited-time
Input	$0.15	$0.075
Cached input	$0.03	$0.015
Output	$0.50	$0.25

Budget against the list price if you are planning a workload that has to survive the promotion ending. Even at list, $0.15 / $0.50 is roughly a tenth of what GLM 5.3 costs. Cached-input storage is currently free for a limited time as well.

If you subscribe to the GLM Coding Plan instead of paying per token, Z.ai gives GLM 5.3 Flash three times the quota of GLM 5.3 under its points system, and charges half points off-peak and all weekend.

How to Run GLM 5.3 Flash on OpenClaw Launch

GLM 5.3 Flash is available through OpenRouter as z-ai/glm-5.3-flash and directly from Z.ai as glm-5.3-flash. Both routes work with a bring-your-own-key setup:

Deploy an agent — about 30 seconds. Bring-your-own-key model selection needs a paid plan; the free trial runs on a fixed set of free models, so use it to check the product, not this model.
In your dashboard, add your OpenRouter key (or a direct Z.AI key) under BYOK settings.
Open the model picker and type glm 5.3 flash. Searching reveals the live provider catalog, not just the curated shortlist, so the model appears as soon as your provider lists it — no redeploy, no config file.
Select it. The change applies to the running agent immediately.

Tip: switch between GLM 5.3 Flash, GLM 5.3, DeepSeek and Claude at any time from the dashboard or with the /model chat command. A common setup is GLM 5.3 Flash as the everyday driver — cheap enough to leave running on a busy group chat — with a frontier model reserved for hard reviews.

Self-Hosted Configuration

Running OpenClaw on your own server? Point the default agent at the model in your openclaw.json:

{
  "models": {
    "providers": {
      "openrouter": {
        "apiKey": "sk-or-..."
      }
    }
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "openrouter/z-ai/glm-5.3-flash"
      }
    }
  }
}

Confirm the current slug on openrouter.ai/models before deploying rather than copying it from any guide, including this one — provider IDs shift between releases and a stale slug surfaces as a model-not-found error. Using a direct Z.AI key instead? Configure it as an OpenAI-compatible provider with its own base URL.

Three Things That Will Surprise You

Thinking cannot be turned off. Reasoning is mandatory on this model — Z.ai's API accepts only thinking.type: "enabled", and OpenRouter reports reasoning as mandatory with a default effort of max. If you are used to disabling reasoning to cut latency and output tokens on cheap models, that lever does not exist here. Budget for reasoning tokens in your output cost.

Z.ai's recommended settings are unusual. Temperature 1, top_p 0.95, reasoning_effort: max, and thinking.clear_thinking: false. For streaming, enable both stream and tool_stream.

The context ceiling is provider-dependent. OpenRouter advertises up to 1,310,720 tokens across providers but the top provider serves 1,048,576 with a 131,072 max completion. Long-context agent runs should be planned against the endpoint you are actually billed by, not the maximum in the catalog.

Running the Weights Yourself

The weights are MIT-licensed and published as zai-org/GLM-5.3-Flash on Hugging Face, with official serving recipes for SGLang, vLLM, TokenSpeed and KTransformers. 320B total parameters is still a serious hosting commitment even at 18B active — the practical local path is a quantised community build rather than the full BF16 checkpoint. If you want the agent running today, an API key is the shorter road.

When to Pick It

Pick	When
GLM 5.3 Flash	High-volume agent work, long-running tool loops, screenshot- or video-driven tasks, anything where per-token cost decides whether you can leave it running
GLM 5.3	You want the strongest GLM on hard coding and security review and the cost difference does not bind
DeepSeek V4	Text-only workloads where you already have DeepSeek keys and pipelines
Claude Opus	Coding is the whole job and the last few benchmark points are worth two orders of magnitude on the bill

The interesting case is the one that was not viable before: an agent that watches a chat, calls tools all day, and reads screenshots, running continuously without the token bill becoming the reason you turn it off.

Deploy with GLM 5.3 Flash

Get an agent running on a model that matches Opus 4.8 on the intelligence index for a fraction of the token price, in about 30 seconds. Bring your own OpenRouter or Z.AI key.

Deploy an agent at openclawlaunch.com

I run OpenClaw Launch, a small hosted service for OpenClaw and Hermes agent bots, which is where the setup steps above come from.

Hermes Agent System Requirements — RAM, CPU, Disk, Python, OS 2026

Zack Chew — Sat, 22 Aug 2026 12:06:23 +0000

Hermes Agent runs comfortably on modest hardware for chat-only workloads, but the browser toolset and large model contexts push memory and disk fast. Here's the minimum, the recommended, and where the bottlenecks actually are in 2026.

At a Glance

	Minimum	Recommended
RAM	1 GB	2–4 GB
CPU	1 vCPU	2 vCPU
Disk	2 GB	10 GB+ (with browser toolset)
Python	3.11	3.12 or 3.13
Node.js	Installed for you — only the browser toolset uses it
OS	Linux / macOS / Windows / WSL2	Linux x86_64 or arm64
GPU	None	None (models are remote)
Network	Outbound 443	Outbound 443 + inbound for webhooks

RAM

We host Hermes Agent, so rather than estimate, we measured. Across 31 live Hermes containers on our fleet, resident memory came in at a median of 282 MB, with a minimum of 139 MB and a maximum of 858 MB. Those are real resident figures, not values clamped by a container limit — the containers are capped at 2–4 GB and nothing was close to its ceiling.

The number that matters for sizing is the peak, not the median. A container caught mid-response — actually generating, tools running — touched 1.1 GB. That is the figure to size against, because it is what your box has to absorb on a busy turn. Large context windows (Claude 200k, Gemini 1M) push the working set up transiently in the same way.

A separate browser container adds only 8–95 MB at idle, which is far less than people expect — the cost of the browser toolset is mostly disk and burst, not steady-state memory.

For a single-user VPS, 2 GB is comfortable. For multi-user managed hosting, plan on ~1 GB per concurrent active container.

Worth knowing before you over-buy: the browser toolset is not on by default. It ships as a core toolset but stays inactive until you add browser to toolsets in your config. So the higher numbers on this page are a ceiling you opt into, not the baseline you start from — a stock install sizes against the chat-only figures.

CPU

Hermes Agent is mostly I/O bound — it waits on model responses, network webhooks, and disk reads. 1 vCPU is enough for low-volume use; 2 vCPU helps when the browser toolset is rendering pages or skills do CPU-heavy parsing (PDF, video).

Measured on the same 31 containers: an idle Hermes agent sits at 0.2–0.7% CPU. It is doing essentially nothing while it waits. But a container actively generating a response was caught at over 100% — a full core saturated. That gap is the whole story of sizing Hermes: idle cost is close to zero, so what you are really buying is headroom for concurrent bursts. One agent that is busy 5% of the time and 20 idle agents cost about the same.

Disk

The base install is small (under 500 MB), but the workspace at ~/.hermes grows with chat history, embeddings, and any files your agent touches. Enabling the browser toolset pulls a full Playwright Chromium plus per-session profile data, which is the single biggest jump in disk use. For reference, the official multi-arch Docker image is roughly 900 MB compressed before any of your data. Plan on:

2 GB — minimum, chat-only, ephemeral workspace
10 GB — comfortable for browser toolset + memory store
20 GB+ — if you keep long chat history and large skill data

Python Version (Not Node.js)

Hermes Agent is a Python project, and this trips people up constantly because so much of the agent ecosystem is Node. The requirement is Python 3.11 or newer, below 3.14 — the upper bound exists because Rust-backed dependencies like pydantic-core don't ship wheels for 3.14 yet.

You mostly don't install Python yourself. The official installer provisions it through uv without sudo, so a clean box needs no manual Python setup at all.

Node.js does get installed — the installer bundles v22, and the official Docker image builds on Node 26 — but it is a secondary dependency, not a version you choose. It exists to run the browser automation (agent-browser, resolved via npx on first use) and the WhatsApp bridge. If you never enable the browser toolset, Node sits unused. So "what Node version does Hermes need?" is the wrong question to size a box around; Python is the runtime that matters.

OS Support

Linux — first-class, x86_64 and arm64
macOS — Intel and Apple Silicon, dev environments only
Windows — natively, via the PowerShell installer; WSL2 also works
Docker — the official image works on any OS that runs Docker

GPU? No.

Hermes Agent does not run local model inference. Model calls go to remote providers (OpenRouter, Anthropic, OpenAI, etc.) over HTTPS. You do not need a GPU. If you want local inference, point Hermes at a local Ollama or LM Studio endpoint — the GPU lives on the inference server, not the Hermes box.

Network

Outbound 443 to your model provider (required)
Inbound 80/443 if you accept channel webhooks (Telegram, Slack, etc.)
Outbound to ClawHub / skill registries if installing skills at runtime

Sizing Cheat Sheet

Personal bot, chat-only: 1 vCPU / 1 GB RAM / 5 GB disk — any $4–5/mo VPS
Personal bot + browser toolset: 1 vCPU / 2 GB RAM / 10 GB disk
Team bot, 5–10 concurrent users: 2 vCPU / 4 GB RAM / 20 GB disk
Production, 50+ concurrent: 4 vCPU / 8 GB RAM / dedicated node

Skip the Sizing

OpenClaw Launch hosts Hermes Agent on right-sized containers with the browser toolset, memory store, and channel webhooks pre-wired. Plans from $3/mo.

Originally published at openclawlaunch.com.

Pinning an agent harness is harder than pinning its package

Zack Chew — Sat, 15 Aug 2026 13:26:09 +0000

DeepSeek shipped its own agent harness this week. MIT, developer preview, and the architecture is the interesting part: everything in it is a plugin, including the pieces you would expect to be the program.

We had a reason to look closely, because we put it into a container image that other people run. That means pinning it, and pinning it turned out to be a different job from pinning the package.

The launcher is thin

dsh is a small commander-based launcher. It parses a few flags of its own, then hands the rest of the argv to a booted app that has its own parser. Almost nothing you care about is in the launcher.

That matters because dsh depends on its own family through caret ranges. Pin @deepseek-ai/dsh at an exact version and you still get @deepseek-ai/dsh-base and @deepseek-ai/dsh-headless at ^0.1.0-rc.6. The permission rows, which decide what the agent may touch, ship inside dsh-base as a patch layer. The parsing that decides whether your task text is a task or a flag lives in dsh-headless.

So the failure mode is quiet. Rebuild the image a week later, after either dependency publishes, and the behaviour of every run changes. Meanwhile dsh --version prints exactly the version you pinned, and every test that checks the version passes.

The fix is a build-time assert on the whole family rather than the launcher alone.

Two dashes, not one

The second thing cost an hour. Running a task by hand works the way the docs show:

dsh --profile headless "run the tests"

Send the same task through a runner that builds argv programmatically and it arrives as flags instead of a prompt. The launcher consumes one -- separator and the booted app consumes another, so a task passed positionally needs both:

dsh --profile headless -- -- "run the tests"

The reason this is worth writing down rather than shrugging at is the silent-success case. If the task text happens to begin with something that parses as a flag, you do not get an error. You get exit code 0, no output, and a run that did nothing. That is the worst shape a bug can have in an unattended pipeline, because nothing downstream notices.

What the sandbox actually does

The permission mode moves both the approval policy and the sandbox together, which is convenient right up until you assume the sandbox is doing something it is not. In our image it is not. The default confinement relies on bwrap, which is absent there, and on Landlock, which is unreadable in that context. On macOS the same setting confines through Seatbelt and genuinely does what it says.

So the honest description of a container run is that the confinement is advisory. That is fine when the container is the boundary you are relying on, which it is for us, but it is worth knowing which layer is actually holding the line rather than assuming it is the one named in the config.

Where this leaves it

None of this is a complaint about a package that has been public for a couple of days and says plainly that it is a developer preview. It is what a plugin architecture costs on the operations side: when everything is a plugin, the version number of the thing you installed stops describing the thing you are running.

If you want to try it without any of the above, it is npx and a key. If you want it to behave the same next month, assert the family.

Five things I disabled before installing a vendor's agent runtime

Zack Chew — Thu, 13 Aug 2026 08:08:31 +0000

Two services I connected recently both call the thing they ship a "skill". One is a hosted endpoint. The other is a zip file. The review those two need has almost nothing in common, and I do not think the word is doing anyone any favours.

Luckin Coffee runs an MCP server at their own domain. My agent sends JSON-RPC over HTTPS, and their code stays on their machines. The questions there are the familiar ones. What can it see, what scopes did I grant, can it spend my money.

Quark Drive, Alibaba's consumer cloud storage, ships a package instead. You download a zip, unpack Node scripts, and those scripts run inside your agent's process with your filesystem and your egress. The question is no longer what you granted. It is what that code does while it sits there.

Credit where it is due

Quark distributes the runtime from its own manifest and CDN, and authorization goes through an official OAuth endpoint scoped for agents. The token lands in the user's own instance and nobody proxies it.

That matters because the alternative, which I have also written adapters for, is scraping a website's internal endpoints and praying they do not rotate. A vendor that publishes a real package and a real OAuth flow is doing the right thing.

Which is exactly why it is worth reading the package instead of assuming.

What is inside is a CLI's habits

I unpacked version 1.0.11 and read it. What I found is what a desktop command line tool would reasonably ship.

Telemetry sampling is hardcoded at 1, so every event goes up. One call hands the raw user query to the telemetry client. Another reports a session id. The startup chain includes a self updater.

For a tool you open, use, and close, all four are defensible. Full-rate telemetry on a young product is how you find bugs. A self updater means users get fixes without being told to upgrade.

Now move the same code into a process that runs for months, holds a user's cloud storage token, and shares an address space with other skills.

The raw query stops being a search string. In an agent it is frequently the user's actual sentence, which carries filenames and people and reasons. And the self updater means the code you reviewed on Tuesday is not necessarily the code running on Friday. On a desktop that is a feature. For something holding a user's files, I would like to know when it changes.

What the install actually does

Version pinned at 1.0.11. Archive URL and SHA-256 both hardcoded. Download, hash, and abort on mismatch before anything is unpacked.

After unpacking, copy exactly two files, scripts/quark-drive.cjs and scripts/hash-worker.cjs, after asserting both exist. The upstream install.sh never runs.

Then five targeted edits to the runtime:

sampleRate:1 becomes sampleRate:0
the telemetry client constructor becomes a Proxy whose every method is a no-op
the setRawQuery call becomes a discard
the setSessionId call becomes a discard
the self updater is removed from the startup chain

A wrapper sits outside all of it and refuses update, --verbose, --session-input, --session-id and --raw-query with exit code 2. Execution goes through env -i so the child gets HOME, PATH, LANG, BROWSER=false, CI=1 and nothing else.

Upgrades stage into a temp directory, move the old tree aside, and roll it back if the swap fails. The user's existing config.json holds their OAuth token, so it is checked with lstat for being a regular file under 1 MiB before being copied forward, into a 700 directory at 600.

The part worth stealing

Every one of those five edits asserts an exact occurrence count before it applies. Three for the sampling pattern, one each for the rest. If the count is off, the install throws with the label and the number it actually found.

unexpected quark runtime: self updater (0)

Here is why that matters more than the edits themselves. When upstream refactors, a naive string replace matches nothing and reports success. The install completes, the tree looks right, and the telemetry and self updater are running exactly as they always were. You are now shipping a build you believe is hardened and is not.

Counting turns that silent success into a loud failure. I would rather the install break and make me read the new version than have it quietly hand me a false sense of what I disabled.

That generalizes past this package. Any time you patch someone else's code as part of a build, assert the shape you expected to find. A patch that no-ops is worse than a patch that fails, because only one of them tells you.

The question I ask now

Services decoupling from platforms is real. Capability ships as a skill, every agent can read it, and the aggregator in the middle stops being mandatory.

What changed underneath is where the integration lives. Calling someone's API and hosting someone's code are different risks wearing the same word. The worst case for the first is that you do not get your data. The worst case for the second is behaviour you did not ask for, running next to everything your agent can reach.

So the first thing I want to know about a new skill is whose machine it runs on. For a hosted endpoint, read the scopes and find out whether it can spend money. For a package, find out whether the self updater can be turned off, what it reports, and whether you can pin a version and verify it.

The Quark package works well once it is pinned. Search, upload, download, share and save all behave. Its AI summarization sends the selected file's contents back to Quark, which is the sort of thing a user should get to decide for themselves rather than discover later.

I run a small hosted service for agent bots and this is one of about 135 connectors we maintain, so I read a lot of these packages. openclawlaunch.com

Nous Portal, Explained: Plans, Models, Tools, and Hermes Cloud

Zack Chew — Sun, 02 Aug 2026 12:36:29 +0000

What is Nous Portal?

Nous Portal launched on April 27, 2026 as Nous Research’s subscription product for users who want to run Hermes Agent without managing API keys for every model and tool provider. One subscription replaces logins to a model gateway plus Firecrawl, FAL, Krea, Browser Use, OpenAI audio, and Modal — Portal routes all of those behind a single authenticated session. Since then it has also grown a hosting product, Hermes Cloud, covered below.

The free tier is $0/mo and carries $0 in monthly credits — it gives you the free-model catalog and standard rate limits only. Every paid tier adds a credit budget with a 10% bonus, the bundled Tool Gateway, and higher rate limits.

Portal plans

Free: $0/mo, $0 monthly credits (free models only), no rollover, 50 RPM / 500K TPM
Plus: $20/mo, $22 in credits, $10 rollover cap, 400 RPM / 4M TPM
Super: $100/mo, $110 in credits, $50 rollover cap, 800 RPM / 8M TPM
Ultra: $200/mo, $220 in credits, $100 rollover cap, 1,600 RPM / 16M TPM

You can also skip the subscription and top up credits directly (custom amount via Stripe); pay-as-you-go keys without a plan run at 180 RPM / 720K TPM. Plan details live on the Portal info page. Prices verified August 1, 2026.

Why Nous Portal Exists

Running a capable AI agent on your own infrastructure used to mean signing up for and paying multiple providers: a model provider (Anthropic, OpenAI), a web search provider (Tavily or Exa), an image generation provider (FAL), a TTS provider, and optionally a browser automation provider. Each one has its own dashboard, billing, and quota. For users who just want to run Hermes Agent and use it, that’s a lot of plumbing.

Nous Portal collapses that into one subscription. You pay one bill, you authenticate once, and Hermes Agent uses your Portal subscription to call models and tools automatically.

Self-host it, put it on Portal’s own Hermes Cloud, or deploy a managed Hermes Agent here in about 30 seconds — no VPS, no Docker, no credit minimum.

Deploy a Hermes agent

What’s Included

Models

Portal lists 248 models plus 29 embedding models — Anthropic Claude, OpenAI GPT, Google Gemini, Meta Llama, Mistral, DeepSeek, Qwen, xAI Grok, and Nous Research’s own Hermes series, among others. Nous states plainly on its own info page that this catalog is powered by OpenRouter, and the model links on the Portal site point at openrouter.ai. Worth knowing before you compare: for third-party models you are paying Portal to sit in front of OpenRouter, not to replace it.

Nous’s own models are the exception — Hermes-4.3–36B, Hermes-4–70B and Hermes-4–405B (128K context each) run on Nous’s own inference backend at inference-api.nousresearch.com/v1, which is OpenAI-compatible. That endpoint also supports x402 payments in Solana USDC (beta), which lets you make pay-per-request calls with no account and no API key at all.

Some models are free for Portal subscribers; others bill against your monthly credit budget.

Tool Gateway (paid tiers)

Paid Portal subscribers get automatic access to bundled tools, with no extra API keys needed:

Web search & scraping — Firecrawl, billed at $0.0005 per credit
Image generation — FAL (FLUX 2 Pro, Nano Banana Pro, Ideogram v3, Recraft v4, Qwen Image) and Krea, roughly $0.005-$0.26 per image
Video generation — FAL, covering Veo 3.1, Kling v3, Seedance 2.0, PixVerse v6 and LTX-2 ($0.0017-$0.44 per unit)
Speech in and out — OpenAI audio: Whisper transcription at $0.0063 per audio minute, plus GPT-4o transcribe and TTS billed per token
Browser automation — Browser Use at $0.0011 per session minute, plus $4.20/GB proxy bandwidth
Code execution — Modal sandboxes at $0.0495 per CPU-hour and $0.0084 per GiB-hour

These tools route through Nous Research’s gateway. Hermes Agent picks them up automatically when you authenticate with a Portal subscription, no per-tool config required. Every tool call bills against the same credit balance as your models, so a heavy image or video session eats the same budget your inference does.

xAI Grok integration (May 2026)

On May 15, 2026, Nous Research and xAI shipped a Grok integration that lets X Premium+ subscribers use their existing Grok subscription inside Hermes Agent — without paying separately for Grok API access. Grok 4.3, Grok TTS, and Grok Imagine all become available through the OAuth flow. See the launch coverage for details, or the upstream xAI Grok OAuth guide.

Hermes Cloud — Nous now hosts the agent too

The biggest change since Portal launched: it is no longer only a key-and-credits product. Hermes Cloud deploys a hosted Hermes Agent on a dedicated instance with its own workspace and dashboard, billed hourly from your Nous credit. It is currently in preview.

You pick a size, and the instance price covers compute and storage only — inference and tool usage bill separately on top:

Small: 1GB RAM, 2 vCPU, 5 concurrent sessions. $0.29/day running (about $8.70/mo), $0.03/day stopped
Medium: 2GB RAM, 4 vCPU, 10 concurrent sessions. $0.56/day running (about $16.80/mo), $0.03/day stopped
Large: 4GB RAM, 8 vCPU, 20 concurrent sessions. $1.09/day running (about $32.70/mo), $0.03/day stopped

Stopping an instance drops it to the storage-only rate and keeps your data, so an idle agent costs about $0.90/mo to keep alive. Deploying requires an active subscription or a credit balance — the Cloud page states a $10 minimum, while the info page’s getting-started steps say $2, so budget for the higher number. Nous picks the region closest to you from Amsterdam, Stockholm, Mumbai, Paris, Dallas, Frankfurt, Los Angeles, London, Tokyo, Chicago, Singapore, San Jose, Sydney and Toronto.

Feature-wise it is what you would expect from a first-party host: one-click deploy, natural-language scheduling, Telegram / Discord / Slack / email / CLI channels against one shared memory, and an isolated hardened container per agent. On billing, the one rule Nous states unambiguously is the two-rate split: you pay the running rate while the instance is on and the storage rate while it is stopped.

Watch: Nous Portal in 90 seconds

One note before you watch: this was recorded in July 2026, when Portal advertised a 300+ model catalog and five Tool Gateway backends. Nous has since restated the catalog as 248 models and added a sixth backend (Modal sandboxes) plus Hermes Cloud. The walkthrough of the setup flow is still accurate; the numbers above it are the current ones.

https://www.youtube.com/watch?v=VvkBFyF14kk

How to Connect Nous Portal to Hermes Agent

Two paths, depending on whether you’re self-hosting Hermes Agent or running it on managed infrastructure.

Self-hosted Hermes

Subscribe at portal.nousresearch.com
Generate a Portal API key from the dashboard
In Hermes Agent, run hermes with no arguments to enter interactive setup, or edit your config.yaml
Select Nous Portal as the provider and paste the API key
Hermes will list available models from your subscription — pick your default

Once configured, the Tool Gateway features (search, image gen, TTS, browser) are picked up automatically — you don’t need separate API keys for Firecrawl, FAL, or Browser Use anymore.

Do You Actually Need Portal?

Depends on where Hermes runs.

You self-host Hermes

Portal is worth it. One login replaces a model provider, Firecrawl, FAL, a TTS key and Browser Use — and the Tool Gateway comes with it. The setup steps are above.

You’d rather not run a server

You now have two managed options, and it is worth being straight about that. Hermes Cloud is Nous’s own, from $0.29/day plus inference — the tightest possible integration with Portal, though it is in preview and you need a credit balance or a subscription before you can deploy anything. OpenClaw Launch’s Hermes hosting is the alternative: deploy in about 30 seconds with no credit minimum and no card for the free trial, run either Hermes Agent or OpenClaw from the same account, and reach channels Hermes Cloud doesn’t list — WhatsApp and WeChat included. Bring a Portal key if you want, or use our managed models and skip Portal entirely.

Nous Portal vs OpenRouter vs Per-Provider Keys

Nous Portal

Pros: One auth; bundled tools; free models for subscribers; tight Hermes integration

Cons: Locked to Nous as the gateway; routing markup on paid model calls

OpenRouter

Pros: One API key for 300+ models; granular per-model spend control; it is what Portal routes third-party models through anyway

Cons: No bundled tools (search / image / video / speech / browser need separate keys)

Per-provider keys

Pros: Direct billing relationship; no gateway markup; full provider features

Cons: 5+ separate sign-ups, dashboards, and bills to manage

The right answer depends on shape of usage. For a single user running Hermes full-time, Nous Portal’s bundled tools usually win on convenience. For teams running production agents at scale, direct provider keys often come out cheaper.

Frequently Asked Questions

Is Nous Portal free?

There is a free tier, but be clear on what it gives you: $0/mo with $0 in monthly credits, capped at 50 RPM / 500K TPM, and limited to the free-model catalog. It is not a trial of the paid product — the Tool Gateway and the paid model catalog both sit behind a subscription or a credit top-up. Plus at $20/mo is the real entry point, and it returns $22 in credits.

Do I need a Nous Portal subscription to use Hermes Agent?

No. Hermes Agent is open source and free; you can run it with any provider you like — OpenRouter, direct Anthropic / OpenAI / Google keys, local models via Ollama, or Nous Portal. Portal is one option among many, not a requirement.

What models are free on Nous Portal?

Nous Research rotates a list of free-for-subscribers models, typically including their own Hermes model series and select open-weight models from other labs. The current list is in the Portal dashboard — it changes from month to month.

Can I use my X Premium+ Grok subscription with Hermes through Portal?

Yes, since May 15, 2026. The xAI Grok OAuth flow connects your existing X Premium+ subscription to Hermes Agent, giving you Grok 4.3, Grok TTS, and Grok Imagine without separate API billing. See the upstream OAuth guide.

What is Hermes Cloud, and how is it different from a Portal subscription?

A Portal subscription buys models, tools and credits. Hermes Cloud is the hosting layer on top: it runs the agent itself on a Nous-managed instance, billed hourly from the same credit balance, from $0.29/day for the Small size plus whatever inference and tools you use. You can hold a Portal subscription without ever using Hermes Cloud — plenty of people just point a self-hosted Hermes at their Portal key.

Is Hermes Cloud cheaper than managed Hermes hosting elsewhere?

On the instance line alone it looks inexpensive, but compare the whole bill. Hermes Cloud’s day rate excludes inference and tool usage, and you need a credit balance or an active subscription before you can deploy at all. It is also still in preview. If you want to try managed Hermes without funding a balance first, our Hermes hosting has a free trial and no credit minimum — and you can compare the two honestly from there.

Does OpenClaw Launch support Nous Portal?

OpenClaw Launch’s Hermes hosting runs Nous Hermes models on managed OpenClaw infrastructure today via OpenRouter — no Portal key needed. Native Hermes Agent framework hosting is also live today — pick Hermes as your framework in the configurator and deploy in about 30 seconds.

Originally published at openclawlaunch.com/guides/nous-portal, where it is kept up to date.