The repository is archived and read-only, last pushed in September 2025. The idea worth keeping is the sandboxed WebAssembly module, which bounds what an agent can touch in a way importing a library does not.
The project is archived
Modus is no longer maintained. Its GitHub repository is archived and read-only.
The details, checked on 2026-09-16 through the GitHub API rather than read off a
page: archived is true, the last push was 2025-09-11, and the last release
was cli/v0.18.2 on 2025-09-03. That is roughly a year of no development.
If you arrived here from a roadmap that lists Modus, that is the answer. Do not start a new project on it. The rest of this page is what it was and what the idea was worth, because the idea is better than its status suggests.
You can check the status yourself, and the same command works for any dependency:
gh api repos/hypermodeinc/modus --jq '{archived, pushed_at}'
What it was
From its own README, Modus was "an open-source, serverless framework for building agentic systems and AI apps in Go and AssemblyScript", built by Hypermode Inc. You wrote functions in Go or AssemblyScript, the framework compiled them to WebAssembly, and it executed them in a sandbox. It ran self-hosted or on Hypermode's commercial platform.
It reached 905 commits and around 419 stars before being archived.
The idea worth taking from it
Most agent frameworks are libraries. You import one, and your agent runs inside your process with your dependencies, your memory, and your blast radius.
Modus made the unit of execution a compiled WebAssembly module in a sandbox. That answers a question the library approach leaves open: what an agent is allowed to touch. A sandboxed module has the capabilities it was granted and no others, which is a stronger boundary than a code review of what a tool function happens to import.
That is the same instinct, arrived at from a different direction, as the isolation the Model Context Protocol builds into its architecture and that context isolation describes: give the untrusted part its own space and control what crosses the boundary. Archiving the project does not make the instinct wrong.
The second idea was the deployment shape. Treating an agent as a serverless function rather than a long-running process fits how agent work arrives, which is in bursts triggered by something else.
What to reach for instead
Nothing is a drop-in replacement, because the WebAssembly sandbox was the distinctive part and the common alternatives do not have it.
Write the loop yourself when the requirement is understanding rather than scaffolding. Manual implementation covers it in about forty lines, and it makes the case that most of what a framework adds is legible once you have written the loop once.
Adopt a maintained framework when you want the scaffolding. Claude Agent SDK covers what that buys: context management, sessions, permissions, and the file and shell tools an agent needs.
Reach for a protocol rather than a framework when the goal is to expose capabilities to an agent you do not control. MCP server covers that boundary, and it is the part of this problem with the most active work behind it.
If the sandbox was what attracted you, that requirement is worth naming explicitly when you evaluate alternatives, because it is the one most agent frameworks do not address at all.
Reading a dependency's status before you adopt it
The useful habit generalizes past this project.
An archived repository still has a working README, a documentation site that may still resolve, tutorials, and stars. None of those change when development stops. The signals that do change are the ones above: the archived flag, the date of the last commit, and the date of the last release.
Check those three before adopting anything, and check them again before a major version bump. It takes one API call.
Further reading
- Hypermode, modus on GitHub: the README, the archive notice, and the release history.
- Manual implementation: writing the loop instead of adopting a framework.
- Claude Agent SDK: a maintained framework and what it covers.
- MCP server: exposing capabilities across a boundary.
Knowledge check
Question 1 of 4
Sign in to save your progress and pick up where you left off.