DEV Community: Zack Chew

Your ChatGPT Doesn't Know Your Stuff. Your Bot Does.

Zack Chew — Tue, 20 Oct 2026 16:19:01 +0000

Hermes and OpenClaw bots on OpenClaw Launch can now be added to ChatGPT or Claude as a connector, so the assistant you already type into can ask the one that actually knows your context.

You know the shape of this already. You're in ChatGPT, halfway through something, and you need a fact that isn't in the chat. What's on your calendar tomorrow. What you decided in the notes you've been keeping. Whether that thing you asked for on Monday ever got done.

You have a bot that knows. It's been running for weeks. If you connected your calendar to it, it can read your calendar. It wrote the notes. It has the skill you set up for exactly this kind of question. But it lives in another tab, and the only bridge between the two is you, copying a question across and pasting an answer back.

That bridge is now a setting. Copy one address, approve it once, and you can ask ChatGPT to ask your bot. The answer comes back in the same chat.

What a connector actually is

The feature is called an MCP connector. MCP is a standard that lets an AI app call something outside itself, and you don't need the acronym to use it. Think of a plug socket. ChatGPT gets one socket that leads to your bot.

The part worth understanding is what doesn't happen. Your bot isn't copied into ChatGPT. Its memory, its skills and the apps you connected to it stay where they are, running on your bot. ChatGPT gets a way to send it a message and read what comes back. That's the whole mechanism.

This matters because the alternative is worse than it sounds. Pasting an answer into ChatGPT gives it a paragraph. It doesn't give it the twenty previous conversations that made the answer make sense, or the notes file the answer came from, or the ability to go and check something else tomorrow. A connector keeps all of that on the bot's side, where it already lives.

What it feels like

You type the way you'd text a person who happens to know your stuff.

Ask my bot what's on my calendar tomorrow.

ChatGPT hands the message to your bot. Your bot works the way it does in Telegram or WhatsApp, with its own model, its own memory and its own connected apps, and the reply appears in the ChatGPT conversation a moment later. You stay where you were.

Some other things this is good for:

"Have my bot add this to the project notes it keeps."
"Ask my bot to run its weekly report skill now."
"Ask my bot whether the thing I mentioned this morning is finished."

Follow-up questions continue the same conversation on the bot's side, so it still has the earlier context when you ask the second question. If you'd rather start clean, tell ChatGPT to start a new conversation with your bot first.

Why there's only one tool

The connector gives ChatGPT exactly one ability, and it's called ask_bot. Send a message, get the reply. There is no file tool, no terminal, no way to change your bot's configuration or read its credentials.

That limit is deliberate. A connected app should never be able to do more than a person typing to the bot could do, and that's the line this sits on. If you wouldn't hand a stranger your Telegram bot, don't hand them the connector address either.

Access is the part I'd want you to read properly, because this does give an outside app a route to an agent with real permissions. When you add the connector, ChatGPT sends you to an OpenClaw Launch page that names the exact bot being connected. You sign in with the account that owns it and press Allow. What the app receives is a token that works for that one bot. Your bot's API keys and provider credentials never leave the platform, and the connector address on its own does nothing until someone signs in and approves it.

If you change your mind, open the bot's MCP window and press Disconnect. Access ends there and then, not at the next restart or the next billing date. You can also remove the plugin on the ChatGPT side, though disconnecting on the dashboard is what actually revokes it.

One warning that applies to any connector, not just this one: only approve a connection you started yourself. If someone sends you a link and asks you to approve it, close the tab. Whoever completes that screen can use the bot, and everything connected to that bot.

Setting it up

Two things before you start. You need a running bot on OpenClaw Launch with an active plan or free trial, and you need a ChatGPT plan that allows custom connectors. ChatGPT Free doesn't offer them, and on a work workspace an admin may have switched them off. Claude accepts custom connectors on any plan, with one connector on Free.

For ChatGPT:

On your dashboard, press MCP on the bot's card and copy the Connector URL from the ChatGPT / Claude tab.
Open ChatGPT's plugins page, press Add and choose Add custom MCP server.
Give it a name you'll recognise, paste the URL under Connection, and leave Authentication on OAuth.
Tick the confirmation, press Create as a plugin, then Continue.
Sign in to OpenClaw Launch, check that the bot named on the page is the one you meant, and press Allow.
Start a new chat and try: "Use my bot to tell me what you can do."

For Claude:

Copy the same Connector URL from the bot's MCP window.
Go to Customize, then Connectors, press + Add and choose Add custom connector.
Paste the URL, add it, and press Connect.
Sign in, check the bot name, and press Allow.

On Claude Team and Enterprise, an owner adds the connector first under Organization settings, then Connectors, and each member connects it for themselves.

Those menu names were correct when the flow was checked in October 2026 on a Pro plan. Both companies move their menus around, so if a button has a different name, look for the option to add a custom connector rather than for the exact wording above.

If ChatGPT answers the question itself instead of passing it to your bot, name the plugin in your message. "Use the your bot's name plugin to ask my bot what's on my calendar tomorrow" is usually enough, and after that it tends to get the idea.

What it doesn't do

It doesn't make ChatGPT smarter, and it doesn't give ChatGPT your bot's model. ChatGPT relays the message and reads the reply. The work happens on the bot, which spends the same AI credits as a message from any other chat app.

A single request can run for just under five minutes. For anything longer than that, ask the bot to start the job and message you when it's finished, rather than leaving the ChatGPT request hanging in the meantime.

It's also not a way to reach a bot that isn't yours. Bots created through the developer API, and bots you resell to your own customers, can't be connected this way.

If you don't have a bot yet

None of this is much use without one. OpenClaw Launch runs Hermes or OpenClaw for you, with restarts, updates and chat apps handled from a dashboard, and the connector is included on every plan and during the free trial. A trial takes a minute to start and doesn't ask for a card.

openclawlaunch.com

My agent now answers with cards I can compare, check and filter

Zack Chew — Sat, 10 Oct 2026 15:45:06 +0000

Ask an AI to help you buy something and you usually get an essay. Then you open ten tabs to check whether any of it is right.

My Hermes bot can now answer with something you use instead: cards you can compare at a glance, numbered sources you can click, and a slider that narrows the list without asking it again.

ChatGPT does something similar with GPT-6 (OpenAI calls it Intelligent UI). I wanted it in the agent I actually work with, the one with its own tools, memory and files, so I built it into Hermes on OpenClaw Launch.

It's live for every Hermes bot there, and it stays off until you switch it on.

What it looks like

In Quick Chat on the dashboard there's a chip next to "/ commands" called Interactive. I turned it on and asked the kind of question I normally lose an evening of tabs to:

"I want a robot vacuum that handles pet hair, budget up to $500. Search the web for 4 strong options you can buy right now, with their current price and battery life from what you find. Show them as cards with a photo of each (use real image URLs from your search), and let me filter by max price with a slider."

A few minutes later the answer was four cards, not an essay. A Roborock at $249.99, a Dreame at $269.99, and two eufy models at $339.99 and $499.99 with coupons. Each card had a product photo, the battery life, what it's good and bad at, and numbered sources I could click. A slider at the top cut the list down as I dragged it.

That's the part I care about. Normally I'd get a page of text and then open ten tabs to check it. Here the checking came with the answer. It even warned me that the battery numbers come from different cleaning modes, and that it hadn't tested the coupon prices at checkout. Dragging the slider costs nothing, because nothing goes back to the model.

It's one run on my own bot, checked October 9, so treat the prices as that day's prices.

How it works

The obvious way to do this is to let the model write a whole web page and load it in an iframe. That works, but it's a lot of code to trust. OpenAI describes their version as a library of native components plus a compiler, and I went the same direction.

The bot writes a small markup block in its reply. Tags that look like JSX, a little JavaScript for state, if and each blocks. The browser compiles it, runs the code inside a sandboxed frame and two isolated workers, and draws the result with a fixed set of parts:

rows, columns, cards and tiles
text, buttons, inputs, sliders, toggles and selects
tables, plus line, area, bar and pie charts
drawings, with simple animation for games and diagrams
pictures, from the bot's own files or the web
a look of its own: dark or light, an accent colour, gradients
246 icons and a copy button

The view's code can't reach the page, your cookies, storage or the network. Pictures are the one thing it can show from outside, and it doesn't fetch them itself. Our server fetches every picture written into the view as soon as it appears, so nothing you type or click inside it makes a request. If a view is broken, too big or stuck in a loop, you get the code instead of the view and the chat carries on.

Every view has a "View code" link. I wanted to see exactly what the bot wrote, and I figured other people would too.

Views can also draw and animate, show pictures, and pick their own look. The vacuum cards above use the pictures.

Ask it how a ballpoint pen works and it draws an exploded view on a dark card, with the cap, barrel, ink tube, tip and ball each labelled. I never asked for dark.

What it costs

My bots run on tokens I pay for, so this was the first thing I measured, on my own bot:

a normal call there already sends about 22,000 input tokens (system prompt and tools)
with Interactive on, the format note adds about 1,900 tokens to the first message, roughly 9% more input. It grew when drawings, pictures and styling went in, and I'm counting from its length
after that most messages carry a 60 token reminder, and the full note goes again every 10th message
over a long chat I'd expect 10 to 15% more input, and most of it is sent as cheap cache reads
plain text replies cost no extra output
the tip calculator I tested first was about 600 to 700 output tokens, nearly all of it the view's code. A text answer would have been 100 to 200

Turn the chip off and nothing gets added to new messages.

Where ChatGPT is ahead

Honestly, in a lot of places. It's on by default and the model decides by itself when an answer should be a UI. OpenAI says it trained GPT-6 to make that call. And it's rolling out to Free users too.

Mine is a switch you turn on, and it's only as good as the model writing the markup. So far I've tested it with GPT-6.1 Sol. I haven't tried weaker models yet.

Where a Hermes bot is different

The view comes from an agent that already has my context. It can run a web search first and put what it found into the view, sources and all, like the vacuum cards above. It has its own memory, skills and files on its own server. And the view is plain text in the reply, so it doesn't care which vendor's model writes it.

The same bot keeps answering on Telegram and Discord in plain text. Those apps can't draw a live view, so Interactive only lives in the web chat.

One caveat

Turning the switch off stops new notes. In a chat where it was already on, the earlier notes are still in the history, so the bot may keep building views there. Start a new chat if you want plain answers back.

If you run a Hermes bot on openclawlaunch.com, open Quick Chat and click Interactive. I wrote up the details and a side by side with ChatGPT here:

https://openclawlaunch.com/guides/hermes-agent-interactive-answers?utm_source=devto&utm_medium=article&utm_campaign=2026-10-08-interactive

My guess is the first thing most people ask for is a calculator. I'd rather hear what you'd make it research.

Rent a Cloud GPU with Hermes Agent or OpenClaw

Zack Chew — Sun, 04 Oct 2026 01:36:03 +0000

Your bot runs on a CPU server, but it can rent a GPU when a job needs one: it quotes the cost, rents a Vast.ai machine on your account, runs the job over SSH, brings the files back and releases the machine. The steps are the same on managed Hermes Agent and OpenClaw.

I run OpenClaw Launch, which hosts the managed bots described in this guide.

What this looks like in practice

We tested this on our own managed Hermes Agent while it was producing an animated film in Blender. It had been rendering on CPU and needed a full-HD, 128-sample Cycles frame to check quality. From one chat message, the bot:

searched Vast.ai for GPUs with at least 12 GB of VRAM, enough CPU and disk, and a CUDA driver new enough for its Blender build, all under a price cap;
rented an RTX 4060 Ti 16GB with a 20 GB disk and a throwaway SSH key it generated for this one job;
uploaded Blender and the scene, checking a SHA-256 hash for each upload;
confirmed Cycles was really rendering on the GPU (CUDA) and not falling back to CPU;
rendered the 1920×1080 frame in 22.5 seconds, then downloaded it and checked the file;
destroyed the instance, removed the SSH key, and confirmed that instance no longer existed.

The whole rental, from creating the machine to releasing it, took 194 seconds. Vast posted a $0.007 charge for that instance. The bot then compared the GPU frame with its earlier CPU preview and told us honestly what had improved and what still fell short, rather than declaring the job done.

The GPU is yours, not ours. Your bot rents the machine on your own Vast.ai account and Vast bills it separately from your OpenClaw Launch plan. Your bot's own container has no GPU; it acts as the controller that rents, drives and releases one.

How it works

Piece	Role
Your managed bot	Plans the job, prepares the files, and runs every step from its own workspace terminal.
Vast.ai connection	Lets the bot quote offers, rent and release instances, manage SSH keys, and read charges on your Vast account, with no API key in the chat.
SSH and scp	Already installed in every Hermes Agent and OpenClaw container. The bot uses them to upload inputs, run the job and download outputs.
The GPU machine	A short-lived Vast instance running a versioned Docker image. It is destroyed once the results are safely back in your bot's workspace.

What you need

A running managed Hermes Agent or OpenClaw bot on OpenClaw Launch.
A Vast.ai account with credit or a payment method on file.
Vast.ai connected to your bot. Follow the Vast.ai connection guide: create a Vast API key with the permissions this workflow uses (misc for offer search, user_read and user_write for balance and SSH keys, instance_read and instance_write for rentals, billing_read for charges), then connect it under Dashboard → Integrations. That takes about two minutes.

Before your first rental, check the connection without spending anything:

Use my connected Vast.ai account. Read my balance and list my instances. Do not create, start, stop or delete anything.

1. Describe the job and your limits

Tell the bot what the job is, what counts as success, and how much you are willing to spend. The more concrete the limits, the better the quote. For example:

Render frame 289 of my Blender project at 1920×1080 with 128 Cycles samples on a rented GPU. Use a single GPU with at least 12 GB of VRAM, a 20 GB disk, and a maximum of $0.40 per hour. Quote the full cost first and wait for my approval. After the render, download the frame, verify it, destroy the instance, and remove any SSH key you added.

If you do not know how much VRAM your job needs, ask the bot to work it out from your model or scene first. Specifying VRAM, CUDA version and disk up front removes most of the cheap offers that would fail halfway.

2. Approve the quote

The bot searches current Vast offers with full pricing and comes back with a specific machine. A good quote names:

the offer ID, GPU model, VRAM, and the host's maximum supported CUDA version;
the hourly price for the disk size you asked for (Vast includes storage in that quote, so it should not be added twice);
upload and download rates, and an estimate of how much data will move;
an estimated total for the expected runtime, and a hard time limit after which it will release the machine.

Offers on Vast change minute by minute. If the chosen offer disappears, the bot should come back with a new quote instead of quietly renting a different machine. Reply with a clear approval, for example "Approved: offer 123456, up to $0.40 per hour, 30 minutes max."

3. The bot rents the machine and connects

Once you approve, the bot typically:

generates a new SSH key pair in its own workspace for this job only, and registers the public key with Vast (the private key never leaves the bot);
creates the instance from the approved offer with a versioned Docker image; the connection refuses untagged, latest and main images. To pin the exact image contents, ask the bot to use the image's sha256 digest instead of a tag;
checks the instance until SSH actually answers. A "running" status from Vast does not yet mean the machine is ready to connect to.

The rental calls look like this from the bot's terminal. You do not need to type them; they show what the bot is doing on your behalf. <PUBLIC_KEY> stands for the public key the bot generated in step 1:

composio execute VAST_AI_OCL_SEARCH_GPU_OFFERS_FULL '{"limit":20,"allocated_storage":20,"filters":{"gpu_ram":{"gte":12000},"num_gpus":{"eq":1},"dph_total":{"lte":0.4}}}'
composio execute VAST_AI_OCL_ADD_SSH_KEY '{"user_confirmed":true,"ssh_key":"<PUBLIC_KEY>"}'
composio execute VAST_AI_OCL_CREATE_INSTANCE '{"user_confirmed":true,"offer_id":123456,"image":"nvidia/cuda:12.8.0-runtime-ubuntu24.04","disk":20,"runtype":"ssh"}'
composio execute VAST_AI_OCL_GET_INSTANCE '{"instance_id":52500115}'

4. The bot runs the job

Over SSH, the bot uploads its inputs, installs or unpacks the software, and runs the job. Two checks separate a real GPU run from an expensive CPU run:

Verify the uploads. Comparing a hash of each file on both ends catches a truncated upload before you pay for a broken run.
Prove the GPU is used. Run nvidia-smi, and for Blender check that Cycles has the CUDA or OptiX device enabled. Many tools silently fall back to CPU when the driver and the software's CUDA version do not match.

5. Download, verify, release

When the job finishes, the bot copies the outputs back into its own workspace with scp and checks them. Only then does it destroy the instance:

composio execute VAST_AI_OCL_DESTROY_INSTANCE '{"user_confirmed":true,"instance_id":52500115}'
composio execute VAST_AI_OCL_LIST_INSTANCES '{}'
composio execute VAST_AI_OCL_DELETE_SSH_KEY '{"user_confirmed":true,"ssh_key_id":98765}'

The job is only finished when this job's instance ID no longer appears in your instance list (the list returns 25 rentals per page, so the bot should follow every page) and its temporary SSH key is gone. Other rentals on your account are left alone. The results then sit in your bot's workspace, where it can send them to you in chat, publish them, or keep working on them.

Stop is not release. Stopping a Vast instance keeps its disk, and Vast keeps charging for that storage. Destroying it deletes the disk and ends all charges. Always download results before destroying. See Vast's instance lifecycle.

Jobs worth sending to a GPU

Job	What to tell the bot
Blender Cycles rendering	Blender version, resolution, samples and frame range. Ask it to confirm the CUDA or OptiX device before rendering the full range.
Image and video generation	The ComfyUI workflow or model and the output count. Size VRAM from the model, and have the bot download the model weights on the GPU machine rather than uploading them.
Speech transcription	The audio files and the Whisper model size. For a large batch, a short GPU rental can cost less than hours of CPU time; test one file first to compare.
Fine-tuning a small model	The base model, dataset and training config. Ask for a checkpoint download before the release step.
Batch inference with an open model	The model and the input list. For a quick batch, a short vLLM rental can beat keeping an always-on endpoint.

Keep costs under control

Give a price cap and a time limit in the first message, and ask the bot to release the machine automatically when either is reached, including on failure.
Test small first. One frame or a short sample on the GPU tells you the real speed and cost before you pay for the full batch.
Check the actual charge. Ask the bot to read your Vast charges for that instance ID afterwards. Vast posts charges with a delay, so the first figure is not always the final one.
Never retry a rental blindly. If a create call times out, the machine may already exist. The bot should list your instances before trying again, so you do not end up paying for two.

Hermes Agent and OpenClaw: same steps

On OpenClaw Launch, managed Hermes Agent and OpenClaw bots get the same Vast.ai connection, the same composio command and the same preinstalled ssh, scp and ssh-keygen in their workspace. Every prompt and command on this page works unchanged on both. Hermes Agent can also save the finished flow as a reusable skill, so the next GPU job starts from a tested routine instead of from scratch.

Self-hosted agents

The VAST_AI_OCL_ actions are part of OpenClaw Launch's managed connection, so a self-hosted Hermes Agent or OpenClaw does not have them. The same workflow works with Vast's own command-line tool, installed where your agent runs and authorized with your Vast API key:

pip install vastai
vastai set api-key YOUR_VAST_API_KEY
vastai search offers 'gpu_ram>=12 num_gpus=1 rentable=true'
vastai create instance OFFER_ID --image nvidia/cuda:12.8.0-runtime-ubuntu24.04 --disk 20 --ssh
vastai show instances
vastai destroy instance INSTANCE_ID

On a self-hosted agent, vastai set api-key saves the key to a file on that machine and the agent can spend with it, so give it a restricted key and put the same approval and cleanup rules in your instructions.

Troubleshooting

Problem	What to do
SSH connection refused right after renting	Normal for the first minute or two. The bot should poll until SSH answers, with a time limit, and release the machine if it never does.
The job ran, but slowly	It probably ran on CPU. Check `nvidia-smi` and the tool's device setting, and compare the host's maximum CUDA version with the one your software needs.
The chosen offer is gone	Ask for a fresh quote. Do not let the bot substitute another machine without your approval.
Create failed or timed out	List instances before retrying. An uncertain response can still mean the machine was created.
A restarted instance stays in Scheduling	A stopped instance can only restart when its host's GPU is free again, and storage is billed while it waits. If the results were already downloaded, destroying it and renting a fresh offer is usually faster.
The bot says Vast tools are missing	Check the connection under Integrations, then ask the bot to run `composio search vast_ai`. See the connection guide.

Cloud GPU FAQ

Does this work on Hermes Agent and OpenClaw?

Yes. Managed Hermes Agent and OpenClaw use the same Vast.ai connection, the same composio command and the same SSH tools inside the bot's workspace, so every step on this page is identical on both. Self-hosted agents need their own Vast integration; see the self-hosted section.

Does OpenClaw Launch provide the GPU?

No. Your bot itself runs on a CPU server. The GPU is rented from Vast.ai on your own Vast account and billed by Vast, separately from your OpenClaw Launch plan. Your bot does the renting, setup, running and cleanup for you.

How much does a GPU job cost?

It depends on the GPU, how long it runs, the disk you allocate and how much data you move. In our own test, one 1080p Blender Cycles frame on an RTX 4060 Ti 16GB took about 3 minutes and 15 seconds from rental to release, and Vast posted a $0.007 charge for it. Prices change constantly, so ask your bot for a quote on current offers before every rental.

Can the bot rent a GPU without asking me?

Every paid Vast action on OpenClaw Launch refuses to run unless the bot explicitly marks it as confirmed by you, and the action descriptions tell the bot to do that only after you approve the specific offer and cost. The bot sets that flag itself, so your instructions are the real control: give it a budget and tell it to wait for your approval before it creates anything. Reading balances, offers and instance lists never rents anything.

What happens if the job fails halfway?

Ask the bot to release the machine on failure as well as on success, and to set a hard time limit up front. A stopped Vast instance still bills storage, so a rental is only fully closed once that instance is destroyed and no longer appears on any page of your instance list.

Related guides

Give your agent a GPU

Connect Vast.ai under Integrations, then ask your bot for a quote on your first GPU job.

OpenClaw Launch

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.