Release Notes

What changed in each MMRY AI release.

1.28.1

Added

• Privacy choices on every page. A "Privacy choices" link in the footer of every page opens the opt-out control on the privacy page. A browser that sends the Global Privacy Control signal is opted out of analytics and advertising measurement automatically, and visitors from the European Economic Area and the United Kingdom are asked before any measurement tool loads, on public and signed-in pages alike. The privacy policy describes how each measurement tool handles IP addresses, how long it keeps data and what is shared. The help page has a "Your privacy choices" section.

Improved

• The home page and the AI memory page lead with lasting, shared context. The home page headline reads "Lasting, shared context for your whole team, in every AI tool you connect.", with one row below it linking to Formations, AI memory and AI database. The AI memory page opens with how MMRY AI keeps one shared, lasting context in your organization's account.
• Website analytics covers the signed-in pages. Visits to the account, records, administration, help, docs and release-notes pages are counted, reporting only the page name and the page you came from. Memory content, records, search terms, email addresses, account identifiers and security tokens are never reported, no advertising measurement runs on signed-in pages, and the opt-out on the privacy page applies to them in the same way. The privacy policy describes this in its "Signed-in pages" paragraph.

Notes

• This release updates the website only. Claude Code, Codex and connected assistants are not affected and need no update.

1.27.1

Added

• Formations page. Read how a Formation connects your team's AI sessions in Claude Code, Codex and ChatGPT on one initiative, at mmryai.com/formations.
• AI memory page. See how your memories follow you and your team across AI tools and computers, at mmryai.com/ai-memory.
• AI database page. See how your AI assistant builds a database for what you track and fills it in as you talk, at mmryai.com/ai-database.
• An AI database section on the Features page. The Features page now describes the AI database and links to the full page.

Improved

• The help page explains Formations in more detail. It covers when a message was read, how the roster shows a member who has moved on, and how check-ins work.
• Privacy policy describes the measurement tools and activities we use. The policy now explains the types of measurement tools and activities used on the site.
• General improvements and bug fixes. Improvements to the AI Platforms heading and address, the Features page layout, and account page accessibility, with header buttons of at least 44 pixels and a clearer Member view layout.

Notes

• This release updates the website only. Claude Code, Codex and connected assistants are not affected and need no update.

1.27.0

Added

• One simple price per user, with a credit pool your whole team shares. Every user adds the same monthly credit allowance to one pool the whole team draws from. If your team uses up the pool before the month ends, it refills right away and your billing date moves to that day. Trials convert to a paid plan the same way. See /pricing for the current price.
• Add and remove seats from your account page. Administrators change seats in the Seats row, see the price before confirming, and are charged on their current plan. It works with the keyboard, on phones and with screen readers, and the help page explains each step.
• Clear pricing and renewal details at sign up and checkout. Sign up, pricing and checkout explain when the paid plan starts and how monthly and early renewal work.
• Terms of service. Published at /terms and linked from sign up, checkout and the site footer.
• Renewal emails for administrators. Administrators get an email whenever the pool refills early or a trial converts, with the amount, the credits added and the new billing date.

Improved

• Seat changes are charged at exactly the price you preview. If anything changes before you confirm, you are asked to preview again.
• When billing needs attention, the Seats row shows exactly what to do next.
• Inviting people does not use credits.
• General improvements and bug fixes. Improvements to welcome emails, seat changes and early renewal.

Notes

• This release updates the service and the website. There is nothing to install or upgrade.

1.26.0

Added

• Keep track of things, not just notes, from Claude Code. Tell your assistant what you want to track, such as expenses, migraines or job applications, and it sets up a record type, files what you say, and later answers questions about the values: how many, which ones, since when, sorted by what. You can correct a record and see its earlier values. Records work the same in Claude Code, in connected assistants such as ChatGPT, Cursor, Claude Desktop and Codex, and in your account at mmryai.com/records.
• Each memory records which assistant saved it. When a named agent saves a memory, its name is kept with the memory and returned with it when memories are loaded, searched or exported.
• Corrections replace the memory they correct. In Claude Code and Codex, tell your assistant what is right and it saves the correction in place of the earlier memory, keeping who can see it.
• Every connected assistant knows what MMRY can do. The briefing an assistant receives names your memories, structured records and Formations, every MMRY tool response carries a short reminder, and loading your memories returns the full briefing.
• Formation members report to the lead. Every member of a Formation is told to report to the lead at each stopping point, and to acknowledge an assignment with what it understood and when to expect the result.

Improved

• Formation messages are easy to spot. In Claude Code and Codex, Formation messages now arrive under "MMRY AI Formation Transmission", and a session woken by one shows "MMRY AI: Formation Transmission".
• Prompts start sooner in a Formation on busy machines. The check for new Formation messages before each prompt is quicker, most noticeably on a busy Windows machine.
• General improvements and bug fixes. Improvements to Formation messaging, record type guidance, the plugin's packaging, data handling, and the help page on corrections.

Notes

• The MMRY plugin updates itself from the marketplace on your next Claude Code restart. In Codex, run codex plugin marketplace upgrade.

1.25.7

Added

• A Features page. A new Features page at /features explains what MMRY AI does for a team: sharing memories across the team, one memory across your AI tools, who sees each memory, memory groups, Foundation memories, saving and finding, Formations, and organization privacy.

Improved

• AI Platforms in the header. The list of supported AI tools is under the header link AI Platforms, at /ai-platforms, so it is easy to find from every page.
• The help page answers more Formation questions. It explains that read status belongs to the session that sent the message, what the roster shows when a recipient has left a Formation, and that each "Still listening." renewal is an ordinary Claude Code turn that counts toward your usage.
• General improvements and bug fixes. Improvements to site readability, including a higher-contrast line in the site footer.

Notes

• This release updates the website only. There is nothing to install or upgrade.

1.25.5

Added

• See when a Formation member has read your message. When you send a message to one member of a Formation, you can now see whether and when they read it.

Improved

• Prompts start faster on busy machines. Your Foundation directives are prepared once and shared by every part that carries them, so each prompt gets under way sooner, most noticeably on a busy Windows machine.
• Formation checks only where they apply. A session that is not in a Formation skips the Formation check entirely, and memberships from sessions that have ended are cleared away on their own.
• Formation members stay ready for messages for as long as they are in a Formation.
• General improvements and bug fixes. Improvements to Formation messaging and Foundation delivery.

Notes

• Claude Code: restart Claude Code to pick up the MMRY plugin update (2.10.2).
• Codex: run codex plugin marketplace upgrade to get the MMRY plugin update (2.10.2). This release updates one of MMRY's hooks, so the next time the Codex CLI starts it asks you to trust MMRY's hooks again. Choose Trust all and continue.
• Connected assistants (ChatGPT, Claude and others): nothing to do. Read status is already live.

1.25.0

Added

• MMRY AI now works in OpenAI Codex. Your memories load at the start of every Codex session, your Foundation directives stay in effect on every turn, messages from a Formation reach you as you work, and Codex is reminded to save what is new. You install it with the Codex plugin commands, trust MMRY's hooks (Codex runs none of them until you do), and sign in by running MMRY's setup yourself in a terminal, which is the simplest way. MMRY has been tested in the Codex command-line tool, which asks you to trust the hooks the first time it starts after installing. In the Codex desktop app, trusting MMRY's hooks could not be confirmed in this release. The Codex IDE extension does not support plugins at all, so MMRY does not reach it there.
• In Codex, one approval per conversation. Codex's default sandbox does not let a command reach the internet or write outside your project, and MMRY's save, search and Formation commands need both. The first time one is blocked in a conversation, your assistant asks for that access and Codex asks you to approve it. Approve it once and every MMRY command in that conversation works; a new conversation asks again. If you would rather not be asked, you can allow it permanently in your Codex settings, which widens the sandbox for everything the assistant runs, not only MMRY.
• What Codex does not have, so you are not looking for it. There are no slash commands: ask in plain words, such as "remember this". A Formation message does not wake an idle Codex session; it arrives the next time anything happens there. There is no prompt to save before a long conversation is trimmed, and none when a plan is accepted.
• You can check whether your Foundation directives reached your assistant. /mmry:foundation-status (in Codex, ask your assistant) says whether your directives were delivered on your most recent prompt: in full, in part, by a copy to read, or not at all, with the reason and what to do about it.
• You can see how big your Foundation set is. On the Foundation Memories page in the portal, an account administrator now sees the size of the whole set in characters and tokens, and how many memories that is. The figure updates as you add, edit, deactivate or restore a memory. We suggest keeping the total under about 10,000 characters, around 2,500 tokens, because the whole set is sent with every prompt and uses some of your assistant's working space each time. That is a recommendation, not a limit: nothing you write is trimmed, and the page tells you when your set is above it.

Improved

• Your Foundation directives are delivered in full. A set of up to about 57,000 characters now reaches your assistant in full with every prompt. Codex counts bytes rather than characters, so there a set with many accented or non-Latin characters fits a little less. A larger set is delivered too: your assistant is pointed to a complete copy and asked to read it before answering, you are told when that happens, and it may need your permission to read the file.
• More time to apply your Foundation directives each turn. The step that applies them each turn now has up to 20 seconds, so a busy machine has time to include them. If they cannot be applied, you are told so in plain words, with what to do.
• Longer memories are accepted. A memory can now be longer than 8,000 characters, and the memory form does not count characters against a limit. Formation messages and close-out summaries keep their own limits.
• A correction replaces the memory it corrects. When your assistant saves a correction to something it already remembers, the correction replaces the memory it names and keeps who could see the original. If the replacement cannot be made, nothing is saved and your assistant is told why.
• Closing out a Formation saves its record every time, or says why. Close-out saves the Formation's record and your summary, including for a Formation with nothing else lasting to record, such as a quick test Formation. If it cannot finish, it tells you why and whether trying again will help, and trying again does not save a second copy.
• The help page covers this release. It now explains how to use MMRY AI in OpenAI Codex, how your Foundation directives reach each assistant, how to see the size of your Foundation set and what a larger set costs, what to do when your assistant does not seem to follow your directives, and what happens when your assistant saves a correction.
• The API documentation is clearer for developers. It has worked examples for handing a conversation to MMRY to pick out what is worth remembering, including a save that replaces an outdated memory. It also states the one size limit that applies to a request, 64 KB for the whole request, and that a larger request is refused with a 413 and saves nothing.
• General improvements and bug fixes. Improvements to how your Foundation directives are checked, refreshed and delivered, including on a Mac, and a clearer setup message for new users on a Mac.

Notes

• The Claude Code changes arrive with the MMRY plugin update. Restart Claude Code to pick it up.

1.24.4

Added

• You can now keep track of things, not just write notes about them. Tell your assistant what you are recording, migraines, expenses, job applications, and it can design the shape of a record for you, file what you say against it in your own words, and later answer questions that depend on the values rather than on the wording: how many, which ones, since when, sorted by what. Your own words are kept intact alongside the fields, and a record is an ordinary memory in every other respect: it turns up in recall, in search and in your export, and it is yours to delete. It works through the MMRY connector (ChatGPT, Cursor, Claude Desktop, Codex), in your account area at mmryai.com/records, and over the API, on one account: a record type defined in one of them is visible in the others, and a record written in one is readable in the others.
• Claude Code joins with a later plugin update, and there is nothing for you to go and get. The record commands arrive with a later MMRY plugin update, which installs itself the next time you restart Claude Code, and the records you have already made will be there when it does. Until then, records are available through the connector, the account area and the API.
• Correct a record from wherever you are, and see its earlier values. Mark a task done in ChatGPT, fix a wrong number from Cursor, or tidy up an entry yourself in your account area without asking an assistant at all: it is one record, so the change is true everywhere the moment you make it, and only what you send changes. Every change is kept, including the values a record started with, so you can ask when a task moved to done or what a note said before you corrected it, from your assistant, from your account area, or in your export. A record's history is exactly as private as the record itself: nobody on another account can read it, and a refusal tells them nothing about whether it exists.
• How record types are created and recognised. A record type is designed by asking an assistant or by calling the API, and your account area shows the records you have and lets you correct them. The words a type carries help your assistant choose it when you tell it something. A save becomes a record when MMRY can tell which type it belongs to and has values for that type's fields. The type is the one you name, or the one whose match hints appear in your words; the values are the fields the save gives, or labelled lines such as "Amount: 25". Naming the type and giving its fields is the surest way. Without both, or when two types fit equally well, the save is stored as an ordinary memory with every word intact. A type created without them is named each time you record against it.

Notes

• Versions 1.24.1, 1.24.2 and 1.24.3 are not listed here because they were updates to our own documentation and internal tooling, with nothing new for you to use.

1.24.0

Added

• Your other AI tools can now join a Formation. A Formation is several assistant sessions working one job as a team, each seeing the others' short updates as it works, so two of them do not quietly change the same thing. Formations now reach beyond Claude Code: an assistant reached through the MMRY connector, such as ChatGPT, Cursor, Claude Desktop or Codex, can now see the Formations running on your account, join one you are entitled to join, tell the Formation what it is working on, and receive what the other members send. You ask it in plain words rather than with slash commands. This extends 1.22.2, when Formations were a Claude Code feature. Your memories work the same way in every tool you connect, as they already did.
• How coordination works over the connector. Over the connector a message is pulled rather than pushed: it reaches the assistant the next time that assistant uses an MMRY tool, and nothing arrives between tool calls, so an assistant sitting idle picks messages up once you give it something to do. Nothing is lost while it waits, and if you are expecting a reply, asking the assistant to check delivers it. A Formation is started in Claude Code, so if nothing is running on your account yet, someone on your team working in Claude Code starts a Formation and hands you its id. Closing a Formation out can be done from the connector when you are that Formation's lead, set its objective, or administer the account.

Changed

• The email a new account receives is now focused on one thing: a greeting, one sentence giving the reason to act, one sentence saying roughly how long setup takes and that the page covers whichever assistant you use, and a single button. It carries a genuine plain text version too, so a mail client that shows no formatting still gives you the whole message and the link. How accounts are created is unchanged.

Security

• A Formation is readable by the people in it. Reading a Formation is decided per person: you can read one if you are on its roster, if you set its objective, or if you administer the account, and having since left a Formation still counts. Anyone else gets the same answer they would get for a Formation that does not exist, so a Formation's existence is never confirmed to someone outside it, and the routes that change a Formation answer the same way. Joining a Formation whose id you were given works as before. The same per-person approach now covers the list of sessions on your account too; see the entries below.
• Breaking change, if you call the API directly: two fields are removed and a third is filled only on your own rows. createdBySessionId is removed from the Formation object, sessionId is removed from each member entry in a close-out summary, and sessionId on a roster entry is filled only on your own row, including in the replies you get back when you update a member or record progress. That identifier is what establishes a session's place in a Formation, so it is returned only to the person who holds it. Email addresses on the roster are kept, because an email address does not get anyone into a Formation and it is the roster's only human-readable label. The MMRY plugin and the connector do not read any of these fields, so if you use either of those, nothing changes for you.
• Your sessions are your own, and so is the identifier that binds them. A session is one assistant, on one machine, working in one folder, and a session now has an owner. You see your own sessions. An account administrator sees that the account's sessions exist and is shown who owns each one, because that is what administering an account needs, and the identifier that binds a session to its owner is shown only on that person's own rows, administrators included. The same protection extends to memories, which do not carry their author's session identifier when read or exported by anyone other than the author, to reading a session's working directory, which requires owning the session, and to coordination messages.
• It sets itself up and there is nothing for you to do, with one step for Formations. The first time one of your sessions checks in after the upgrade, it starts a fresh session that you own. No error, no sign-in, no step for you. A registration is refused only when somebody registers an identifier another person on the account currently holds. The one step: a session that was in a Formation before the upgrade rejoins that Formation once; the Formation, its history and its messages are untouched. Rejoining adds a new roster entry and the earlier entry stays on the Formation, so member counts and close-out records include it until those entries are tidied, which is tracked.
• One thing to know about memories saved in the minutes around the upgrade. The server fills in a memory's working directory from the session that saved it, for that session's owner. A memory saved between the upgrade and its session's first check-in is stored without a working directory, so folder-based recall does not match it; it stays fully readable through recall, search and export. The window is small and bounded by the upgrade itself, and we kept the information needed to add the folder to those memories later rather than guessing one.
• Breaking change, if you call the API directly: session identifiers are returned only to the people who own the session. GET /api/sessions/active returns your own sessions, and returns the account's sessions to an administrator with the owner named, with the binding identifier shown only on the caller's own row, administrators included. A memory you did not write, including in the memory export file, does not carry that identifier, and reading a session's working directory requires you to own that session. Registering a session identifier that somebody else on the account currently owns is refused with a 409. Registration is where a session acquires its owner. As above, the MMRY plugin and the connector need nothing from you.

Improved

• More dependable Formation message delivery on a Mac. The plugin now uses only what a stock Mac already has to receive Formation messages, so a message can reach an idle Claude Code session, a message that turns up while you are typing is handed over quietly, and the check made when a session starts is applied. Nothing needs installing: restart Claude Code to pick up the plugin version that carries it. If an idle Mac session still does not receive messages after you update, ask that session to run /mmry:formation status, which delivers anything outstanding straight away on any platform.
• Bursts of requests are handled smoothly. The API now holds its own work below the database's limit for requests in flight at once and queues the rest internally, so a batch of requests arriving together, which is ordinary when an assistant fires a batch of searches, is served. This applies to everything the API does, not only search. This is not a speed change and we are not claiming one. It does not make search faster; the time a search takes is unchanged.
• If you call the API directly, there is a new response to handle: 503 with Retry-After. When the API is momentarily at capacity it answers 503 with a Retry-After header. A 503 means the request was fine and the service was momentarily full: wait the number of seconds in Retry-After and send it again. That value is one to three seconds and is varied deliberately between callers, because the requests answered together are the ones that arrived together, so returning them all at the same instant would rebuild the burst; honour the value we give you rather than substituting a fixed delay of your own. 503 itself is not new to this API, but a 503 for capacity carrying Retry-After is, and it can come from any route. If your client treats any 5xx as permanent, update it to retry this one. This is not the 429 you may already handle: a 429 is about your quota, a 503 is the service itself being momentarily at capacity. Worth knowing: a request's credit is taken before the request is served, so a retry after a 503 costs another credit. In a healthy deployment a 503 should not appear at all; it is a safety net, not an expected answer.

1.23.0

Improved

• The service is ready to deliver formation messages sent at the very same instant. Sending at the same instant is not the coincidence it sounds like: it happens whenever two assistants speak at once, which is exactly the situation a formation exists to create. The service side is live, and the plugin side follows. Collecting messages this way also uses a change in the plugin, which arrives with a later plugin release. Until then everything you have works exactly as it did.
• Formation message delivery can now be looked into directly, without asking you to repeat anything. The call each member makes on a timer leaves a record of who asked, from what point, and how many messages came back. The content of your messages is never written to that record. Your transmissions stay where they were stored. The record also tells apart "there was nothing new" from "that session was not entitled to hear it", which is the first thing worth knowing about any delivery question.

Changed

• Breaking change: a session identifier longer than the supported length is refused with an error naming the field. Calls that send an over length identifier need updating, which is why we are calling this breaking rather than putting it under a general note. It means every caller is served against exactly the session it names. If you use the plugin or any of our own tools, nothing changes for you, and nothing changes for anything sending a valid identifier. If you call the API directly, check the identifiers you send.

Notes

• Our published figure for how one kind of timestamp rounds is now exact rather than estimated: 49,998 of every 100,000 values round backwards, which is about half. Nothing behaves differently.
• Two improvements to our own release process are included here for completeness. A single deployment is verified reliably, and every release script confirms the environment it reached. Neither is visible in the product.

1.22.2

Changed

• The website now says plainly which tools formations work in. At this release formations come with the MMRY plugin for Claude Code rather than with the MCP connector, and memories themselves work the same in every tool you connect. Reaching a formation member that is sitting idle also needs Claude Code 2.1.64 or newer, and on an older version nothing is lost: the message waits and arrives the next time that session does anything.

1.22.1

Changed

• The help pages now cover everything the 1.22.0 release added. Addressing a message to one member, the lead handing out work, declaring the areas you are working in, reporting progress, and the closing record are all documented, along with when a message actually arrives.
• The help page describes leaving a formation precisely: the roster keeps the record that your session took part and when it stepped away, and the count of current members drops by one.
• The API documentation now covers all sixteen formation endpoints.

1.22.0

Added

• An assistant can now send a formation message to one member instead of the whole team. Write it as /mmry:formation say "..." --to <member>, and use /mmry:formation roster to see who is in the formation and the member number to address. Only the member you name receives it, and that assistant is told the message was meant for it alone, so an instruction for one person reaches only them and everybody else carries on undisturbed. A message sent without naming anyone still goes to the whole formation, exactly as before. Addressing someone who has already left the formation is refused and nothing is sent, so you find out straight away and can re-address it. Requires plugin version 2.9.0.
• A formation lead can now hand out the work and see who is treading on whom. The lead assigns a piece of work to a named member, and only that member is told, so nobody else has to read an instruction that does not concern them. Members also say which parts of the code they are working on, and when two people claim overlapping ground both are warned, once each, with the other person's claim quoted. Claiming a whole repository is supported. Two areas that merely share the start of a name are not treated as a clash, and punctuation inside a path is never read as a wildcard. Requires plugin version 2.9.0.
• You can now see whether the work handed out in a formation actually got done. Each member records whether it took the work on, finished it, got blocked or gave up, and the lead sees that as it happens without having to ask. The closing record lists every member, what it was asked to do and how that ended, including anyone who reported nothing at all, who appears as not started. A member cannot change somebody else's record, while the lead can, so work somebody abandoned can be picked up. Requires plugin version 2.9.0.

Improved

• Messages sent inside a formation are put in front of the assistant they are meant for, including a session that is sitting idle and waiting rather than actively working. Reaching an idle session needs Claude Code version 2.1.64 or newer; on older versions messages arrive as soon as the session does anything, as the formation command help explains. Requires plugin version 2.9.0.
• Leaving a formation ends that session's part in it and frees it to join the next one, while the formation carries on for everybody else. The formation keeps a record that the session took part and when it stepped away, the member count drops accordingly, and everyone else carries on undisturbed.
• Short messages are delivered like any other. Something as brief as "done", "stop" or "files locked" goes through, with no minimum length. Blank messages are refused.
• Each formation message is shown to a member once.

1.21.3

Improved

• If you run several terminal windows on one account and have them join the same formation, a message you send appears once to each of the others and stays out of the window that sent it.

1.21.2

Added

• The team feature promised in 1.21 is now ready to use. Several assistants working the same job can work as one team: one of them starts a formation and says what the job is, anyone you already share a memory group with can join, and each assistant sees the others' short updates as it works. When the job is done, whoever started it closes it out with a summary of what was accomplished and learned. That summary is kept, and the running commentary stops.
• A formation is private to your organization, and only people who already share a memory group with its members can join one.
• Every update tells you plainly whether it was delivered, so you always know whether your team heard you.

1.21.0

Improved

• Groundwork only in this release. We built the foundation for letting several assistants work the same job as a team, and tightened how MMRY AI is built and released. Nothing changed in how the service behaves for you yet. We will say so here when the team feature is ready to use.

1.20.0

Improved

• Groundwork only in this release. We tightened how MMRY AI is built, tested and released, which makes future changes safer to ship. Nothing changed in how the service behaves for you.

1.19.0

Added

• Choose who sees a memory as you save it from Claude or another connected assistant, as well as in the account portal. You can name a memory group directly, and the assistant tells you which sharing choice was applied.
• Change who can see a memory you have already saved, from a connected assistant, without opening the portal.

Improved

• Shared memories are protected from unexpected edits. Whoever saved a memory can always change it, an administrator can correct one that is shared with the organization or with a group, and nobody else can. A private memory stays with its author alone. Every edit now records who made it and when, so an unexpected change can be traced.
• Clearer sharing language on the account screen. It now states plainly who can see your memories under each choice.
• Connecting MMRY AI to a new tool reads more clearly, and returning to a tool you have already connected shows a short confirmation, while a first connection gets the full explanation.
• General reliability improvements across the service.

1.18.0

Added

• Choose who sees each memory. Memories stay open to your organization by default. You can now keep one private to yourself, or share it with a specific memory group instead.
• Set your own default. Pick the sharing choice you want applied whenever you do not say otherwise, from the account portal or from the Claude Code plugin. An explicit choice on a single memory always wins.
• Memory group management in the portal. Administrators can create, rename and remove memory groups and manage who belongs to them, without leaving the account screen.
• Retire a memory group safely. Removing a group that still holds memories now asks where those memories should go, either private to whoever saved each one or into another group, so nothing is stranded and nothing becomes more visible than it already was.

Improved

• Clearer language throughout. The feature is called Memory Groups wherever you see it, and the sharing panel is fully usable on a phone.
• Signing up is more dependable, and every signup message tells you plainly what happened.
• General reliability and security improvements across the service.

1.17.0

Improved

• Clearer onboarding. The welcome email now helps you get started with MMRY AI across your AI tools.

1.16.0

Improved

• Clearer seat messaging. When you add teammates beyond the seats your plan includes, the account screen now explains the limit in plain language.
• Claude Code plugin sign-in feedback. If your saved sign-in expires, the plugin now lets you know so you can re-authenticate. Update to the latest plugin version.
• More dependable memory saving in the Claude Code plugin.
• General reliability and security improvements across the service.

1.15.0

New

• Search your memories on demand. The new /mmry:search command lets you look up what MMRY AI remembers about a topic in the middle of a session, and you can narrow the search to a specific area of your work.

Improved

• Teammate seats stay in step with your plan. When you invite or add teammates, MMRY AI now keeps you within the seats your plan includes and tells you clearly when it is time to add more, so there are no billing surprises.
• Turning off a connected application now takes effect right away. When you deactivate an app linked to your account, its access ends immediately.

1.14.3

Improved

• Faster, more focused session starts. Your assistant now begins each session with your core guidance in place, so sessions start quicker and stay relevant.
• Smoother pick-up where you left off. When you come back to work, the assistant starts with a sense of your recent activity, so you spend less time re-explaining context.

API

• Pagination on the public memory API. Memory results now come back in predictable pages, so external integrations stay fast and reliable no matter how much memory an account holds. See the API docs for the new page parameter.

1.14.2

Improved

• General improvements and reliability fixes for the Claude Code plugin. Update to version 2.1.1 for the latest.

1.14.1

Improved

• Clearer handling of duplicate topics. When an administrator adds a Foundation memory whose topic already exists, the screen now shows a plain-language message.
• Replace an existing entry. When a Foundation memory shares a topic with an existing one, you can now choose to replace it.

1.14.0

Added

• Manage your Foundation memories. Administrators can now view, add, edit, and deactivate the account's Foundation memories from a dedicated screen, and restore ones that were deactivated. Foundation memories are the core facts and values that apply across your whole account.
• Consistent guidance across your AI tools. Your Foundation memories stay in effect wherever you work, so your assistant applies them consistently.

1.13.0

Added

• MMRY now works inside your AI tools. Connect MMRY to ChatGPT, Claude, Cursor, and any assistant that supports the Model Context Protocol (MCP). Your assistant picks up every conversation where you left off, remembering your projects, preferences, and decisions, and the same memories follow you from one tool to the next.
• One-step setup, nothing to configure. Add the MMRY connector in your AI tool and it registers itself automatically. You just sign in and approve access to your account. No client IDs or secrets to copy or manage.
• Private to each person. Everyone signs in to their own MMRY account. Adding the connector for a whole team makes it available to all members, while each person's memories stay private to them.
• Privacy policy and consent. Added a published privacy policy, a site-wide legal footer, and clear consent at signup and checkout.
• See the docs for step-by-step connection instructions.

1.12.0

Added

• OAuth client management for admins. Account administrators can now register external AI platforms (ChatGPT GPT, MCP server, etc.) through a dedicated admin page. Create clients, rotate secrets, deactivate platforms, optionally revoke all active tokens on deactivation. Available at /admin/oauth-clients for users with the Admin role.
• Public API documentation. A curated OpenAPI 3.x spec at /openapi/v1.json describing just the public memory operations (load, search, save) and OAuth flow. Drop-in importable to ChatGPT's GPT builder Actions and MCP server tooling. It covers just the public operations.
• Friendlier rate-limit responses. When a request is rate-limited, the API returns a clear JSON message with a "try again in N seconds" hint, and the Authorize page displays that message.

Security

• Rotating an OAuth client's secret instantly revokes every active access and refresh token for that client. The platform sees its old tokens fail, refreshes against the new secret, and is back online. A stolen secret can't keep a tail of valid tokens alive.
• Deactivating an OAuth client removes it from new authorization flows immediately; existing tokens can be revoked at the same time with one checkbox.
• Admin secret-display modal shows the raw secret exactly once with an explicit warning that it can't be retrieved later.

Improved

• Behind-the-scenes reliability and release-process improvements.

1.11.0

Added

• Cross-platform integration foundation. MMRY AI now supports OAuth 2.0 authorization so external AI assistants can connect to your memories with your permission. The groundwork for upcoming ChatGPT, Copilot, Gemini, and Cursor integrations.
• Public /v1/ memory API. A clean three-operation surface (load, search, save) that external platforms call on your behalf. Your memories stay yours; platforms only see what they need to help.
• Authorization consent screen. When an external platform requests access, you log in to MMRY AI and explicitly approve. You stay in control of which platforms can read or write your memories.
• Per-platform usage tracking. Every external request is logged so you can see which platforms are using MMRY AI on your behalf.

Security

• OAuth tokens are stored only as SHA-256 hashes. The raw token is returned to the platform once and never logged.
• Refresh tokens rotate on every use. A stolen refresh token is invalidated the moment the real platform uses its replacement.
• PKCE (Proof Key for Code Exchange) is supported for platforms that use it, adding a second layer of protection against intercepted authorization codes.

Notes

• No external platforms are registered yet. The first registrations (ChatGPT GPT, MCP servers) are the next phase. Existing Claude Code plugin users see no change; the plugin continues to use the same authentication it already had.

1.10.0

Changed

• Brand alignment: the plugin is now MMRY AI. Slash commands moved from /mnemo: to /mmry:. Install path moved to ~/.claude/mmry/.
• Plugin version bumped to 2.0.0 to reflect the brand cutover.

Improved

• Plugin setup opens your default browser reliably from Git Bash, MSYS2, Cygwin, and WSL on Windows.
• Setup polling shows a "still waiting" status, so you can see setup is progressing.

Upgrade

• To move an existing install to the new name, run /plugin uninstall mnemo@mnemo-plugin then /plugin install mmry@mmry-plugin.

1.9.0

Improved

• Multi-hour sessions now produce memories reliably.
• Plugin auto-updates reach all installs, including legacy ones.

Changed

• Save reminders are less frequent and incremental.

1.8.0

Improved

• Saved memories preserve your content verbatim.
• Concurrent sessions stay separate.

Changed

• /mnemo:save returns a one-line confirmation of what was stored.

Removed

• /mnemo:remember (use /mnemo:save).

1.7.0

Improved

• Group and Private visibility honored on saved memories.
• /mnemo:save confirmations are concise and free of technical noise.
• Improved separation between concurrent sessions.

1.4.0

Added

• Automatic, server-side memory handling.
• Plugin self-update.

1.3.0

Added

• Export all memories as JSON.

Improved

• Clearer API responses: a request with a missing or malformed body is answered 400.
• A request with an unsupported HTTP method is answered 405.

1.2.1

Improved

• Refined top navigation alignment.

1.2.0

Added

• Invitation-based user onboarding.
• Browser-based device authorization for plugin setup.
• Account dashboard at /account.
• Trial-to-paid flow via Stripe checkout.
• Self-service password reset.
• Feedback submission.

1.1.0

Added

• Credit metering and auto-recharge.
• Volume-tiered subscription pricing.
• Stripe subscription management.
• 14-day free trial on registration.
• Memory visibility: Global, Group, and Private.
• Permission groups and access rules.
• Web-based login and registration.

1.0.0

Added

• Initial release.
• Memory storage, retrieval, search, and tier-based expiration.
• JWT and API key authentication.
• Multi-tenant isolation.