Please see the release notes thread for all the details!
Is anyone having problems using Dlam since the update to OS 2.3? I keep getting rate limited. It seems like a ploy for us to have to get a paid subscription. I have been a user since the 1st batch and this is horrible. I have changed models, put in numerous API keys using numerous models. This hasn’t changed anything. Please help.
I just set this up, tested it and it works flawlessly. The dream is finally true. Thanks Rabbit Team.
There’s an issue in the installer, sets cwd as /home/yt. Also can we not have hermes connect to the gateway rather than acp so we can see all previous sessions etc. Also, can I remove openclaw from my horizontal carousel menu?
R1 → Hermes: connector advertises a nonexistent working dir (/home/yt), breaking file/terminal tools
I’ve been using the R1’s Hermes integration (via the rabbit-agent node) and hit one issue worth flagging. Posting here in case it helps the team and others.
When the R1 opens a Hermes session, the node spawns hermes acp and passes it a workspace cwd. The cwd it sends is /home/yt:
2026-07-23 10:13:38 [INFO] acp_adapter.session: Created ACP session <id> (cwd=/home/yt)
/home/yt doesn’t exist on my machine (my home is /home/jay). Digging into the connector binary, that path is just Rabbit’s build environment:
__dirname="/home/yt/repo/typescript/q-os3-node-agent/dist"
So the compiled connector is leaking its own build path as the agent’s working directory. Anything the Hermes session does with files or the terminal defaults to a directory that doesn’t exist, so those tools error out until you cd somewhere real.
I patched it locally in Hermes (_resolve_acp_cwd now falls back to the real home when the cwd doesn’t exist) and it works, but that patch gets wiped on the next hermes update. The real fix is on the connector side: send the host’s actual working directory (or $HOME) as the ACP cwd, not the build path.
Other than that the integration is solid. The R1’s Hermes session loads my credentials, model, memory and tools fine, and it responds well. Just the cwd is wrong.
Happy to share more logs if useful.
Suggestion: let the R1 reach existing Hermes sessions (Telegram/desktop) instead of isolated ACP sessions
Love that the R1 can drive Hermes now. One thing I’d love to see: the sessions picker on the R1 is always empty for Hermes.
Reason I’ve figured out: the connector launches a fresh hermes acp process for each session. ACP is scoped to sessions it creates itself, and per Hermes’ own docs, ACP can’t see ~/.hermes/state.db at all. So none of my existing Telegram or desktop app sessions show up, and I can’t resume them from the R1. The R1 gets a brand-new Hermes every time (it still knows me via memory, just no chat history).
The Hermes gateway is what actually owns all those sessions in one store. Hermes already has a relay/enroll mechanism for external connectors to feed into the gateway. If the R1 connector routed through the gateway instead of (or alongside) spawning hermes acp, the R1 could list and resume my existing Telegram/desktop sessions, and the picker would actually populate.
Not sure how much work that is on your side, but figured I’d raise it as a direction. Even just being able to resume the gateway’s sessions from the R1 would be a big step up from the current clean-slate-per-session model.
One more: the Claude Code integration currently spawns a fresh claude CLI session when the R1 targets it, which also starts clean each time. Claude Code has a remote-control mode (its --session-id / resume and the /resume and /projects remote session handling) that lets you reattach to an existing CLI session instead of starting new. If the R1 connector could connect to an already-running Claude Code session (or at least resume a previous one by session id) the same way, that’d match how I actually use Claude Code on the desktop — pick up where I left off rather than re-explain everything. Curious whether the connector could target a live Claude Code session over its control socket instead of shelling out a new claude each time.