Supermemory Says MIT in the LICENSE File and 10,000 Documents in a Release Note
An agent memory engine with 30,000 stars, a plain MIT license, and a document cap you only find if you read the changelog.
The LICENSE file at the root of supermemoryai/supermemory is unremarkable. Twenty lines, MIT, "Copyright (c) 2025 supermemory," the standard permission grant with no additions, no riders, no asterisk. If you are the person on your team who checks licenses before a dependency goes into a build, this file passes in about four seconds.
Now open the release notes for server-v0.0.7, published August 15, 2026. The first bullet, headed supermemory lite, reads:
self-hosted is licensed up to 10,000 documents (read the license at git.new/memory); the cap is enforced at the API and shown at boot.
That is a licensing term. It restricts what the self-hosted server may do, it points at a license document that is not the LICENSE file in the repository, and it is enforced in code. None of it appears in the MIT text you just cleared.
I do not think this is a trick. Supermemory is a real project with real engineering behind it, roughly 30,000 stars, and a hosted business it is openly building. Dual-licensing a self-host tier is a completely legitimate thing to do. What interests me is the mechanics, because the mechanics generalize: the repository is telling you one thing in the place you were trained to look, and something else in a place you were not.
Why the mismatch is structural, not sloppy
A repository used to be a single artifact with a single license. You cloned it, you read LICENSE, you knew where you stood.
That model assumed the thing you run and the thing in the repo are the same thing. For a growing number of AI infrastructure projects, they are not. Supermemory ships a hosted API, a dashboard, a web app, and a self-hostable server binary installed with a curl-to-bash one-liner. The repo holds source for several of those. The binary is a release artifact. And the terms that bind the binary were stated when the binary was released, in the release notes, which is a reasonable place to put a product announcement and a terrible place to put a license.
Look at the release history and the shape is clear. The tags are not one sequence. There is a server-v0.0.x line for the self-hosted binary, running from 0.0.1 in June 2026 to 0.0.8 in August, and there is an archive/web-2026-09 tag from September 2 for the web app. One repository, multiple products, multiple release trains, and a single root LICENSE that was written for the source and now sits above artifacts it does not fully describe.
The enforcement detail is the part I keep coming back to. "The cap is enforced at the API and shown at boot." That is unusually honest. The limit is not buried in a terms-of-service page nobody opens; it prints when you start the server. A developer who runs it will see it. A developer who reads the LICENSE file and then approves the dependency in a procurement ticket will not.
Those are two different people, and in most organizations they are not in the same meeting.
What the cap actually constrains
Ten thousand documents sounds generous until you think about what feeds an agent memory system.
A memory engine's whole job is to accumulate. Supermemory extracts facts from conversations, maintains a user profile, and combines retrieval with that profile. Every ingested conversation, file, email or page is a document. A single team using this for a quarter of internal knowledge work can cross 10,000 without anyone deciding to. The cap is not sized for evaluation; it is sized for evaluation to end.
That is a normal commercial design. The thing worth saying out loud is that a cap enforced at the API fails at a specific and awkward moment: not at install, not in CI, but in production, the first time the corpus grows past the line. By then the integration is written.
Put this into practice
The generalizable move here is small and takes a few minutes per dependency. I would run it on anything that ships both a repo and a binary.
Read the release notes for the artifact you actually run, not just the repo root. The fastest way to do this without a browser is the Atom feed, which every GitHub repo exposes and which no cache sits in front of:
https://github.com/<owner>/<repo>/releases.atom
Search that output for the words "licensed," "license," "limit," "cap," "up to," "commercial," "beta," and "free for." Those seven strings catch most of what LICENSE files miss. For supermemory, "licensed" hits on the first bullet of server-v0.0.7.
Check whether the repo has more than one release train. If the tags fall into named prefixes (server-v, archive/web-, fleet-agent-v, sdk-typescript-v), the project is shipping multiple products and the root LICENSE probably predates at least one of them. Multiple trains is a signal to read more, not a defect.
Fetch LICENSE from the raw endpoint with a cache-buster, and read the text rather than the badge. README badges and rendered GitHub pages both serve stale values, and a badge is a claim about a file, not the file:
https://raw.githubusercontent.com/<owner>/<repo>/main/LICENSE?cb=20260919
Start the binary once before you approve it. Boot-time notices are becoming a real channel for terms. If a project says a limit is "shown at boot," the only way to see it is to boot it. Five minutes in a container beats finding out in production.
Write down the limit next to the dependency, not in a ticket. Whatever your team uses for dependency records, the line you want is the one a future engineer reads when the corpus is at 9,000 documents. "MIT" is not that line. "MIT source, self-host server capped at 10,000 documents per server-v0.0.7 notes" is.
Honest limitations
I have not run supermemory's self-hosted server and I have not read the license at git.new/memory, which is where the release note points. I am reporting on the gap between two documents in the repository, not on the substance of the commercial terms, and the shortlink may well contain a perfectly clear dual-license that resolves everything. If you are making a real decision here, read that document. My argument is about where the terms live, not what they say.
I am also not a lawyer, and nothing here is legal advice. Whether a release note constitutes an enforceable license modification against an MIT grant in the same repository is exactly the kind of question that needs a real answer from someone qualified to give one, and I do not know how it comes out.
The four-question routine above will not catch everything either. It catches terms stated in release notes, boot messages and multiple release trains. It will miss terms that live only in a hosted dashboard, only in a signup flow, or only in a document behind a shortlink, which is one of the things going on right here.
And the diligence habit costs something real. If you add a five-minute check to every dependency, you will do it for two weeks and then stop. The version that survives is narrower: run it on anything that ships a binary alongside the source, and on anything where a vendor has an obvious hosted business next to the open-source repo. Those two filters catch most of the surface without turning into a ritual.
Worth noting separately, because it bears on running this at all: server-v0.0.7 had a migration bug that silently wiped search vectors on stores upgraded from a release candidate. Documents stayed listed and returned nothing. Version 0.0.8, released two days later on August 17, detects and re-embeds the damaged rows automatically on boot. The team's write-up of that incident is candid and specific, which is a point in its favor, and it is also a reminder that the self-hosted path here is young.
What to do with this
Pick the three AI dependencies your team leans on hardest. Pull each one's releases.atom, search it for those seven strings, and see what you find. It will take you fifteen minutes and my guess is at least one of them surprises you.
The LICENSE file is no longer the license. It is one of the places the license might be, and on any project shipping both source and a binary it is probably not the most current one. That is not a conspiracy, it is just what happens when open-source repositories become the front door to commercial products. Adjust where you look.
Sources: supermemoryai/supermemory, its root LICENSE, and the release feed carrying the server-v0.0.7 and server-v0.0.8 notes.
Medium metadata
Title: Supermemory Says MIT in the LICENSE File and 10,000 Documents in a Release Note Subtitle: An agent memory engine with 30,000 stars, a plain MIT license, and a document cap you only find if you read the changelog. Tags: Open Source, AI, Software Engineering, Programming, Developer Tools