Hermes in the CLI, and the Hermes path that was only half true - #60
Merged
Merged
Conversation
The CLI configures Hermes as of nan-cli 0.1.3, so the table on /docs/nan-cli and the card on /docs/agent-setup say so, in both languages. Two corrections that came out of driving the real tool while writing it: - The Hermes page published `~/.hermes/config.yaml` as the path. That is the macOS and Linux one; on Windows Hermes keeps its home under LOCALAPPDATA. Both are published now, along with `hermes config path`, which answers for whichever machine the reader is on. - The Hermes page now says the CLI can do this step, which is the shortcut the rest of the section already points at for the other tools. The test is for the half that kept drifting. The list of tools lives in four files - two pages, two languages - and the last time the CLI learned one, the table gained a row and the card went on naming four, so the answer a member got depended on which page they landed on. It cannot check the Go source, which is another repository; it checks that the site agrees with the site. It earned itself immediately: it caught the Spanish Hermes page going out without the CLI note the English one had. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two things a member acts on, both wrong on the page. The Pi page said what Pi is and never said where to get it. Every other page in the section links its tool out - Hermes to Nous Research, Gentle-AI to its repo - and the only link anywhere pointed at pi.ai from the CLI's README, which is Inflection's consumer chatbot and a different piece of software with a different company behind it. Pi is at pi.dev, and it installs in one line on each kind of machine, Windows included. The model page closed the premium note with "every other model can be called by any member". That is no longer true: `GET /v1/models` answers with what the cluster is running, which is not the same question as what a key can call, and there is at least one id today that appears there and comes back `401`. The note now points at the table as the thing to go by and says why the endpoint is not it - without pretending the difference does not exist. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The page published `glm5.3-flash` and `deepseek-v4-flash` as an example while
the CLI writes all seven, so the same member got a different answer depending
on whether they set Pi up by hand or let the CLI do it - and by hand they got
a model picker missing five of the models they are paying for.
Nothing caught it. Every window on the page was correct; there were just two
of them, and the rule the suite enforced was written over the values rather
than over the set. The OpenCode page has published all seven all along, which
is what made the difference invisible: two of our own pages disagreeing about
what the cluster serves.
Both blocks are now the same seven in the same order, and the prose names them
the way /docs/opencode does.
Two things the list needs explaining, both now in Known issues:
- `mimo-v2.5` goes in without its audio. Pi's `input` schema is
`("text" | "image")[]` and a third value does not fail that one model: Pi
refuses the whole file, every other provider in it included. That is why
this page and the OpenCode page differ on that one field.
- `glm5.3` is premium. It is on the list so a member who has the tier can see
it, and the 401 without it is explained on /docs/choose-a-model.
The tests are the OpenCode ones written for Pi, the completeness check
included - seen failing against the two-model page before going in - plus one
the other pages have no equivalent of: settings.json has to name a provider
and a model that models.json actually declares. A default pointing at
something the same page never defined is the failure the CLI was shipping
until this week.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The Windows half of /install, same shape and for the same reasons: the script is not copied into this repo, it is fetched from a released tag next to the code it installs, and a failure comes back as a script that exits rather than as an HTTP error page. The caller is a shell in both cases; only the shell differs, which is what the content type is about - Invoke-RestMethod parses by content type, and anything json-ish would hand `iex` an object where it expected the text of a script. The pin is v0.1.3, which is not cut yet. Until it is, the upstream fetch 404s and the route answers with the error script that says what happened and where to download by hand - the correct degraded behaviour for something piped into `iex`, and better than the route not existing. /install is deliberately left pinned at v0.1.1. That script works today, and moving it before the tag exists would break a working install path in order to improve one that does not exist yet. Both pins move to v0.1.3 together once it is published - which also ships the install.sh change in this same branch. The docs stop saying Windows means building from source. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
/install had been pinned to v0.1.1 for three releases. The pin is deliberate - whatever that URL returns runs on a member's machine, and a tag is a revision somebody decided to publish - but nothing moved it, so the change that tells a member what happened when the GitHub API rate limits the version lookup was released and served to no one. /install.ps1 moves to v0.1.4 rather than the v0.1.3 it was written against, because v0.1.3's PowerShell installer does not work. Two PowerShell 5.1 faults, both found the first time it was pointed at a published release rather than a local zip: an Invoke-WebRequest without -UseBasicParsing, which throws where the Internet Explorer engine is absent or has never run its first-run setup, and checksums.txt read off a response body that PowerShell hands back as a Byte[] because GitHub serves release assets as application/octet-stream. Both fixed in helmcode/nan-cli#5 and run end to end on Windows 11 afterwards. The test pins the two routes to each other. They are not required to name the same tag forever, since each moves when its own script changes, but one drifting three releases behind the other in silence is exactly what happened, and it is cheap to be told. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Docs for helmcode/nan-cli#4, which teaches the CLI to configure Hermes.
What changed
The table on
/docs/nan-cliand the card on/docs/agent-setupnow say the CLI configures Hermes too, in both languages, along with a short paragraph on what it does and does not touch.Two corrections that came out of driving the real tool while writing it:
~/.hermes/config.yamlas the path. That is the macOS and Linux one; on Windows Hermes keeps its home under%LOCALAPPDATA%. Both are published now, plushermes config path, which answers for whichever machine the reader is on.The test
The list of tools the CLI configures lives in four files — two pages, two languages. The last time the CLI learned a new one, the table gained a row and the card went on naming four, so which answer a member got depended on which page they landed on. Nothing in the build compared the two, because they are prose in different files.
It cannot check the Go source, which is another repository. It checks that the site agrees with the site — the half that kept going wrong.
It earned itself immediately: it caught the Spanish Hermes page going out without the CLI note the English one had.
🤖 Generated with Claude Code