When you create a managed assistant, the model picker now pulls in the full OpenRouter catalog instead of a short curated list. That means you can browse and search across 500+ models from dozens of providers, all in the same dropdown. We also updated the defaults so new assistants start on the latest models.
This update makes it much easier to find and use the right model for your assistant, whether you want the latest flagship or a cost-effective option for simpler tasks.
Hermes assistants now support inbound email. When someone sends a message to your assistant's email address, it arrives as a structured webhook event that the agent can process, respond to, and take action on. This brings Hermes to parity with OpenClaw on one of the most requested messaging channels.
Email is one of the simplest ways to interact with an assistant without installing anything. With this update, both OpenClaw and Hermes assistants can be reached the same way.
Hermes assistants now come with a built-in terminal in the dashboard. That means you can open a live shell directly inside the assistant's container, inspect files, run commands, and debug issues in place instead of guessing from the outside.
This is the most direct way we have added yet to work with a hosted assistant like a real running system, not just a dashboard object. For Hermes users especially, it makes day-to-day debugging and inspection much more practical.
getclaw now supports Hermes Agent as a hosted framework. That means you can create a Hermes assistant directly from the product, deploy it through the same managed flow, and operate it from the same dashboard you already use for OpenClaw assistants.
This is a framework expansion, not just a new toggle. getclaw now supports two different open-source agent runtimes, which gives users a clearer choice between OpenClaw's operations-first model and Hermes's more personal, persistent-agent model.
Until now, each conversation with your assistant started from a blank slate. The assistant could be brilliant in the moment, but the next time you talked to it, all of that context was gone. Lossless-claw changes that. It gives every managed assistant a persistent, structured memory that grows over time — so your assistant gets more useful the more you use it.
This is a step change in what managed assistants can do. An assistant that remembers is fundamentally more useful than one that forgets — for ongoing projects, repeated workflows, and anything where continuity matters.
The infrastructure underneath managed assistants is now faster to start, easier to debug, and lighter on resources. This release removes unused dependencies from the container image, parallelizes data restores, and finally gives you visibility into what actually went wrong when a deploy fails.
Assistants start faster, and when something breaks during startup, you can actually see why.
Managing channels is now much cleaner, and the runtime underneath managed assistants just took a meaningful step forward too. This release adds a dedicated Messaging tab for channel setup and rolls hosted assistants onto OpenClaw 2026.3.13, which pulls in the biggest recent capability upgrades from upstream.
This is partly a dashboard release and partly an infrastructure one, but both sides matter. Channel operations are easier day to day, and managed assistants are now much closer to the current OpenClaw experience instead of lagging behind it.
Search is now available to every OpenClaw user, and it ships with unlimited usage from day one. No plan upgrade, extra toggle, or special setup required. If you already have assistants deployed, just redeploy each instance once to enable the new feature.
This is a meaningful capability release, not just a limit change. Search is now part of what every assistant can do, and if you already have one live, a redeploy is all it takes to turn it on.
OpenClaw assistants now have their own email address. They can check their inbox, send messages, and reply to threads — all as part of a workflow.
Email turns your assistant from something you talk to into something that can talk to others on your behalf — following up, reporting, and communicating without you in the loop.
OpenClaw can now use a real browser as part of its workflow. That means your assistant is no longer limited to APIs and text-only tools. It can move through the web the way a person would: opening pages, clicking buttons, reading content, and acting on what it finds.
This is one of the biggest capability jumps in the product so far. Giving OpenClaw a browser turns it from an assistant that can call tools into one that can operate directly on the web.
This release is about polish where it matters: assistants start more smoothly, the first-run experience feels more alive, and Telegram access is less likely to surprise you later.
Small release on paper, but it removes a lot of friction in the moments users actually notice: launch, preview, and trust.
Creating an assistant no longer means filling out forms. Just describe what you want in a conversation, and the wizard configures everything for you.
Two improvements to help you understand and manage running assistants faster.
Your assistant is no longer limited to a single messaging platform. You can now deploy to Telegram, Slack, Discord, or any combination of the three.
Until now, editing assistant files meant working through openclaw UI or redeploying from scratch. The new file editor gives you direct access to your assistant's files right from the dashboard.
This update improves how managed assistants preserve state, so restarts are less disruptive and recovery is more dependable.
We made this change because cloud browser automation setups were too fragile and required too much manual configuration. The goal of this release is to give you safer defaults, fewer deployment steps, and more reliable assistant behavior in isolated environments.
We are introducing first-class support for fully customizing your openclaw.json, alongside making assistant configuration easier to understand and more dependable.
This release focused on product clarity and assistant configuration flow.
This update focused on clarity and usability.
This release made external integrations more complete while improving day-to-day stability.
This patch focused on making managed usage more dependable.
A full pass on the landing experience improved readability and conversion-oriented messaging.
This was a major milestone for managed assistant billing and reliability.
Payments and production reliability moved from setup to functional rollout.
This release focused on improving security for critical user actions.
This is the first public foundation of the product.
When you create a managed assistant, the model picker now pulls in the full OpenRouter catalog instead of a short curated list. That means you can browse and search across 500+ models from dozens of providers, all in the same dropdown. We also updated the defaults so new assistants start on the latest models.
This update makes it much easier to find and use the right model for your assistant, whether you want the latest flagship or a cost-effective option for simpler tasks.
Hermes assistants now support inbound email. When someone sends a message to your assistant's email address, it arrives as a structured webhook event that the agent can process, respond to, and take action on. This brings Hermes to parity with OpenClaw on one of the most requested messaging channels.
Email is one of the simplest ways to interact with an assistant without installing anything. With this update, both OpenClaw and Hermes assistants can be reached the same way.
Hermes assistants now come with a built-in terminal in the dashboard. That means you can open a live shell directly inside the assistant's container, inspect files, run commands, and debug issues in place instead of guessing from the outside.
This is the most direct way we have added yet to work with a hosted assistant like a real running system, not just a dashboard object. For Hermes users especially, it makes day-to-day debugging and inspection much more practical.
getclaw now supports Hermes Agent as a hosted framework. That means you can create a Hermes assistant directly from the product, deploy it through the same managed flow, and operate it from the same dashboard you already use for OpenClaw assistants.
This is a framework expansion, not just a new toggle. getclaw now supports two different open-source agent runtimes, which gives users a clearer choice between OpenClaw's operations-first model and Hermes's more personal, persistent-agent model.
Until now, each conversation with your assistant started from a blank slate. The assistant could be brilliant in the moment, but the next time you talked to it, all of that context was gone. Lossless-claw changes that. It gives every managed assistant a persistent, structured memory that grows over time — so your assistant gets more useful the more you use it.
This is a step change in what managed assistants can do. An assistant that remembers is fundamentally more useful than one that forgets — for ongoing projects, repeated workflows, and anything where continuity matters.
The infrastructure underneath managed assistants is now faster to start, easier to debug, and lighter on resources. This release removes unused dependencies from the container image, parallelizes data restores, and finally gives you visibility into what actually went wrong when a deploy fails.
Assistants start faster, and when something breaks during startup, you can actually see why.
Managing channels is now much cleaner, and the runtime underneath managed assistants just took a meaningful step forward too. This release adds a dedicated Messaging tab for channel setup and rolls hosted assistants onto OpenClaw 2026.3.13, which pulls in the biggest recent capability upgrades from upstream.
This is partly a dashboard release and partly an infrastructure one, but both sides matter. Channel operations are easier day to day, and managed assistants are now much closer to the current OpenClaw experience instead of lagging behind it.
Search is now available to every OpenClaw user, and it ships with unlimited usage from day one. No plan upgrade, extra toggle, or special setup required. If you already have assistants deployed, just redeploy each instance once to enable the new feature.
This is a meaningful capability release, not just a limit change. Search is now part of what every assistant can do, and if you already have one live, a redeploy is all it takes to turn it on.
OpenClaw assistants now have their own email address. They can check their inbox, send messages, and reply to threads — all as part of a workflow.
Email turns your assistant from something you talk to into something that can talk to others on your behalf — following up, reporting, and communicating without you in the loop.
OpenClaw can now use a real browser as part of its workflow. That means your assistant is no longer limited to APIs and text-only tools. It can move through the web the way a person would: opening pages, clicking buttons, reading content, and acting on what it finds.
This is one of the biggest capability jumps in the product so far. Giving OpenClaw a browser turns it from an assistant that can call tools into one that can operate directly on the web.
This release is about polish where it matters: assistants start more smoothly, the first-run experience feels more alive, and Telegram access is less likely to surprise you later.
Small release on paper, but it removes a lot of friction in the moments users actually notice: launch, preview, and trust.
Creating an assistant no longer means filling out forms. Just describe what you want in a conversation, and the wizard configures everything for you.
Two improvements to help you understand and manage running assistants faster.
Your assistant is no longer limited to a single messaging platform. You can now deploy to Telegram, Slack, Discord, or any combination of the three.
Until now, editing assistant files meant working through openclaw UI or redeploying from scratch. The new file editor gives you direct access to your assistant's files right from the dashboard.
This update improves how managed assistants preserve state, so restarts are less disruptive and recovery is more dependable.
We made this change because cloud browser automation setups were too fragile and required too much manual configuration. The goal of this release is to give you safer defaults, fewer deployment steps, and more reliable assistant behavior in isolated environments.
We are introducing first-class support for fully customizing your openclaw.json, alongside making assistant configuration easier to understand and more dependable.
This release focused on product clarity and assistant configuration flow.
This update focused on clarity and usability.
This release made external integrations more complete while improving day-to-day stability.
This patch focused on making managed usage more dependable.
A full pass on the landing experience improved readability and conversion-oriented messaging.
This was a major milestone for managed assistant billing and reliability.
Payments and production reliability moved from setup to functional rollout.
This release focused on improving security for critical user actions.
This is the first public foundation of the product.
