DEV Community: Edward Izgorodin

Claude vs Coderabbit for code reviews? Where do we stand on this?

Edward Izgorodin — Mon, 19 Oct 2026 09:08:00 +0000

As of 17 October 2026, a code review from Claude can mean four things from Anthropic: the managed Code Review service, "out of research preview" since 15 October for Team and Enterprise organizations on GitHub and billed on token usage with no flat price per review; the /code-review command in Claude Code, on any plan; its cloud mode ultrareview, still "a research preview feature"; and the Claude Code GitHub Action in your own CI. CodeRabbit is a separate reviewer, billed per developer who creates pull requests, on GitHub, GitLab, Azure DevOps and Bitbucket, and also runs inside Claude Code as a plugin. Your Claude plan, code host and preferred billing unit decide the choice, and the answer is often both.

Every fact below comes from each vendor's own pages as I read them on 17 October 2026, and neither Anthropic nor CodeRabbit saw this text before publication.

Where things stand on 17 October 2026

	CodeRabbit	Claude Code Review (managed)	`/code-review` and ultrareview	Claude Code GitHub Action
Status	Free and open-source access plus four paid plans: Essentials, Team, Advanced, Enterprise	"out of research preview" since 15 October 2026	a Claude Code command; ultrareview is "a research preview feature"	a GitHub Action that runs Claude Code inside your repository's workflows
Who can use it	any team; Free gives PR summaries, with reviews in the VS Code extension and CLI	Team and Enterprise organizations, not Pro or Max; not with Zero Data Retention, the HIPAA configuration or CMEK	`/code-review`: "Anyone, on any plan"; ultrareview needs a claude.ai sign-in	anyone with a Claude API key or cloud provider credentials (Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry), or an OAuth token on Pro, Max, Team or Enterprise
Code hosts	GitHub, GitLab, Azure DevOps, Bitbucket Cloud and Data Center, plus GitHub Enterprise Server and self-managed GitLab	GitHub, GitHub Enterprise Server if Anthropic infrastructure can reach it, GitHub Enterprise Cloud with data residency	your local branch; `--comment` posts to a GitHub pull request, or to a GitLab merge request as a single note	GitHub; for GitLab, a separate integration "currently in beta" that GitLab maintains
What starts a review	every eligible pull request by default, skipping drafts, then later pushes until a pause after 5 reviewed commits by default; `@coderabbitai review` or `@coderabbitai full review`	per repository: Once after PR creation, After every push or Manual, skipping drafts and forks; `@claude review` for one review, `@claude review always` to follow later pushes	you run it	your workflow's events
What you pay for	a seat for each developer who creates pull requests: Essentials $24 per developer per month billed annually or $30 monthly, Team $48 or $60	token usage from usage credits, outside the plan's included usage, billed to the organization	`/code-review`: your plan's usage or API billing; ultrareview: 3 free runs once per account on Pro and Max, then "typically $5 to $25 in usage credits depending on the size of the change"	GitHub Actions minutes, plus API tokens, inference through your own cloud account, or your Claude subscription with an OAuth token
Where it runs	"Sandboxed cloud execution with your full repository cloned for isolated analysis"; self-hosted for Enterprise customers with 500 or more user seats	Anthropic infrastructure, read-only inside the review, no commits, "without building or running your code"	`/code-review` in your session as a background subagent; ultrareview in a cloud sandbox on Anthropic's infrastructure	your repository's workflows on GitHub Actions runners
How a finding is checked	a Verification agent among specialized agents working in parallel	"A verification step checks findings against the code before they're reported."	`/code-review` at `low` effort reports the findings it is most confident in; ultrareview: "every reported finding is independently reproduced and verified"	whatever your workflow asks for
What lands on the pull request	a walkthrough comment at the top of the pull request that summarizes the changes, then review comments that follow your pushes; `@coderabbitai approve` approves only when `reviews.request_changes_workflow` is enabled	inline comments marked Important, Nit or Pre-existing, a summary, and a check run that ends neutral or skipped, never as a failure	`/code-review`: nothing unless you pass `--comment`, and `--fix` applies the findings to your working tree; ultrareview: with `--post` on a github.com pull request, one comment from your own GitHub account	in the review workflow, an inline comment per issue, or one summary comment when it finds none
Training on your code	"CodeRabbit never uses customer code for model training."; code goes to "OpenAI and/or Anthropic for reviewing purposes only"	none under commercial terms (Team, Enterprise, API) unless the customer opts in	by account: commercial terms as for Code Review; Free, Pro and Max data is used for training when that setting is on	the same rule, by account

What is different since 15 October

Anthropic's announcement of 15 October 2026 reads "Code Review is out of research preview and available to Claude Team and Enterprise organizations." The cost page now says "Code Review has no flat per-review price." A review costs more with a higher review level, a larger change, more complex surrounding code and more candidate issues to verify, and it is billed to the organization, "not to the developer who opened the PR or requested the review." The figure of 15 to 25 dollars per review that older answers still give comes from Anthropic's launch article of 9 March 2026, written for the preview; a published average price per review was not found on the Code Review overview, setup, costs, pull requests or customizing pages as of 17 October 2026.

Admins pick a review level for the organization and for each repository: Quick is "A lighter pass. The fastest level, at the lowest cost", Standard is the default, and Deep "Takes the longest and costs the most". A repository added from the admin page "starts at After every push", the mode that "runs on each push, multiplying cost by the number of pushes". On speed, the announcement says "Most reviews now finish about 3x faster (~20 minutes down to 6-10 minutes) compared to during preview." The overview page adds that Code Review is not yet available to organizations that use customer-managed encryption keys (CMEK). Ultrareview was not part of the move, and its page says "A review typically takes 15 to 25 minutes."

If your team is on Pro or Max

The managed service is not on these plans; Anthropic's availability table marks Code Review for Team and Enterprise only. You can use /code-review, which "works on any plan" and counts toward your plan's usage; ultrareview, whose three free runs are "a one-time allotment per account" that does not refresh; and the GitHub Action with an OAuth token from your subscription. On CodeRabbit's side, the Free plan gives "PR summarization only; code reviews are available through the VS Code extension and CLI.", open-source projects "receive Team features with no paid subscription required", and "New organizations start with a 14-day Advanced trial".

If your team is on Team or Enterprise

The two vendors bill in different units, so a fair comparison needs your own counts. Anthropic bills each review from usage credits and suggests that you "estimate monthly spend from your own pull requests" before a wide rollout: cap Code Review spending for the month, turn it on for a few representative repositories in Once after PR creation or Manual mode, read the Average cost column, and multiply by your pull requests per month, and again by pushes per pull request for After every push. CodeRabbit charges a monthly seat for each developer who creates pull requests, and its pricing page says "There is no total limit on the number of pull requests or repositories you can review". Per developer, Essentials includes "5 PR reviews per hour" on a rolling window, the pricing page marks the hourly numbers "Subject to Fair Usage Policy", and reviews past the limit cost $0.25 per reviewed file only when usage-based reviews are turned on.

Claude Enterprise has one more line: "Eligible Claude Enterprise organizations can claim at least $10,000 in Code Review credits by January 15, 2027." By the terms, the amount is "between $10,000 and $50,000, based on your organization's active Claude Code seats", claimed once per organization, for reviews of pull requests on github.com, for 30 days from the claim or until it is used up, after which reviews are billed as usual. The exclusions include Team, Pro, Max and Free plans, organizations connected to GitHub Enterprise Server or a .ghe.com instance, and those that cannot use Code Review, and the credits do not cover the GitHub Action, /code-review or ultrareview.

Running both

CodeRabbit documents a plugin for Claude Code: after /plugin install coderabbit, the command /coderabbit:coderabbit-review has the CodeRabbit CLI review your changes, and Claude Code applies the fixes. Both vendors read CLAUDE.md: CodeRabbit "automatically detects coding guideline files such as .cursorrules, CLAUDE.md, and AGENTS.md in your repository and applies them as review criteria", while Anthropic notes that its service and /code-review "are two separate tools, and they read different files", the service reading REVIEW.md as well. Purchasing links them too: CodeRabbit joined the Claude Marketplace on 27 May 2026, where "Anthropic customers can apply their existing Anthropic spend commitment toward CodeRabbit", and Anthropic's listing says "Claude powers CodeRabbit's context engine and review harness". CodeRabbit's FAQ puts its case for review in one line: "the perspective of the reviewer differs from that of the code generator, whether human or machine".

How to choose

If this is true for your team	Look first at	What the pages say
Code lives on GitLab, Azure DevOps or Bitbucket	CodeRabbit	CodeRabbit lists all three; Anthropic documents a GitLab CI/CD integration in beta and `/code-review --comment` for merge requests, and `/code-review` reviews a local branch; Bitbucket and Azure DevOps were not found on Anthropic's Claude Code docs index or its Code Review overview page as of 17 October 2026
The bill should follow headcount, or only the reviews someone asks for	CodeRabbit for headcount; Code Review in Manual mode or `/code-review` for requests	CodeRabbit bills developers who create pull requests; Manual mode runs "no reviews on open or push"; `/code-review` counts toward normal usage
Zero Data Retention, the HIPAA configuration or CMEK	CodeRabbit, the GitHub Action or `/code-review`, after your policy owner reads each data page	Code Review and ultrareview are not available to those organizations
A tool must be able to approve as a required reviewer	CodeRabbit	`@coderabbitai approve` with `reviews.request_changes_workflow` enabled; Code Review's check run never ends as a failure, so a merge gate is a script in your CI that reads its Details
Claude Enterprise, eligible for the credits	Code Review, while the credits last	at least $10,000 for 30 days from the claim, github.com repositories only
Each candidate finding checked before it reaches the pull request	CodeRabbit, Code Review, ultrareview, or Sigma (Mnemoverse, the author's company)	CodeRabbit lists a Verification agent; Code Review describes a verification step; ultrareview says "every reported finding is independently reproduced and verified"; Sigma, in closed beta on GitHub by invitation, "checks potential issues and brings the evidence back to your code", and its docs say a fresh verifier "confirms, rejects or reclassifies each one", that "only confirmed candidates are verified findings" and that suspicions no verifier confirmed stay labeled separately; Sigma runs on Claude Code and OpenAI models and reviews its team's own repositories every day; its homepage takes requests through a "Request beta access" form and says "A request does not grant access automatically."

A test on your own pull requests

Both vendors leave room to measure before you commit. On Team or Enterprise, run Code Review in Once after PR creation or Manual mode under a monthly cap, as Anthropic's cost page suggests, and give a new CodeRabbit organization its 14-day Advanced trial; "Reviews beyond your plan's rate limits are free during your initial subscription trial." Choose ten merged pull requests that later needed a bug fix, so the right review comment is known in advance, recreate each from its original commits on a fresh branch, and let both reviewers read it. For every comment, write down whether it names the known bug and whether you would delete it, and for every pull request, the cost in each vendor's own unit. On Claude Enterprise, read the credit terms first: "Set up Code Review on your repositories before you claim.", because the 30 days start at the claim.

Sources, all read on 17 October 2026. Anthropic: Code Review, setup, costs, pull requests, customizing, /code-review, ultrareview, GitHub Actions, feature availability, data usage, GitHub Enterprise Server, GitLab CI/CD, docs index, general availability article, Enterprise credit terms, March launch article, CodeRabbit in the Claude Marketplace. CodeRabbit: pricing, plans, rate limits, usage-based reviews, automatic reviews, platforms, FAQ, architecture, review commands, self-hosted, coding guidelines, Claude Code plugin, Claude Marketplace news. Sigma: homepage and reading a review.

What options exist for connecting an AI agent memory layer across both ChatGPT web interfaces and localized coding environments?

Edward Izgorodin — Sun, 18 Oct 2026 09:39:00 +0000

TL;DR

ChatGPT on the web and local Codex do not share one built-in memory store. OpenAI says ChatGPT web uses ChatGPT memory, while local Codex uses separate local memory and controls.

One documented bridge is a hosted remote MCP memory service, connected once in ChatGPT and again in each coding client. Every client keeps its own configuration and OAuth session.

Browser-extension products bridge the ChatGPT page directly and reach coding tools through MCP. A local server can reach ChatGPT through a tunnel. OpenAI also offers narrower ChatGPT-to-Codex bridges: Computer History and dots.

A memory layer can sit beside ChatGPT. It cannot be ChatGPT memory: OpenAI documents no interface through which a memory layer reads or writes it, though with Memory on ChatGPT may pass relevant memory context to an app while it responds.

An AI agent memory layer is an external store and retrieval service that makes saved knowledge available to several AI clients under one account or memory space.

Connecting that layer across ChatGPT and local coding environments takes two separate integrations. ChatGPT needs a web-side connection. Claude Code, Cursor, VS Code, Codex, or another coding client needs its own MCP configuration.

That split follows OpenAI's product design. OpenAI states that "ChatGPT web uses ChatGPT memory, while local Codex clients use a separate local memory store and controls." ChatGPT web also "doesn't read local Codex configuration files or expose the local Codex command menu."

This page compares published documentation and Plugin Directory results read on 2026-10-09, with every quotation re-checked on 2026-10-10 and again on 2026-10-17. It does not report product testing, except one dated Mnemoverse check, disclosed below.

The four documented bridge patterns

The approaches differ mainly in where the ChatGPT-side connection runs.

Bridge pattern	ChatGPT path	Coding-tool path	Main constraint
Hosted memory over remote MCP	Published plugin or custom MCP server added by URL	Remote MCP entry in each coding client	Plan limits in ChatGPT; separate setup and OAuth sign-in in every client
Browser extension plus MCP	Extension inside the ChatGPT page	Hosted or local MCP server	Extension availability, browser support and maintenance become part of the system
Local server through a tunnel	Custom MCP server pointed at a public HTTPS tunnel or a Secure MCP Tunnel	Local MCP server connects directly to coding tools	The local process and tunnel must stay up
OpenAI Computer History or dots	Built into eligible ChatGPT experiences	Codex or local computer tasks through the ChatGPT desktop app	Limited by plan, platform, market and mobile eligibility

A hosted MCP service lets one provider serve otherwise separate clients. It does not merge their built-in memories. Instead, each client reads from and writes to the external layer.

A browser extension changes the ChatGPT side of the design. Plurality says its extension "embeds within the UI of ChatGPT, Claude, Gemini, Perplexity, and Grok," while its MCP server carries the same memory buckets into coding workflows. MemoryPlugin lists a "Browser extension (Chrome + Safari, mobile too)" alongside a "Hosted MCP server (plus local)". Memwyre describes clipping decisions from the web and querying them "inside Claude Code, Cursor, and your terminal CLI".

Pieces documents a local-first variation. Its ChatGPT setup exposes a locally running PiecesOS MCP server "via ngrok or another HTTPS proxy", and "The tunnel must be active when you add the connector and when you use ChatGPT." OpenAI separately documents a Secure MCP Tunnel for servers on a private network or a developer machine.

ChatGPT custom MCP servers, remote MCP, and plugins

A remote MCP server is an MCP endpoint that a client reaches over the network rather than launching as a local process.

OpenAI's help article answers the question "Can I connect to a local MCP server?" with "Not directly. ChatGPT connects to remote MCP servers." Its developer guide lists "SSE and streaming HTTP" as supported protocols.

A custom MCP server is an MCP server that a user or admin adds to ChatGPT by URL, while a published plugin is listed in OpenAI's Plugin Directory and can reach more ChatGPT surfaces.

OpenAI's documentation uses both terms, and its help article says that in the current Plugins experience "You don't need to turn on Developer Mode first." The developer guide says to "Connect your Model Context Protocol (MCP) server to ChatGPT as a plugin." Authentication can be "OAuth, No authentication, and OAuth or no authentication." ChatGPT supports read and write tools, respects the readOnlyHint annotation, and treats tools without it as write actions. "Write actions by default require confirmation."

Plan support needs careful wording:

OpenAI's help article says "Custom MCP server connections and full MCP support are available for ChatGPT Business and Enterprise/Edu customers on ChatGPT web."
The same article says "Pro users can connect custom MCP servers with read/fetch permissions."
The article does not name Plus, read 2026-10-17.
OpenAI's custom MCP developer guide names no plans.

A vendor may publish broader plan claims. Pieces names "Pro, Plus, Business, Enterprise, or Education" in its own guide. That is a Pieces statement, not confirmation from OpenAI's help article.

Custom MCP server connections are documented as web only: to "Can I connect custom MCP servers on mobile?" the help article answers "No - web only." Published plugins have wider reach. OpenAI says "Plugins work in Chat and Work across ChatGPT on the web, desktop, and mobile, and in Codex in the ChatGPT desktop app." The Codex IDE extension does not support plugins. Saving a plugin with local apps "does not make those tools available on web or mobile."

Workspaces add one more delay. "After an admin first approves an MCP server connection for the workspace, ChatGPT uses a 'frozen' snapshot of its available tools and inputs." A memory tool the vendor adds later reaches the workspace only after an admin publishes the update. OpenAI's own apps do not fill the gap: "OpenAI-built apps are search-only today and do not support write actions."

The ChatGPT Plugin Directory

OpenAI says "ChatGPT and Codex share one universal plugin directory." OpenAI's help article adds: "In Codex, directory changes can take up to 6 hours to refresh."

A Plugin Directory search on 2026-10-09 by the names of the layers on this page found Basic Memory Cloud and Supermemory ("Universal context and memory"). The other names, Mnemoverse included, returned no card. A broader search for "memory" returned 47 cards, so those name matches are not a complete inventory of memory plugins. The directory refuses scripted fetches, so these results were not re-fetched on 2026-10-10.

Basic Memory recommends its published plugin because it "does not require Developer mode or a server URL." The vendor says "Basic Memory Cloud is required" because ChatGPT connects to the hosted service, and warns: "Plugin availability can depend on your ChatGPT plan, region, workspace settings, and role."

OAuth and account identity determine whether memory is shared

OpenAI's plugin authentication expects "an OAuth 2.1 flow that conforms to the MCP authorization spec", with "Client ID Metadata Documents (CIMD), dynamic client registration (DCR), predefined OAuth clients, and PKCE."

The practical consequence is that identity must line up across clients. The account on the memory host is what is shared. The session is not.

Devin states this directly: "Each MCP client (Windsurf, Claude Code, Devin CLI) maintains its own OAuth session, so you must log in separately even if you've already authenticated in another tool." Zep says each person "signs in with a work email and reaches their own Zep user graph in the selected Zep project."

A plugin install is not a universal installation event. Zep: "A plugin install in the Claude app or in ChatGPT does not install the plugin in these coding agents." Each coding tool still needs its own remote MCP entry. How such sharing can stop while every client looks healthy: MCP servers that share state across IDEs.

Claude Code, Cursor, VS Code, Devin, and Codex setup

Each coding client has its own place for remote MCP configuration. Its built-in memory also stays separate from the external layer.

Coding tool	Remote MCP configuration	Built-in memory
Claude Code	`claude mcp add --transport http <name> <url>`; OAuth sign-in through `/mcp`; a team entry can live in `.mcp.json` "at your project's root directory"	"Auto memory is machine-local."
Cursor	A `url` under `mcpServers` in `~/.cursor/mcp.json`; "Cursor supports OAuth for servers that require it."	"Rules provide persistent, reusable context at the prompt level."
VS Code	Workspace-root `.mcp.json` uses `mcpServers` and is listed as "Preferred for configurations that you share with your team and compatible tools."; `.vscode/mcp.json` uses `servers`; "A browser window opens for authorization on the first connection to the server."	"User, repository, and session memory are stored locally on your machine."
Devin Local or CLI	Local configuration files; the CLI adds servers with `devin mcp add` (by default to `.devin/mcp_config.local.json`; `-s user` writes `~/.config/devin/mcp_config.json`) and signs in with `devin mcp login`	"The Devin Local agent does not persist memories between sessions."
Codex	`~/.codex/config.toml`, shared by the ChatGPT desktop app, Codex CLI and IDE extension; `codex mcp login <server-name>`	Local memories live under `~/.codex/memories/` and "are off by default."

Claude Code: "HTTP servers are the recommended option for connecting to remote MCP servers." It supports OAuth 2.0. Cursor reads a global ~/.cursor/mcp.json "for tools available everywhere". VS Code's Settings Sync can carry "MCP server configurations" between machines; its documentation lists no memory sync, and memory is "stored locally on your machine."

Codex supports CIMD and DCR for OAuth (Codex MCP). Its memories.disable_on_external_context setting, "when true, keeps chats that used external context such as MCP tool calls, web search, or tool search out of memory generation."

These settings matter because an external memory service and a client's native memory can both be active. They remain different stores with different controls. For which client holds whose memory, see MCP memory servers for Claude Code and Cursor; for what MCP itself standardizes, What is an MCP memory server?

What a connected memory server can see

A connected MCP server does not receive ChatGPT's internal memory store.

OpenAI warns that a server "will have access to whatever data ChatGPT supplies during the interaction, potentially including sensitive data the user may earlier have provided to ChatGPT." Its plugin guidelines set the boundary: "Your MCP server must not pull, reconstruct, or infer the full chat log from the client or elsewhere."

The plugin and MCP paths bring tools into ChatGPT, not ChatGPT memory out of it. OpenAI's developer guides and API reference, read 2026-10-10, describe no endpoint that reads or writes ChatGPT memory. Sign in with ChatGPT "does not independently share" "Your ChatGPT conversations or memory." Uploading exported conversations to another account does not "Transfer custom instructions, memories, GPTs, or other account settings."

The Enterprise Compliance API is narrower still. Read 2026-10-09, its memory endpoints cover "exporting and spot-deleting ChatGPT Enterprise workspace Memories." They read or delete; none writes.

Connected apps can still touch ChatGPT memory from inside ChatGPT. OpenAI says an app responding to you "may also leverage relevant information from memories", so that "the app may access and use relevant context from your memories", and "ChatGPT may remember relevant information accessed from the app, unless that app or connected source restricts Memory from saving that information."

Data-use settings also apply. The same page: "For ChatGPT Business, Enterprise, and Edu customers: OpenAI does not use information accessed from connectors to train models by default. For ChatGPT Free, Plus, Go, and Pro users: OpenAI may use information accessed from apps to train our models if your 'Improve the model for everyone' setting is on."

Memory-layer options documented by vendors

Each row summarizes the vendor's own documentation, read 2026-10-09 and re-checked 2026-10-10. The rows are documentation claims, not a ranking and not a test.

Memory layer	ChatGPT route	Coding route	Documented limitation
Basic Memory Cloud	Published plugin	Any MCP client: "Notes created in Codex are immediately available in Claude Code, Cursor, Claude Desktop, or any other MCP client."	The hosted Basic Memory Cloud is required for ChatGPT
Supermemory	Plugin Directory entry, or the documented ChatGPT Web MCP setup	OAuth remote MCP, "a shared memory layer" for MCP-compatible assistants	Its browser extension was removed from its repository on 7 September 2026 (commit)
Cognee Cloud	Developer mode; connectors "are tied to your ChatGPT account, so the web and desktop apps share them"	"Any client that supports remote MCP servers with OAuth", including Claude Code	Developer mode, so OpenAI's plan limits apply
Zep	Plugin; hosts include "ChatGPT (Business, Enterprise, or Edu)" (Zep)	Help centre: plugin in Claude Code, Codex CLI and Cursor (Teams or Enterprise); remote MCP with OAuth for VS Code, GitHub Copilot and Gemini CLI	"The plugin does not work in the Codex IDE extension." "The plugin does not ingest a codebase." The README of the plugin's own repository says it is "Not positioned for Claude Code, Codex, or other coding-agent CLIs" (details)
Mem0	OpenMemory browser extension, still installable from its Chrome Web Store card	Mem0 MCP for "Claude, Claude Code, Codex, Cursor, Windsurf, VS Code, OpenCode"	ChatGPT is not described as a Mem0 MCP client; the extension's source is archived since 23 March 2026, and Mem0 removed the OpenMemory project from its monorepo in July 2026 (details)
Letta	No documented ChatGPT MCP path	Hosted MCP for clients "such as Claude Code, Cursor, or another agent"	"The client must support custom bearer headers; OAuth-only clients are not supported yet."
MemoryLake	Developer-mode plugin: "paste your Server URL, with No Auth as the authentication method."	"Every client that speaks MCP", naming Claude Code and Cursor	Its ChatGPT page uses No Auth; its MCP docs describe "standard OAuth2" for remote MCP clients
Plurality AI Context Flow	Browser extension for Chrome, Opera, Edge and Brave, or MCP	MCP server	The extension carries the ChatGPT side
MemoryPlugin	Browser extension, or a Custom GPT	Hosted or local MCP server	The Custom GPT route depends on custom GPTs, which "are scheduled to retire on Dec 11, 2026"
Memwyre	A Chrome and Edge extension clips decisions from ChatGPT conversations into its memory graph; a Custom GPT Action searches and saves memory	Queries in Claude Code, Cursor and the terminal	The two-way ChatGPT path is a Custom GPT Action, and custom GPTs "are scheduled to retire on Dec 11, 2026"
Pieces	Local MCP exposed through ngrok or an HTTPS proxy	Pieces MCP for Claude Code, Cursor, VS Code and JetBrains	"PiecesOS must be running locally", and the tunnel must stay active
Mnemoverse (the author's company; vendor row)	Custom MCP server added by URL, with browser sign-in; no Plugin Directory card in the 2026-10-09 search	Claude Code, Cursor, VS Code, Devin Desktop, Codex CLI and IDE extension (install by host)	Submitted to the Plugin Directory, not listed as of 2026-10-11; `vault_list` withheld in ChatGPT (tool availability); the owner reported on 2026-10-11 that sign-in from Codex and Devin works, with no memory call recorded, so install by host still marks those routes not verified live. Own check, 2026-09-27: an existing connector on ChatGPT Pro passed a stats call, a write and a read; sign-in, custom MCP server creation and Plus were not tested

Mnemoverse, the author's company, is the vendor row above. Its hosted server is https://mcp.mnemoverse.com/mcp (remote MCP server, ChatGPT), so OpenAI's plan limits apply to it as they do to every layer added as a custom MCP server. Its account rule: "a fact stored in one tool is available to every other tool on that account." Rooms, in Beta, is a memory space shared across Mnemoverse accounts.

OpenAI's Computer History and dots

OpenAI offers two narrower bridges between ChatGPT context and local work.

Computer History "turns your activity across apps and websites into memories and a timeline that ChatGPT and Codex can reference." It "is off by default for ChatGPT Pro, Business, and Enterprise users in the ChatGPT desktop app on macOS." It generates "the same kind of local memories as Codex": plain-text Markdown files that, in OpenAI's words, "other programs running as your macOS user may be able to access". It "also requires Memories and is not available with an API key or Amazon Bedrock."

A dot "starts with relevant context from ChatGPT memory", but its notes are "separate from ChatGPT's saved memory". "With local computer access enabled, your dot can create Work or Codex tasks", and connecting a computer takes the ChatGPT desktop app on that machine. A dot can be created "in the ChatGPT mobile app on iOS or Android, the desktop app, or on desktop web", but "Dots are not supported on mobile web."

OpenAI's release notes of September 29, 2026 describe a gradual rollout "to eligible Pro and Business Premium users aged 18 and older in supported markets", and "Pro access excludes the European Economic Area, Switzerland, and the UK at launch." OpenAI's dot article adds that for Enterprise, including Edu and Healthcare, the beta must be enabled by the workspace admin and is off by default.

Custom GPTs are not a durable substitute. OpenAI's retirement FAQ says they "are scheduled to retire on Dec 11, 2026"; "For affected Enterprise workspaces with an approved deferral, the retirement date is Feb 11, 2027." For affected Enterprise workspaces it also lists "Oct 26, 2026 (planned): Creation of new custom GPTs ends," and notes that "the dates are subject to change." Personal accounts "cannot create or publish new GPTs", and "Custom actions do not transfer through the migration workflow."

Six steps to one memory in ChatGPT and your coding tools

Check what your ChatGPT plan allows on OpenAI's help article and developer guide quoted above.
Pick a layer whose ChatGPT side is documented, and the bridge you want: plugin, custom MCP server, extension or tunnel.
In ChatGPT on the web, add the layer's plugin from the Plugin Directory, or its server as a custom MCP server by Connect to ChatGPT; a server on your machine goes through Secure MCP Tunnel.
In each coding tool, add the same server address to its MCP configuration, and sign in there if the layer uses OAuth.
Use the same layer account everywhere.
Expect write actions to ask for confirmation by default, and the server to see what ChatGPT supplies in the conversation.

Common questions

What options exist for connecting an AI agent memory layer across both ChatGPT web interfaces and localized coding environments?

As of 2026-10-09, four are documented: a hosted memory layer over remote MCP, connected separately to ChatGPT and to each coding tool; a browser extension inside ChatGPT paired with an MCP server; a local MCP server exposed to ChatGPT through a tunnel; and OpenAI's Computer History or dots, which bridge ChatGPT and Codex through the ChatGPT desktop app. One memory everywhere means the same layer account in every client.

Can an external memory layer read ChatGPT's saved memory?

Not directly: OpenAI documents no interface that gives a memory layer read or write access to ChatGPT's memory, read 2026-10-10. A connected app gets what ChatGPT supplies during an interaction, and with Memory on that can include relevant context from your memories. In the other direction, ChatGPT may remember relevant information it got from an app.

Does connecting a memory plugin in ChatGPT also connect Claude Code, Cursor, VS Code, or Codex?

No. Each coding client needs its own MCP configuration and, when OAuth is used, its own sign-in.

Which ChatGPT plans support custom remote MCP servers?

OpenAI's help article says custom MCP server connections and full MCP support are available for Business and Enterprise/Edu on ChatGPT web, while Pro can connect custom MCP servers with read and fetch permissions. Neither that article nor OpenAI's custom MCP developer guide names Plus, read 2026-10-17.

Do ChatGPT MCP apps work on mobile?

OpenAI documents custom MCP server connections as web only. Published plugins work across ChatGPT web, desktop, and mobile, although availability can still depend on plan, region, workspace settings, and role.

Can ChatGPT and local Codex use the same built-in memory?

OpenAI documents ChatGPT memory and local Codex memory as separate stores. Computer History and dots are OpenAI's bridges for eligible users, with platform, plan, market, and mobile restrictions.

Sources

Every page below was read on 2026-10-09, and every quotation on this page was re-checked against its page on 2026-10-10 and again on 2026-10-17. On 2026-10-10 help.openai.com refused scripted fetches, so its articles were re-checked against archived copies dated 2026-09-08 to 2026-10-08, and the Compliance API specification could not be re-fetched; on 2026-10-17 both were read live through the r.jina.ai reader. The Plugin Directory search could not be re-run and rests on the 2026-10-09 reading.

Edward Izgorodin · Mnemoverse · 2026-10-17

How to maintain session knowledge across a fleet of specialized developer bots?

Edward Izgorodin — Sat, 17 Oct 2026 06:21:00 +0000

On Monday the test-fixer bot spends a whole run finding out why test_refund_webhook fails about once a day: it shares a Redis database with test_retry_queue and fails whenever it runs second. The bot opens a fix and the run ends. On Wednesday the reviewer bot meets the same failure on a branch cut before the fix and asks the author to look into a flaky test. On Friday the release bot holds the release over it. Each bot did its job. What the fleet learned on Monday lived in one run's context and ended with it.

The short answer: treat every bot run as a session that starts empty, and keep what the fleet learns in one store outside the runs. Each bot reads from it before it acts and writes to it the moment it concludes something that will still hold on its next run. What only its role needs goes to a scope of its own, what any bot could trip over goes to one project scope that every bot reads, and a bot catching up on what the others found lists everything new since its last run instead of searching for it. When the bots run under different accounts, the shared scope moves to a store both accounts are members of.

Session state and session knowledge

Session state is what a run holds while it works: the diff, the logs, the plan for its next step. Session knowledge is what the run concluded that will still be true on the next run: a diagnosis, a fact about the repository, a warning for the bot that comes after. State should end with the run. Knowledge is what the fleet loses when it does.

A fleet loses it faster than a single assistant. Every run is a fresh process started by a webhook or a CI job, no person in the loop remembers, and the bot that finds a fact is rarely the one that needs it next. The SAMEP paper (arXiv:2507.10562) opens its abstract with both gaps: "Current AI agent architectures suffer from ephemeral memory limitations, preventing effective collaboration and knowledge sharing across sessions and agent boundaries." Between runs is the session boundary; between bots, the agent boundary.

Three kinds of knowledge, three readers

Kind	Example	Written by	Read by	Where it goes	How it is read
Role lesson	"Maintainers here reject a new dependency without a lockfile change"	the reviewer	the reviewer	the reviewer's own scope	search by the task at hand
Repository fact	"`test_refund_webhook` fails after `test_retry_queue`: both use Redis database 0"	the bot that confirmed it	every bot	the project scope	search by the task at hand
Handoff	"PR 812 adds migration 0042; deploy it before the worker change in PR 815"	the bot that found it	the next role	the project scope	list everything since the last run

The third row is the one fleets miss. A handoff is addressed to a role, not to a question, and the release bot does not know to ask about migration 0042. A search returns what resembles the query, so a handoff unlike anything the release bot asks stays out of the results, and nothing in them shows it was missed. Hence the rule: search for lessons, list for handoffs.

One run, start to finish

Read its own scope, then the project scope, with the task as the query.
List what is new in the project scope since this bot's last run, and keep the time this run started, not ended, for the next one.
Do the work.
Write each conclusion when it is reached, not in a summary at the end: a CI job that hits its timeout is killed mid-run. Write the sentence for a bot that never saw this run, with its evidence ("seen in CI runs 4411 and 4417").

If every bot in the fleet is GitHub's own

Then sharing what one bot learns about the repository is built in. GitHub's page About GitHub Copilot Memory says Copilot Memory "is currently used by Copilot cloud agent, Copilot code review, Copilot CLI, and agentic autofix", and that "Facts and preferences captured by one Copilot feature can be used by another." Repository facts there "are stored with citations pointing to the code that supports them", which Copilot checks against the current branch before it uses a fact. The feature is in public preview. The rest of this article is for bots you build yourself, which share only what they write to a store they all call.

A minimal version in code

The code below uses Mnemoverse (the author's company) through mnemoverse 0.4.0 from PyPI. Each scope in the table is a domain, the domain argument of a read, a listing or a write. The multi-tenant guide gives the naming patterns agent:{agent_name} and project:{project_id}, so the reviewer's scope is agent:reviewer and the fleet's is project:orders-api. A read that names a domain returns only memories from that domain, so the priority order the guide sketches, own scope first and shared ones after, is the bot making one read after another, as the code below does. Every key on one account reaches the same memory (MCP server page), so on one account a domain sorts what each bot reads, and separating bots takes separate accounts. Domains sort, accounts separate.

Bots run unattended, so they connect with an API key, through the Python SDK or the npm MCP server; the hosted connector signs in through a browser, which suits an agent a person starts. A write that is too similar to the nearest memory in the same domain is not stored, and the result says why, so a bot that writes down a fact the project scope already holds, in words too close to tell apart, gets a refusal instead of a second copy.

Every bot runs the same code under its own name:

import os
from mnemoverse import MnemoClient

BOT = os.environ["BOT_NAME"]                # "reviewer", "test-fixer" or "release"
SHARED = os.environ.get("FLEET_DOMAIN", "project:orders-api")
LAST_RUN = os.environ.get("LAST_RUN_AT")    # when the previous run started (ISO time), kept by CI; unset on the first run

def start_of_run(memory, task):
    own = memory.read(task, domain=f"agent:{BOT}", top_k=5).items
    shared = memory.read(task, domain=SHARED, top_k=5).items
    new, cursor = [], None
    while True:  # everything since the last run, newest first, nothing ranked away
        page = memory.recent(domain=SHARED, since=LAST_RUN, limit=100, cursor=cursor)
        new += page.items
        if not page.next_cursor:
            return own, shared, new
        cursor = page.next_cursor

with MnemoClient() as memory:  # reads MNEMOVERSE_API_KEY
    own, shared, new = start_of_run(memory, "test_refund_webhook fails intermittently")
    # ... the test-fixer's work ...
    result = memory.write(
        "test_refund_webhook fails when it runs after test_retry_queue: both use Redis "
        "database 0. Fixed in PR 807. Seen in CI runs 4411 and 4417.",
        concepts=["flaky-test", "redis", "test_refund_webhook"],
        domain=SHARED,  # a role lesson would go to f"agent:{BOT}"
    )
    if not result.stored:
        print("Not stored:", result.reason)

When the bots run under different accounts

Say the release bot belongs to another team's account. Its key reaches only that account's memory, where project:orders-api holds none of what the other bots wrote. What both accounts can reach is a room (Beta), a memory space shared across accounts and addressed as xroom:<room_id> in the same domain field. Creating a room, minting an invite, joining and listing your rooms are self-service tools in the local MCP server and the hosted connector; Join a shared room has the steps. Once its account has joined, a bot runs the code above with FLEET_DOMAIN set to the room address.

A room is its own bucket. Nothing in project:orders-api moves into it, and joining shares nothing from a member's own memory. The bots write the shared part to the room address.
An invite carries its scope. A read invite fits a bot that should use what the fleet knows and never change it, such as that release bot. A contractor's reviewer that leaves handoffs needs read_write, the default. Invites minted with the tools default to one redemption and a 7-day expiry, so mint one per bot account when it is ready to join.
Membership is checked on every request. A bot account revoked in the console is refused on its next call; what it already read, it keeps.
The room address belongs in the bot's configuration. An unscoped read does not search shared rooms, so a bot that leaves the address out reads only its own account's memory.

Check it with a control

Have the reviewer bot write a handoff to the shared scope that no release query would match well, such as the migration note in the table.
Start the release bot in a fresh process. Its listing should show the handoff. Then run its usual search alone: if the handoff does not come back, you have seen why the listing is there.
Control, with the fleet split across accounts: call the room from an account that was never invited. It should be refused with "Not an active member of this room" (in the SDK, a MnemoAuthError with that message). A bot holding a read invite that tries to write should get "Read-only membership cannot write to this room". If either call succeeds, the boundary is not where you think it is.

The library page goes further: private and shared domains, how memory differs from a coordination protocol such as A2A, and the boundaries between accounts. Which of your bots found something last week that another one is still rediscovering?

Qodo vs CodeRabbit?

Edward Izgorodin — Fri, 16 Oct 2026 10:15:00 +0000

Pick by four things your team knows: how it wants to pay, where its code lives, whether the reviewer must run inside your network, and how many reviews it runs a month. CodeRabbit charges per developer who opens pull requests, $24 a month on Essentials billed annually; Qodo charges $30 a month for a pool of 2,500 credits shared by the team, which Qodo estimates at ~18 reviews. Both list GitHub, GitLab, Bitbucket and Azure DevOps; Qodo adds Gerrit, which its homepage and pricing page put on Enterprise while its docs list it for every deployment model, the multi-tenant cloud included. Both self-host on Enterprise: CodeRabbit from 500 user seats, Qodo with no seat minimum I could find. At Qodo's $1.67 a review ($30 over its own ~18), the two bills meet at about 14 reviews per developer a month against CodeRabbit's $24.

Every fact below comes from each tool's own pages as I read them on 14 October 2026, and neither Qodo nor CodeRabbit saw this text before publication.

Qodo and CodeRabbit side by side

Each cell is from the vendor's own pages, read on 14 October 2026; links are at the end.

	Qodo	CodeRabbit
Code hosts listed	"GitHub (cloud and Enterprise Server), GitLab (cloud and self-managed), Bitbucket (Cloud and Data Center), Azure DevOps. Gerrit on Enterprise." on its homepage, and "Gerrit support" is "Not included" on Pro Team in its pricing table; its docs mark Gerrit for Multi-tenant, Single-tenant, On-prem and Air-gapped, and its changelog says Qodo "now fully supports Gerrit across multi-tenant, single-tenant, and on-premises deployments"	GitHub, GitHub Enterprise Server, GitLab.com and self-managed GitLab, Bitbucket Cloud and Data Center, Azure DevOps; a Reverse Tunnel, set up through CodeRabbit sales or support, for a GitHub Enterprise Server or self-managed GitLab that cannot accept inbound network access
Not found on these pages on 14 October 2026	Gitea, Perforce (homepage, pricing, deployment table, install page, docs index)	Gerrit, Gitea, Perforce (platforms page, docs index)
When it reviews	automatically when a pull request is opened, reopened or marked ready for review; "Review every push" is an option; `/agentic_review` on demand; a "Manual only" setting	automatically when a pull request is opened against the main branch, then an incremental review on each push, paused by default after five reviewed commits; `@coderabbitai review` for new changes, `@coderabbitai full review` for the whole pull request
What you pay for	one credit pool per workspace: Pro Team $30 a month for 2,500 credits, packs of 5,000 credits for $60 and 20,000 for $240, "$.012/credit, pooled across the team"; overage at the same per-credit rate up to a monthly cap you set; credits expire each month; Pro Team is billed monthly	developers who create pull requests: Essentials $24 per developer per month billed annually or $30 monthly, Team $48 or $60; 5 PR reviews per developer per hour on Essentials, 8, 10 and 12 on the higher plans; optional usage-based reviews at $0.25 per reviewed file, with a monthly spending cap
Free entry	a 14-day trial with unlimited reviews and no credit card; "We don't offer a permanent free tier."; qualified open-source projects can apply to the Qodo for Open Source program	a 14-day trial with no credit card, Advanced by default for new organizations; the Free plan gives "PR summarization only; code reviews are available through the VS Code extension and CLI."; open-source projects get Team features without paying
Self-hosting	Enterprise: single-tenant SaaS, on-prem and air-gapped; the Enterprise card reads "For 30+ users"; no seat minimum for on-prem found on its homepage, pricing, install page or docs index	Enterprise "with 500 or more user seats": a container in your infrastructure, with your own model provider; the page names "air-gapped requirements"; its pricing table also lists "company-selected SaaS regions" on Enterprise
Linked repositories	"Cross-repo capabilities" included on Pro Team	multi-repo analysis with 1, 5, 10 and 20 linked repositories on Essentials, Team, Advanced and Enterprise
Merge gates	on GitHub, an author self-review checkbox that "Can be configured to add Qodo as a reviewer, allowing the PR to be merged."; compliance labels such as "Failed compliance check" that your own CI action can block on	pre-merge checks in error mode, which with the Request Changes Workflow "block merges until resolved or manually overridden"; built-in checks on Essentials, custom checks from Team; since 5 October 2026, a CodeRabbit Security check that you can require in GitHub, on Advanced and Enterprise
Training and storage	"Your code is analyzed and discarded. Nothing stored, logged, or used to train models."; bring your own model keys on Enterprise	"CodeRabbit never uses customer code for model training."; code is "shared with OpenAI and/or Anthropic for reviewing purposes only"; a data retention setting decides whether code-related data is kept for learnings
How a finding is filtered	several review agents with shared context, "filtering out low-impact or irrelevant comments before they reach the pull request"; tell it a finding does not apply and Qodo "dismisses the finding as False positive, Rejected, Deferred, or Intentional"	Review, Verification, Chat and Pre-Merge Checks among its parallel agents; "Sandboxed cloud execution with your full repository cloned for isolated analysis"; 50+ static analyzers, linters and SAST tools
Noise and learning	review effort mode (Beta), Auto by default, "which dynamically matches review depth to the risk of each change"; "Rules system (no limit)" on Pro Team, "Self-learning system" on Enterprise	"Quiet, Chill, and Assertive profiles"; Learnings on every paid plan
Before the pull request	IDE plugins for VS Code, JetBrains IDEs and Visual Studio, and a CLI	an IDE extension for "VS Code, Cursor, Windsurf, and any VS Code-based IDE", and a CLI
Security attestation	SOC 2 Type II, on its homepage	SOC 2 Type II, by its changelog

What the bill depends on

The billing unit is what several comparison pages by third parties get wrong. Qodo writes "Billing is usage-based (not seat-based)." and calls a credit "the unit Qodo uses to meter review activity". CodeRabbit charges per developer and says "you will only be charged for developers who create pull requests". CodeRabbit also renamed its plans: "Essentials is the new name for Pro, and Team is the new name for Pro Plus." A page that prices Qodo per person, or CodeRabbit by its old plan names, describes pricing that is not on either vendor's page today.

The two units meet at a number you can compute. Ten developers who open pull requests cost $240 a month on CodeRabbit Essentials billed annually. The same $240 buys Qodo's 20,000-credit pack, which Qodo estimates at ~144 reviews, or 14.4 reviews per developer. That is arithmetic on the vendors' own prices, not a measurement, and it rests on Qodo's average, because "Smaller PRs draw fewer credits, larger or more complex reviews draw more." Below that rate the Qodo pool costs less; above it the CodeRabbit price per developer does. At CodeRabbit's monthly price the crossover moves to 18 reviews per developer: $300 for ten developers buys 25,000 credits at $.012, ~180 reviews by the same estimate.

Three edges move the result. Qodo's smallest pack is $30 for the whole team, so a team of one pays $24 on CodeRabbit's annual Essentials against $30 at Qodo. Qodo's pricing page calls Pro Team "Designed for up to 30 users" and starts its Enterprise card there, while its docs list "Unlimited users per workspace." for the same plan. CodeRabbit's price holds until a developer passes the hourly allowance, 5 PR reviews per hour on Essentials in a rolling window, and sustained activity can space that developer's reviews out further. Past the allowance, reviews wait unless usage-based reviews are on, at $0.25 per reviewed file. They are optional, but CodeRabbit switches them on in Automatic mode the first time a review passes the limit during a trial, free while the trial lasts, and "Your saved continuation choice carries over when you activate a paid subscription." Through all of this, "There is no total limit on the number of pull requests or repositories you can review".

What counts as a review differs as well. CodeRabbit's rate-limit page says it "reviews pushes, not commits": by default each push gets an incremental review, with a pause after five reviewed commits, and each of those reviews draws on the hourly allowance. Qodo reviews when a pull request is opened, reopened or marked ready, and updates its review on every push only if you turn on "Review every push". Qodo states that "Every code review draws credits from your monthly pool.", so check on its dashboard, which shows "real-time balance and burn rate", what a pushed commit draws.

How each one describes noise and checking

Qodo describes several review agents that share context: "Combining multiple review agents with shared context lets Qodo catch what a single-pass review misses, while filtering out low-impact or irrelevant comments before they reach the pull request." Its review effort mode, in beta, starts at Auto and scales the depth of a review to the risk of the change. When someone tells Qodo a finding does not apply, it records one of four dismissal reasons, so the noise that got through can be counted.

CodeRabbit's architecture page lists a Verification agent among its parallel agents, next to "Sandboxed cloud execution with your full repository cloned for isolated analysis", and its homepage says review generation "Uses agentic code generation and exploration, static verification, and analysis to deliver a review." How much it says is set by profiles, from Quiet to Assertive.

Both are descriptions, not measurements. Each vendor also publishes a number with its method, below; neither is a noise rate for your code.

What each publishes as numbers, and how

	Qodo	CodeRabbit
What is compared	Qodo "against 7 other leading AI code review platforms", each on its default settings	Claude models inside CodeRabbit's own review pipeline, Sonnet 5.5 against Sonnet 5
Test set	"100 PRs containing a total of 580 issues", defects injected into merged pull requests from open-source repositories; the benchmark and the reviews it scored are published	13 hardest known-bug cases from open-source pull requests; a second set of 85 known issues across 44 open-source pull requests is reported for comment counts, speed and cost only, because "judge scoring was pending"
Who judges	findings "were rigorously compared against our validated ground truth using an LLM-as-a-judge system"	"an independent judge scored every comment with three votes against the known issue, and only majority-PASS comments count"
When	published 4 February 2026, updated 3 September 2026	published 28 September 2026

Qodo's headline, on that method: Qodo is first in its own table, "achieving an F1 score of 60.1%".

CodeRabbit's headline, on its method: Sonnet 5.5 caught 6 of 13 issues through actionable comments, against 4 for Sonnet 5, at 41.2% actionable precision. The same page marks the limit: "Thirteen cases is a small set, and we say so throughout."

The two headlines answer different questions. Qodo's ranks Qodo against other reviewers on a benchmark that Qodo built and judged; CodeRabbit's compares two models inside CodeRabbit. Neither belongs in one column with the other, and no figure about CodeRabbit from a Qodo table appears here. Qodo also publishes a page titled "Qodo vs CodeRabbit: Full Codebase Enforcement vs. Diff-Level Review (2026)", dated 6 July 2026. I did not find a CodeRabbit page about Qodo in CodeRabbit's sitemap (602 addresses), its llms.txt files or its docs index on 14 October 2026. A comparison written by either vendor is that vendor's case, so each tool here is described from its own pages, not from its rival's.

How to choose for a team

If this is true for your team	Look first at	What the pages say
Your code review runs on Gerrit	Qodo; its own pages differ on the plan	Qodo's homepage says "Gerrit on Enterprise." and its pricing table marks "Gerrit support" "Not included" on Pro Team; its deployment table marks the "Gerrit" row with a check under Multi-tenant, Single-tenant, On-prem and Air-gapped, its install page lists Gerrit under multi-tenant, the column it marks "All plans", its changelog says Qodo "now fully supports Gerrit across multi-tenant, single-tenant, and on-premises deployments", and its Gerrit install guide asks for "A Qodo environment configured for Gerrit", so ask Qodo which plan your Gerrit setup needs. Gerrit not found on CodeRabbit's platforms page or in its docs index; all read on 14 October 2026
Code must stay inside your network, and you would buy fewer than 500 seats	Qodo Enterprise	CodeRabbit self-hosts "with 500 or more user seats"; Qodo lists on-prem and air-gapped on Enterprise, with no seat minimum that I found on its homepage, pricing, install page or docs index on 14 October 2026
You run GitHub Enterprise Server and want the vendor's shared cloud	either; Qodo's own pages differ	CodeRabbit's cloud connects to a GitHub Enterprise Server instance, through a Reverse Tunnel when the instance cannot accept inbound network access; Qodo's install guide covers "Qodo multi-tenant with GitHub Enterprise Server" and calls multi-tenant "Available on all plans", while its deployment table marks the "GitHub Enterprise" row with a cross under Multi-tenant
The bill should follow review volume, under a cap you set	Qodo	one credit pool per workspace, overage at the same per-credit rate up to a monthly cap you set; credits expire at the end of each month
The bill should follow the number of people who open pull requests	CodeRabbit	"you will only be charged for developers who create pull requests"; extra charges past the hourly allowance come only from usage-based reviews, which CodeRabbit switches on during a trial the first time a review passes the limit, and which you can keep or turn off when the trial ends
Each developer opens many pull requests, or agents open them in bursts	model both bills first	the bills meet at 14.4 reviews per developer a month against CodeRabbit's annual price and at 18 against its monthly price, by Qodo's own estimate; past that rate the CodeRabbit price per developer stays flat, while bursts meet its hourly allowance and sustained heavy use gets a developer's reviews spaced out
Written rules must hold a merge	either, by different routes	CodeRabbit: pre-merge checks in error mode with the Request Changes Workflow; Qodo: compliance labels that your CI can block on, or the author self-review checkbox
You want each finding checked before it reaches you	CodeRabbit, Qodo, or Sigma (Mnemoverse, the author's company)	CodeRabbit lists a Verification agent among its parallel agents; Qodo's docs describe filtering out low-impact or irrelevant comments before they reach the pull request; Sigma, in closed beta on GitHub by invitation, "checks potential issues and brings the evidence back to your code", and its docs say a fresh verifier "confirms, rejects or reclassifies" each candidate, that "only confirmed candidates are verified findings" and that suspicions no verifier confirmed stay labeled separately; Sigma runs on Claude Code and OpenAI models and reviews its team's own repositories every day; its homepage takes requests through a "Request beta access" form and says "A request does not grant access automatically."

Other tools also review pull requests: GitHub Copilot code review, the open-source PR-Agent, which its README calls "a community-maintained legacy project of Qodo", and Sigma.

A two-week test that settles it

Both vendors let you try before paying. CodeRabbit's docs say "New organizations start with a 14-day Advanced trial.", and at Qodo "Every workspace begins with a 14-day free trial starting at signup." Install both on one busy repository and let them review the same pull requests. If a busy repository passes CodeRabbit's hourly allowance during the trial, those extra reviews are free, and the usage-based setting they switch on is worth checking before the trial ends. CodeRabbit's default trial "includes Advanced features", so compare it against the price of the plan you would buy.

Before you start, take five merged bug-fix pull requests and open the commits that introduced those bugs as new pull requests. Qodo's own benchmark also starts from known defects in real pull requests, "intentionally injecting defects into genuine, merged pull requests", and the method works on your code as well as on theirs. If you have access to a third reviewer, such as GitHub Copilot code review or Sigma, give it the same pull requests.

Mark every comment as a real bug, a wrong claim or noise, and note how long each took to confirm. At the end, Qodo says it will "suggest a credit pack based on the review volume your team generated during the trial"; put that price next to CodeRabbit's price for the developers who opened pull requests in the same two weeks. You then have four numbers of your own: known bugs caught out of five, wrong claims per pull request, minutes per comment and the cost of a month. They answer Qodo vs CodeRabbit for your code, which no vendor's chart can do.

Sources, all read on 14 October 2026. Qodo: homepage, pricing, pricing and usage, triggering a review, review effort, how review works, pull request commands, custom compliance, deployment models, install, GitHub Enterprise Server install, Gerrit install, changelog, docs index, benchmark write-up, Qodo vs CodeRabbit. CodeRabbit: homepage, pricing, plans, rate limits, usage-based reviews, platforms, GitHub Enterprise Server, Reverse Tunnel, self-hosted, FAQ, architecture, IDE and CLI, multi-repo analysis, pre-merge checks, changelog, docs index, Sonnet 5.5 write-up, sitemap. Other reviewers: GitHub Copilot code review, PR-Agent, Sigma homepage, docs and reading a review.

My custom AI bot keeps giving bad advice because it cannot retain feedback from past calls

Edward Izgorodin — Thu, 15 Oct 2026 17:15:00 +0000

Your support bot tells a customer that a sync error goes away if they clear the app cache. It does not. The customer writes back, a person on the team finds the real fix, re-authorising the integration, and the ticket closes. Next Tuesday another customer reports the same error, and the bot recommends clearing the cache again, with the same confidence.

The short answer: each call ends before anyone knows whether its advice worked, so the feedback arrives with nothing to attach to. Keep a record of every call with the ids of the stored notes the answer was built on. When the verdict comes in, from the user, the ticket or the person who took over, send it back as a rating on those notes, and have the bot recall from a memory that reads ratings when it ranks. Next time, the advice that failed and the advice that worked are no longer equals. Nothing is erased: the failed advice stays on record, with its outcome attached.

Why the bot does not learn from its own calls

A typical custom bot is a model call wrapped in retrieval: a system prompt, a search over help articles or stored notes, and the question. The verdict on last week's answer is in none of those. It is in the customer's reply and the helpdesk.

Teams usually try three fixes, in this order.

Edit the system prompt. Add "do not suggest clearing the cache for sync errors". A prompt is the right home for policy, but it scales like any document edited by hand: every bad call adds a line, nobody prunes them, and important rules compete with stale ones for the model's attention.

Store answers and corrections in a memory. The correction now survives the call, but so does the cache advice, and similarity search ranks by closeness to the question. Both notes match, both come back, and the model picks one in context. A wrong note is as similar to the question after ten failures as after none.

Attach the outcome to the note. When a call's result is known, record it on the notes that shaped the answer. The failed note now carries its failure and the working one its success, and a recall that weighs outcomes can tell them apart. Only this fix has a path from what happened back to what gets recalled next.

What to keep from each call

The answer is written during the call. The verdict arrives after it, sometimes days later, in another process. So the call must leave something for the verdict to find:

Call record: what a bot keeps from each call so that a verdict arriving later can find what to judge: the question, the answer, and the ids of the stored notes the answer was built on, under a key the verdict will carry.

The ids are per note, not per conversation. One piece of advice failed, not the exchange. If the model can say which recalled notes it relied on, keep those; otherwise keep every note that was in the prompt and accept that they move together.

The key is one the verdict will carry: a ticket id, a thread id, the session id your feedback button already sends. When one key covers several answers, the code below keeps the latest.

Keep call records in your own database, apart from the notes the bot recalls. Written into the same memory, every logged answer becomes one more candidate in the next recall, the bad ones included.

Where the verdict comes from

Explicit ratings are rare. Other outcomes are often already recorded somewhere, and wiring those places in works better than waiting for a thumbs-down.

signal	when it arrives	what it says about the advice	what to send
thumbs up or down on the answer	seconds later, if at all	how the answer looked, often before it was tried	positive or negative
the user says it did not work	the next message, or the next day	it was tried and it failed	negative
a person takes over and solves it another way	when the handover closes	it failed, and here is what worked	negative, plus the fix as a new note
the same user returns with the same problem	hours or days later	the first answer did not hold	negative, smaller
the ticket closes and stays closed	after a quiet period you choose	it probably worked	positive, smaller
nothing happens	never	nothing	nothing

Two rows need care. A handover for a reason the bot was never meant to handle, a refund or an angry customer, says nothing about the advice. And silence, the commonest row, is not a verdict.

The third row does the most work. A rating can lower the advice that failed, but only a note can supply the advice that worked, so the person's fix goes into the memory the bot recalls from.

What a rating changes, and what it does not

A rating cannot change the answer already given. It changes the order of what the next recall brings back.

Keep the failed note rather than deleting it. Clearing the cache is right for a different error, and a deleted note cannot answer "why did the bot tell customers to clear the cache in October?".

Ratings tune ranking, not truth. If a help article is wrong, fix the article. The loop needs no particular product: a list of failed advice the bot checks approximates it, a store you run can carry an outcome field, a managed memory layer keeps the bookkeeping. What matters is the path from outcome back to recall.

A minimal version in code

This uses mnemoverse 0.4.0, the Python SDK of Mnemoverse (the author's company), set up as on the Python SDK page. The model call is a placeholder, and call records live in SQLite.

import json
import sqlite3

from mnemoverse import MnemoClient

memory = MnemoClient()  # reads MNEMOVERSE_API_KEY
DOMAIN = "bot:support"
db = sqlite3.connect("calls.db")
db.execute("CREATE TABLE IF NOT EXISTS calls "
           "(call_id TEXT PRIMARY KEY, question TEXT, answer TEXT, used TEXT, concepts TEXT)")


def answer(call_id: str, question: str) -> str:
    recalled = memory.read(question, domain=DOMAIN, top_k=5)
    reply, relied_on = bot.reply(question, recalled.items)  # your model call
    used = [str(item.atom_id) for item in relied_on]
    db.execute("INSERT OR REPLACE INTO calls VALUES (?, ?, ?, ?, ?)",  # latest answer per key
               (call_id, question, reply, json.dumps(used), json.dumps(recalled.query_concepts)))
    db.commit()
    return reply


def on_verdict(call_id: str, outcome: float, fix: str | None = None) -> None:
    row = db.execute("SELECT question, used, concepts FROM calls WHERE call_id = ?",
                     (call_id,)).fetchone()
    if row is None:
        return  # no call record: the verdict has nowhere to land
    question, used, concepts = row[0], json.loads(row[1]), json.loads(row[2])
    if used:
        result = memory.feedback(atom_ids=used, outcome=outcome,  # -1.0 to +1.0
                                 query_concepts=concepts, domain=DOMAIN)
        print("updated:", result.updated_count)
    if fix:  # what actually worked, from the person who solved it
        note = memory.write(f"Problem: {question}\nWhat worked: {fix}", domain=DOMAIN)
        if not note.stored:
            print("Not stored:", note.reason)


on_verdict("ticket-1042", -1.0, fix="Re-authorise the integration under Settings, Connections.")
on_verdict("ticket-1043", 1.0)  # the customer confirmed it worked

feedback gets the same domain as the read; the SDK page notes that without it the SDK sends "general". A write that is too similar to the nearest memory in the same domain is not stored, so the code checks stored.

The API docs state the effect in one line: "Ratings re-rank what comes back next." The overview says what stays: "feedback changes the order of the next read, not the stored text". A bot on an MCP client rates through the memory_feedback tool instead.

Check it with a control

Seed notes about two different problems, answer one question about each through answer(), and check that the two call records share no id. Print the valence of the notes each call relied on, "Outcome polarity [-1, +1]" in the API reference, and stop the process.
In a new process, send a negative verdict for the first call only. updated_count, "Number of atoms updated" in the reference, should equal the number of ids recorded for that call. If it is zero, check the ids and the domain first.
Read both questions again and print valence for the same notes. What to look for is the first call's notes moving toward -1 since step 1.
Control: the second call got no verdict, so its notes are the comparison for step 3. If they moved and the first call's did not, look at the key the verdict was filed under. If both moved alike, step 3 does not show the verdict's effect.

The library page follows the same loop for coding agents, where the verdict is a build or a test run, with the limits of outcome memory in more detail. Where does the verdict on your bot's answers end up today?

AI assistant keeps giving outdated answers after codebase refactoring, how to update its learned knowledge?

Edward Izgorodin — Wed, 14 Oct 2026 13:56:00 +0000

TL;DR

A refactor changes the code; the assistant's notes about that code stay as they were. Whether it notices depends on two things: does a note point at the code it is about, and is that pointer checked before the note is used?

GitHub Copilot Memory documents both: facts cite code, and the citations are checked against the current branch before use. Claude Code dates its notes and tells the model to verify older ones against current code when it uses them. Cursor advises rules that reference files instead of copying them.

Devin and Cline tie memory to the session it came from or to markdown files that you or the agent keep current. Memory layers (Zep, Mem0, Supermemory, Cognee) trace a fact to a conversation or document, not to code.

After a refactor: keep out of memory what the code already says, point the rest at files and date it, run the checks that exist, replace a stale note instead of appending a correction, and send changed documents through an update path.

A renamed function is easy to find in the repository. It can be much harder to get out of an assistant's memory.

GitHub's engineering post on Copilot's memory says the core challenge is not retrieval but "ensuring that any stored knowledge remains valid as code evolves across branches and time" (GitHub blog, 2026-01-15). Persistence is not the problem. Persistence with no connection to current code is.

A stale note is a stored claim that describes an earlier state of the code and was not revised or invalidated when that state changed.

Code-anchored memory is a stored claim tied to code locations (files, symbols, tests) that can be checked against the current repository before the claim is used.

This is a reading of each vendor's published documentation and shipped files, first read on 2026-10-06 and re-read on 2026-10-10. It is not a hands-on test of the products. Where a page does not describe a behaviour, this article says so rather than claiming the product cannot do it.

Why a refactor leaves the assistant on the old code

A saved note and a repository file have separate lifecycles unless something connects them.

Say an assistant noted that authentication goes through validateSession(). A refactor replaces that function. The repository now holds the new name, but the old note can still be retrieved, because nothing ties it to the changed file and nothing checks it before use. Anthropic describes the same failure for an index of the code: it "returns a function the team renamed two weeks ago, or references a module that was deleted in the last sprint, with no indication that either is out of date" (Anthropic, 2026-05-14).

So two questions matter more than whether a product "has memory":

What does the note point to? Current code, a file, the session it was learned in, a conversation, or a document.
What checks or updates it? A check when it is used, a code change, a scheduled cleanup, a command you run, or nothing that is described.

Copilot Memory, Claude Code, Cursor, Devin and Cline compared

Read from each vendor's documentation and shipped files on 2026-10-10.

Assistant	What a note points to	What signals or checks a stale note	Remember or re-read
GitHub Copilot Memory	Facts with citations to the code that supports them	Citations checked against the current branch before use; unused entries deleted after 28 days	Remembers, then re-reads the cited code
Claude Code	One auto memory directory per git repository, on one machine	Last-modified time on notes; from two full days old, an age note and an instruction to verify against current code	Skips what it can derive from the codebase
Cursor	Version-controlled `.mdc` rules that can reference files	You edit a rule, or Agent does when you tag `@cursor` on a GitHub issue or PR	Rules point at files; search index stays on your machine
Devin	The session where the entry was learned, with the date it was added	Session Insights flags Knowledge items (now moving to Skills) written for a previous version of the codebase	Does not save what is cheap to rediscover
Cline	Markdown Memory Bank files in your project	Update occasions named in the recommended instructions, one of them your `update memory bank`	Reads the Memory Bank after each reset, per the recommended instructions

GitHub Copilot Memory checks cited code against the current branch

In the Copilot Memory docs, Copilot "checks those citations against the current branch to confirm the information is still accurate. Only validated facts are used." The engineering post says how: "the agent is prompted to verify its accuracy and relevance by checking the cited code locations." So the check is an instruction to the agent when it reads a fact, not a rewrite on every commit. When the code disagrees, the agent "is encouraged to store a corrected version of the memory".

The docs add three details that matter after a refactor. A fact captured from a pull request closed without merging has no effect unless the current codebase still supports it. Unused facts are deleted after 28 days, and "The 28-day timer may reset whenever Copilot successfully validates and uses an entry." Repository owners can review and delete repository-level facts by hand. Memory serves the Copilot cloud agent, code review, the CLI and agentic autofix, and, since 2026-08-11, agent chat in JetBrains (GitHub changelog). It "is currently in public preview and is subject to change."

Claude Code auto memory dates notes and warns when they are used

The memory page: "Auto memory is machine-local." All worktrees and subdirectories of one git repository share one directory on that machine, and the files "stay until you or Claude edits or deletes them." Notes have carried timestamps since 2.1.75 (2026-03-13) and an ISO modified write time in their frontmatter since 2.1.214 (2026-07-18) (changelog). The /memory command gives "access to the auto memory folder and the auto memory toggle" (debug your config), so you can read and edit the notes yourself.

The program shipped as Claude Code 2.1.291 adds an age note to any memory two full days old or older, followed by "Verify against current code before asserting as fact." That acts when a note is used, not when the code changes. A link from a note to a file or commit, and a re-check triggered by a code change, are not described on the Claude Code documentation read on 2026-10-10.

Claude Code's first defence is upstream: auto memory skips "anything it can derive from the codebase". Function names, paths and signatures are cheaper to re-read than to keep as prose. For instruction files, /doctor prompt-audit (since 2.1.283, 2026-09-25) reports references to missing files or commands and contradicting files, and changes nothing until you ask. Its default list covers CLAUDE.md, CLAUDE.local.md, AGENTS.md and the rules, skills, commands, subagents and output styles under .claude/ and ~/.claude/. It does not list the auto memory directory, though you can pass a path. The best practices put it in one line: "Treat CLAUDE.md like code".

Cursor rules should reference files, not copy them

Cursor's rules page says it directly: "Reference files instead of copying their contents. This keeps rules short and prevents them from becoming stale as code changes." Rules are .mdc files in .cursor/rules, under version control. You edit them, or Agent does when you tag @cursor on a GitHub issue or PR.

The difference is concrete. A rule that says "follow the interface in src/auth/session.ts" sends the assistant to the current file. A rule that pastes the old interface becomes a second specification, and after the refactor it is the wrong one. Cursor's search builds its index on your machine and "does not store embeddings of your codebase for search"; that is a statement about search, not about rules.

Devin memory links each entry to the session it came from

In Devin's Memory, each entry "links back to the session where it was learned" and is dated when added. That records origin; it points at a past session, not at current code. Session Insights gives as one reason knowledge misled Devin: "Knowledge was written for a previous version of your codebase", listed under Misleading Knowledge so you can update or remove it. Dreaming "reviews your recent sessions alongside your existing memory" and removes "stale notes that no session has used". A check of a note against changed code is not described on the Devin Memory page read on 2026-10-10. The older Knowledge feature "is deprecated"; Devin's release notes date its move into Skills to 2026-09-18.

The Agent Memory Repo specification that this memory is built on recommends a source key, "a link to the agent session where the information was learned", and an added date. A key tying an entry to a code file is not described in the specification, though "Keys are open."

Cline Memory Bank is documentation you keep current

Cline calls its Memory Bank "a documentation methodology". The recommended custom instructions on that page name four occasions to update it, among them "After implementing significant changes" and your own update memory bank. The same instructions say: "After each reset, I rely ENTIRELY on my Memory Bank". These are recommended instructions, not built-in behaviour, and they make a stale Memory Bank expensive. Separately, the extension's source tracks outside edits to files read in the current task "to prevent stale context"; that covers the current task, not the Memory Bank.

Memory layers trace a fact to a conversation or document, not to code

If your agent's memory sits in a separate memory layer, the anchor is the episode, conversation or document the fact came from. Zep ties facts to episodes and says plainly that this "records where information came from. It does not establish that the source content or a derived fact is true." Mem0 keeps in a memory's history "The conversation input that led to this memory change". Supermemory's MCP returns "source document IDs", and its GitHub connector syncs pushed documentation "within approximately 10 minutes", removes deleted files, and excludes code files by default.

What matters after a refactor is what each layer does with a changed document:

Cognee: "add() creates documents; it never updates one." (add). Its update() replaces what was derived from the old content and by default re-ingests "only the chunks the edit touched"; when it rebuilds a document instead, entities that other documents in the same dataset also reference are kept.
Supermemory: "Content changes trigger full reprocessing" (document operations), and "facts supported only by the previous source can disappear after reprocessing" (v5 document updates).
Zep: "Reingesting the same file creates new episodes, even when its contents are unchanged" (ingestion); each extracted fact is then compared with existing ones, and "duplicates merge, and contradictions invalidate older facts rather than leaving conflicting truths side by side." (graph creation).

The lesson is the same in all three: a changed document goes through the update path. Adding it again can leave both versions in memory.

Remember or re-read: what the October 2026 preprints measured

Remembering saves rediscovering. Re-reading avoids trusting yesterday's summary. Anthropic's post explains why Claude Code searches the live code without an index, and names the price: "it works best when Claude has enough starting context to know where to look." Copilot keeps memory and re-reads the cited code.

Three arXiv preprints from October 2026 study this trade-off. None studies refactoring, none is peer-reviewed, and every number below is the authors' own measurement on their own setup.

arXiv 2610.03902 (Wenhui Chu, v1, 2026-10-02) asks, when supporting documents are revoked or replaced, "should it repair memory or re-read current evidence?" On ICU medical records with two 7B models, local repair used 5 to 10 times fewer revision tokens than rebuilding on short records, yet every memory pipeline cost at least twice full re-reading in held-out conditions; in a small development sweep that padded records to about 10,000 tokens with documents the task does not use, memory became cheaper than full re-reading after 2 to 14 uses, "while source-filtered re-reading remained cheapest." The author's own limit: "none of the four primary confirmatory tests reached statistical significance." No code or data are published yet. Its example fits code too: "The raw record is marked revoked; the extracted claim and the summary are not".
MemTrace, arXiv 2610.04838 (Hongming Xu and others; v1 2026-10-04, v2 2026-10-08 with the same results) anchors a coding agent's records to "files, symbols, tests" and checks them "against the current repository state"; with nothing applicable, "the agent reads the current file or symbol, or reruns the required test." The authors: "Persistence alone, however, does not establish current validity". In 84 archived coding-task runs, 57.0% of 9,226 eligible file-bound records met a later change to at least one bound file, which is exposure, not error: "Exposure measures file changes; Trace Validation assesses whether historical evidence remains applicable." The performance runs used one model; sessions are left to future work; no refactoring. The code is published.
StateWise, arXiv 2610.05241 (Yongyuan Peng and others, v1, 2026-10-04) planted one wrong operational record in an agent's persistent memory in each of 150 cases. Even with an explicit reminder to refresh, "refresh remains selective and recovery is limited". Removing the wrong record "reduces harm but leaves the agent without information needed to complete the task." The records were about environment and repository policy, not code after a refactor, and developer responses were simulated.

Together they support a design question, not a product ranking: which notes are worth repairing, and which should be read again from the source.

Replace the stale note, do not append a correction

A correction added beside the old note leaves two notes that disagree, and the old one can still win retrieval. An illustration of the pattern to avoid:

- Session tokens are validated by `validateSession()` in src/auth/session.ts.
- UPDATE 2026-10-10: `validateSession()` was removed; use `verifyToken()`.

Several systems tell the agent to fix the note in place instead. Letta's reflection prompt: "fix the stale entry at the source. Do not append the new version alongside the old." The Agent Memory Repo skill: "Update or remove entries that are out of date instead of adding a contradicting entry." Kevin Liao's essay (version of 2026-10-05): "Facts should be rewritten when truth changes. No appending." Whether a model actually does this varies: Letta's evaluation of 2026-07-28 found that "weaker models make minimal edits that leave stale and contradictory information behind." What a store does with an older record that a newer one contradicts is compared in Agent memory consolidation compared.

A rating moves a note down, it does not say why

Several products take a rating on a memory or an answer, and none of them turns a thumbs-down into the corrected fact. Cognee can fold answer ratings into graph search; self-hosted, by default "the learned feedback signal does not change ranking until you opt in" (feedback system). Its demonstration rates one topic up and another down, because "a symmetric signal would raise both topics equally and leave their relative order untouched", and the same page points disagreeing facts to a separate conflict review, where they are settled "by each source's date, not by a rating." Mem0 takes POSITIVE, NEGATIVE and VERY_NEGATIVE ratings and says "This feedback is used to improve the accuracy of the memories and search results." (feedback); how NEGATIVE lowers a memory is not described on that page. Supermemory down-weights facts its engine inferred "until someone confirms them": once approved, such a fact "Ranks like a stated fact"; once declined, it is "Removed from search entirely" (memory review). In Mnemoverse (the author's company), "Ratings re-rank what comes back next." (agent memory).

A rating can push a stale note down without saying that it is stale or what replaced it. After a refactor, fix the note.

What to do after a refactor

Keep out of memory what the code already says. Function names, paths, signatures and behaviour are for the agent to read from the code; Claude Code skips what it can derive from the codebase, Devin skips what is cheap to rediscover. A prompt such as "Read src/auth/session.ts and confirm the current exports before writing the tests" does more than any remembered summary of that file.
Point what you keep at files, and date it. Cursor's rules advice and Copilot's citations both point at code; Claude Code records write times; the Agent Memory Repo recommends source and added keys. A session link tells you where a note came from, a file reference gives the agent something current to check.
Run the checks that exist. Copilot validates cited facts on its own; repository owners can delete stale ones. In Claude Code, open /memory and read the notes about the code you moved, and run /doctor prompt-audit on your instruction files. In Cursor, update the affected rules. In Devin, review the Misleading Knowledge list in Session Insights (it covers Knowledge items, now moving to Skills). In Cline, run update memory bank.
Replace a stale note instead of adding one beside it (Letta, the Agent Memory Repo). Copilot's agent is encouraged to store a corrected version; GitHub's pages do not say the old fact is removed, and repository owners can delete it by hand.
Send a changed document down the update path, not the add path: Cognee's update(), not add(); in Supermemory, "update the canonical document when facts change" (v5 memory forgetting).

Rules files age with the code too: a rules file is text in a context window. Forgetting over time is a separate question, as are outdated library patterns after a correction.

Common questions

AI assistant keeps giving outdated answers after codebase refactoring, how to update its learned knowledge?

Remove from memory what the code already says, point what you keep at files and date it, run the checks your assistant documents, replace a stale note instead of appending a correction beside it, and send changed documents through an update path. Whether the assistant notices a refactor on its own depends on whether its notes point at code and whether that pointer is checked before use; as of 2026-10-10, GitHub Copilot Memory documents both.

Why does my AI coding assistant still suggest a function I renamed?

Something it reads was written before the rename. If that note points only to an earlier session, conversation or document, nothing in the rename touches it. GitHub Copilot Memory checks a fact's code citations against the current branch before use; Claude Code tells the model to verify notes two full days old or older against current code. Otherwise, rewrite or delete the note, or let the agent read the code again.

Does Claude Code update its memory after a refactor?

Its memory files "stay until you or Claude edits or deletes them." (memory page). The Claude Code documentation read on 2026-10-10 does not describe a re-check of a note when code changes. The program shipped as Claude Code 2.1.291 dates notes and, when a note two full days old or older is used, tells the model to verify it against current code.

How does GitHub Copilot Memory keep facts from going stale?

Facts carry citations to code, and before a fact is used the agent is prompted to check those citations against the current branch; in GitHub's docs, "Only validated facts are used." Unused entries are deleted after 28 days, and the timer may reset on validated use. Repository owners can also delete facts by hand. The feature is in public preview.

Can a thumbs-down rating fix an outdated memory?

No. A rating can move a note down in retrieval where a product documents that, but it does not say why the note is wrong or what replaced it. Cognee's docs say disagreeing facts are settled "by each source's date, not by a rating." Correct or remove the note itself.

Sources and method. Each vendor's pages were first read on 2026-10-06; every quotation on this page was read again on 2026-10-10 (the two Cognee feedback pages on 2026-10-13) and is contiguous text of the source linked beside it (for arXiv papers, the full text behind the abstract page; for Claude Code's shipped instructions, the npm package named below), with the vendor's punctuation. Where a vendor describes an instruction to the model rather than a mechanism, this page says so. Claude Code: memory, best practices, changelog, debug your config, and the shipped program in the npm package @anthropic-ai/claude-code-linux-x64 2.1.291, searched byte by byte; Anthropic, How Claude Code works in large codebases (2026-05-14). GitHub: Copilot Memory, Building an agentic memory system for GitHub Copilot (2026-01-15), JetBrains changelog (2026-08-11). Cursor: rules, search. Devin: memory, Session Insights, Knowledge, release notes. Agent Memory Repo: SPEC.md, SKILL.md. Cline: Memory Bank, FileContextTracker.ts. Letta: reflection.md, Evaluating memory in production agents (2026-07-28). Mem0: memory history, feedback. Zep: source traceability, preparing data for ingestion, how graph creation works. Cognee: update, add, feedback system, feedback demonstration. Supermemory: document operations, GitHub connector, MCP, memory review, v5 document updates, v5 memory forgetting. Research: arXiv 2610.03902 (v1), arXiv 2610.04838 (v1 and v2), arXiv 2610.05241 (v1). Discussion: Kevin Liao's essay (version of 2026-10-05). Mnemoverse: agent memory. No score or performance number for any product appears on this page.

Edward Izgorodin · Mnemoverse · 2026-10-10

CodeRabbit vs Claude Code?

Edward Izgorodin — Tue, 13 Oct 2026 13:55:59 +0000

Claude Code is not one reviewer but several products: Anthropic's managed Code Review, the Claude Code GitHub Action you run in your own workflows, and the /code-review command in your terminal, with an ultra mode that runs in the cloud. Code Review is a research preview for Team and Enterprise plans on GitHub, billed per review from usage credits, $15 to $25 on average by Anthropic's docs. CodeRabbit bills per developer who creates pull requests, from $24 per developer per month billed annually, and lists GitHub, GitLab, Azure DevOps and Bitbucket. CodeRabbit also runs inside Claude Code as a plugin, so the answer is often both; choose by code host, billing unit, where the review runs, and whether the reviewer sits outside the session that wrote the code.

Every fact below comes from each vendor's own pages as I read them on 11 October 2026, and neither Anthropic nor CodeRabbit saw this text before publication.

The four options side by side

In Anthropic's words, "Several products share the Claude Code name." Each cell is from the vendor's own pages, read on 11 October 2026; links are at the end.

	CodeRabbit	Claude Code Review (managed)	Claude Code GitHub Action	`/code-review` in your terminal
Status	paid plans Essentials, Team, Advanced, Enterprise, plus Free	"research preview"	"open source and available", per Anthropic	a Claude Code command, also run as `/review`; its `ultra` mode is a research preview
Code hosts	GitHub, GitLab, Azure DevOps, Bitbucket Cloud and Data Center, GitHub Enterprise Server, self-managed GitLab	GitHub; GitHub Enterprise Server on Team and Enterprise, if Anthropic's infrastructure can reach it	GitHub; for GitLab, a separate integration "currently in beta" and "maintained by GitLab"	any local diff; `--comment` posts to a GitHub pull request or a GitLab merge request
When it reviews	when a pull request opens against the main branch, then as you push, skipping draft pull requests unless configured to include them; `@coderabbitai review` (incremental) or `@coderabbitai full review`	per repository: Once after PR creation, After every push, or Manual; `@claude review` for one review, `@claude review always` to follow later pushes; "20 minutes on average"	on your workflow's events; the review workflow skips draft, closed and trivial pull requests and those Claude already commented on	when started: your branch and uncommitted changes, or a PR, a branch or a ref range
What you pay for	developers who create pull requests: Essentials $24 per developer per month billed annually or $30 monthly, Team $48 or $60	each review, averaging $15-25 per review from usage credits outside the plan; After every push multiplies that by the number of pushes	GitHub Actions minutes, plus Claude API tokens or, with an OAuth token, your Claude subscription	normal Claude Code usage; `ultra` has 3 free runs on Pro and Max, once per account, then typically $5 to $25 per review
Plan you need	Free gives PR summaries, with reviews in the VS Code extension and CLI; open-source projects get Team features without paying	Team or Enterprise, not Pro or Max; not for organizations with Zero Data Retention or the HIPAA configuration	a Claude API key, or an OAuth token on Pro, Max, Team or Enterprise	plans without Code Review too: "On other plans, you can still review a diff locally"
Where it runs	"Sandboxed cloud execution with your full repository cloned for isolated analysis"; self-hosted on Enterprise from 500 user seats	"on Anthropic infrastructure"	GitHub-hosted runners, calling the Claude API, Amazon Bedrock, Google Cloud's Agent Platform or Microsoft Foundry	your machine, as a background subagent with its own context window; `ultra` in a cloud sandbox
How a finding is checked	a Verification agent among "Specialized AI agents working in parallel"	"a verification step checks candidates against actual code behavior to filter out false positives"	set by your workflow; the review workflow runs Anthropic's `code-review` plugin	at low effort it reports the findings it is most confident in; with `ultra`, "every reported finding is independently reproduced and verified"
What lands on the pull request	comments that update as you push; `@coderabbitai approve` resolves its threads and attempts to approve, for teams that require it as a reviewer	inline comments by severity and a check run that "always completes with a neutral conclusion"	an inline comment on each issue, or one summary comment when it finds none	nothing unless you pass `--comment`; `--fix` applies the findings to your working tree
Training on your code	"CodeRabbit never uses customer code for model training."	no, under commercial terms (Team, Enterprise, API), unless the customer opts in	by account: commercial terms for an API key; Anthropic trains on data from Free, Pro and Max accounts when the setting is on	the same rule, by account

Why not just ask Claude Code to review the pull request?

You can, and Anthropic documents how. The /code-review command reviews a diff "without installing the GitHub App", follows your CLAUDE.md "like any Claude Code session", and "runs as a background subagent with its own context window"; --comment posts the findings to the pull request. It runs when started, so a later push gets a review only when it is run again.

The services differ in what happens after the first review. CodeRabbit "reviews new pull requests automatically and updates its feedback as you push new commits", and Code Review in After every push mode keeps "catching new issues as the PR evolves and auto-resolving threads when you fix flagged issues". That record on the pull request, repeated on every push, is what a one-off prompt does not keep for you. Whether a reviewer that shares the author's model misses more bugs is a fair question that none of the pages I read measures; the test at the end of this article is the closest a team can get on its own code.

What each one costs, in its own unit

A CodeRabbit seat includes reviews up to an hourly limit: "Essentials includes 5 PR reviews per hour" on a rolling window, and sustained use lowers the refill rate, down to "1 review/hour, one review at a time" after 60 or more reviews in 7 days. Past the limit, reviews wait unless usage-based reviews are on, at $0.25 per reviewed file. One detail to check before a trial ends: at the first eligible overage, CodeRabbit turns usage-based reviews on in Automatic mode unless an admin already chose Off or On demand; trial overages are free, and the choice carries over into a paid subscription unless someone turns it off.

Anthropic's managed Code Review bills per review: "Each review averages $15-25 in cost, scaling with PR size, codebase complexity, and how many issues require verification." It is "billed separately through usage credits and does not count against your plan's included usage", and in Manual mode "cost accrues only from reviews someone requests".

One recipe, not a measurement: Anthropic's average for one managed review ($15 to $25, its Code Review page) is in the same range as one month of one CodeRabbit Essentials seat billed annually ($24, its pricing page), and that seat covers its developer's pull request reviews up to the hourly limit. Which bill comes out lower depends on how many pull requests each developer opens and how often they push, so run both with your own counts.

Running both

CodeRabbit documents a plugin for Claude Code: /plugin install coderabbit, then /coderabbit:coderabbit-review reviews your local changes through the CodeRabbit CLI. Both tools read the same instruction file: CodeRabbit "automatically detects coding guideline files such as .cursorrules, CLAUDE.md, and AGENTS.md in your repository and applies them as review criteria", and Anthropic's Code Review "reads two files from your repository to guide what it flags", CLAUDE.md and REVIEW.md.

The vendors are linked on billing too. CodeRabbit joined the Claude Marketplace on 27 May 2026, and "Anthropic customers can apply their existing Anthropic spend commitment toward CodeRabbit". Anthropic's marketplace page says "Claude powers CodeRabbit's context engine and review harness", and CodeRabbit's FAQ says your code is shared with "OpenAI and/or Anthropic for reviewing purposes only". A team can keep /code-review or the plugin for the moment before a push and one service on the pull request.

How to choose

If this is true for your team	Look first at	What the pages say
Repositories live on GitLab, Azure DevOps or Bitbucket	CodeRabbit	CodeRabbit lists all three; Code Review lists GitHub and GitHub Enterprise Server, and for GitLab Anthropic documents a CI/CD integration in beta that GitLab maintains, and `/code-review --comment`; Bitbucket and Azure DevOps were not found in Anthropic's Claude Code docs index or on its Code Review page as of 11 October 2026
The review should run in your own workflows or on your own servers	the Claude Code GitHub Action, or CodeRabbit self-hosted	the Action runs inside your repository's workflows; CodeRabbit self-hosts for Enterprise customers "with 500 or more user seats"
The bill should follow headcount, or only the reviews someone asks for	CodeRabbit for headcount; Code Review in Manual mode or `/code-review` for requests	CodeRabbit bills developers who create pull requests; Manual mode bills requested reviews; `/code-review` counts toward normal usage
Your organization runs Zero Data Retention or the HIPAA configuration	CodeRabbit, the GitHub Action or `/code-review`, after your policy owner reads each data page	Code Review and ultrareview are not available to those organizations
A tool must be able to approve, as a required reviewer	CodeRabbit	`@coderabbitai approve`, which submits an approval only when the `reviews.request_changes_workflow` setting is enabled; Code Review's check run stays neutral, so a merge gate is a script in your CI that reads it
You want each candidate finding checked before it reaches the pull request	CodeRabbit, Code Review, ultrareview, or Sigma (Mnemoverse, the author's company)	CodeRabbit lists a Verification agent; Code Review describes "a verification step"; ultrareview says "every reported finding is independently reproduced and verified"; Sigma, in closed beta on GitHub by invitation, "checks potential issues and brings the evidence back to your code", and its docs say a fresh verifier "confirms, rejects or reclassifies each one", that "only confirmed candidates are verified findings" and that suspicions no verifier confirmed stay labeled separately; Sigma runs on Claude Code and OpenAI models and reviews its team's own repositories every day; its homepage takes requests through a "Request beta access" form and says "A request does not grant access automatically."

If Greptile is also on your list, CodeRabbit vs Greptile? compares those two in the same way.

What each vendor publishes as numbers

Anthropic's launch article of 9 March 2026 reports its own use: "We run Code Review on nearly every PR at Anthropic." On those pull requests, "Before, 16% of PRs got substantive review comments. Now 54% do.", and "Engineers largely agree with what it surfaces: less than 1% of findings are marked incorrect." The set is Anthropic's own pull requests, and its own engineers did the marking.

CodeRabbit's write-up of 28 September 2026 compares Claude models inside CodeRabbit's own pipeline, not CodeRabbit against other tools. On its 13 hardest known-bug cases, Sonnet 5.5 caught 6 of 13 issues through actionable comments, at 41.2% actionable precision, where "Actionable precision is passing actionable comments divided by all actionable comments." The post adds "Thirteen cases is a small set, and we say so throughout."

The two numbers answer different questions on different sets, so they do not belong in one column. How to read vendor benchmarks in general is the subject of "How Are AI Code Review Tools Benchmarked, and Can You Trust the Results?".

A two-week test on your own pull requests

CodeRabbit's plans page says new organizations start with a "14-day Advanced trial", and Code Review in Manual mode bills only the reviews you request on a Team or Enterprise plan. Pick ten merged pull requests from the last quarter that later needed a bug fix, so you already know what a careful reviewer should have said, and open each one again from a branch at its original commits. Let CodeRabbit review it, comment @claude review for Code Review, and run /code-review with the PR number in a terminal.

For every comment, note whether it names the known bug, whether you would have deleted it, and how many minutes it took to confirm. After two weeks you have known bugs named out of ten, comments you would delete per pull request, and cost per pull request in each vendor's own unit. That answers CodeRabbit vs Claude Code for your code, and if your code is written with Claude Code, it also shows how each reviewer does on changes from that tool.

Sources, all read on 11 October 2026. Anthropic: Code Review, Claude Code GitHub Actions, ultrareview, GitHub Enterprise Server, GitLab CI/CD, feature availability, data usage, docs index, Code Review launch article, CodeRabbit in the Claude Marketplace. CodeRabbit: pricing, plans, rate limits, usage-based reviews, platforms, FAQ, architecture, pull request reviews, review commands, self-hosted, coding guidelines, Claude Code plugin, Claude Marketplace news, Sonnet 5.5 write-up. Sigma: homepage and reading a review.

Explain how an importance gate prevents noise accumulation in persistent agent memories.

Edward Izgorodin — Tue, 13 Oct 2026 11:10:00 +0000

An agent that saves everything it hears fills up fast. Within a week its store holds "The deployment region is Dublin." three times, a reworded copy twice, a dozen "ok, thanks" and the JSON of every tool call. Ask where you deploy, and copies of one fact take the top results. Nothing was retrieved wrongly. The store accepted writes it should have refused.

The short answer: an importance gate is a test on the write path that decides whether an incoming write is stored at all, so noise is refused before it can pile up and crowd later reads. It prevents only the noise its test can see. A sameness test refuses repeats, a written list refuses the noise it names, a model's judgement against criteria you write refuses chatter at the cost of inference, and declared types refuse what falls outside your schema. The name does not tell you which of these you have.

A gate decides storage, not ranking

A write gate is a decision on the write path about whether an incoming write is stored at all. It does not rank memories at read time. Two distinctions matter:

Refusing a write is not filtering what is extracted from it. A product can drop an extracted entity and still keep the text it came from.
The name does not fix the test. Mnemoverse (the author's company) defines the write response field stored in its API reference as "True if the write passed the write gate (novelty check)", and the number in the field it calls importance as a "Novelty score [0, 1]: how different the write is from the nearest existing memory in the same domain". Mem0's OpenClaw integration describes "a structured protocol with importance gates and domain overlays": in its triage protocol the agent judges every candidate fact against four gates, and Gate 2, NOVELTY, checks it against memories already recalled. One word, two tests.

Match the test to the noise

The noise you have	A test that matches it	What it costs
The same text twice	A hash of the content, or a novelty comparison	A lookup, or a comparison with nearby memories
The same fact reworded	A similarity or novelty comparison with stored memories	An embedding of the write and a search of nearby memories
Chatter you can name	A written list of patterns	A list to maintain
Chatter you cannot name	A model's judgement against criteria you write	Model inference, and the occasional miss
Anything outside your schema	Declared types	A schema to maintain; only what you declared is caught

A sameness test asks the wrong question about chatter: a new "ok, thanks" restates nothing stored, so it passes. Named junk is a list. Unnamed junk is a model, and you pay for the call, including the miss.

What six products test on the write path

Each row is a named, documented path as the vendor's own page states it, not every path a product has. Nothing here is a measurement.

Product and path	What the test asks	What a refused write becomes
Mem0: add path, OpenClaw triage	Is the fact already stored? In the plugin: does it pass all four triage gates?	A recognised duplicate is not stored again; triage writes nothing; a message matching a noise pattern is dropped
Cognee: session distillation, folder presort	Not rated harmful, with confidence through the distillation gate? Does a writer, checking existing lessons, accept the lesson? Which scanned groups do you approve?	A rejected lesson is dropped; presort ingests only the groups you approve
Letta: Letta Code reflection pass	Lasting rather than ephemeral, not already captured, generalizable?	No change and no commit
Supermemory: organizational context (API v5), document ID	What does your organisation do, and what content matters, in words you write? Was this ID sent before with the same content?	Steers what gets extracted into memories; casual chatter is less likely to become durable memory; an unchanged duplicate under the same ID queues no new work
Zep: episode ingestion, strict ontology	Within the size limit? Does an extracted entity match a declared type?	Oversized episode rejected, not truncated; undeclared entity dropped while the episode stays
Mnemoverse: write API	How novel is the write against the nearest memory in the same domain?	Nothing stored: `stored` false, a null `atom_id`, a `reason`

Mem0 checks related memories on its add path "so it can avoid storing the same fact again" (How Mem0 works). Its open source pipeline lists "Hash-based deduplication (MD5, prevents exact duplicates)" (v2 to v3 migration), and its hosted platform reaches further, per its Dream page: "most exact or near-duplicate restatements of a fact you already have are recognised and deduplicated as the memory is added". Its custom instructions add a model's judgement against criteria you write. The OpenClaw triage protocol says: "Most turns produce zero memory operations. That is correct and expected." The plugin's filtering.ts drops whole messages that match "Patterns that indicate an entire message is noise", among them acknowledgements, timestamps and tool output.

Cognee states its gate on the improve page: "Guidance is eligible only when it has not been rated harmful and its confidence passes the distillation gate." Proposed lessons then go to a writer/rejecter, which "checks them against existing lessons and graph entities". Its folder presort "reports what is junk, duplicated, versioned, personal, or already in cognee, and then ingests the groups you approve", so the refusal comes back as a report. Its add operation says "Cognee uses content hashes to avoid duplicates".

Letta puts the decision with the agent: "Your agent updates memory when it learns something durable" (memory page). The reflection prompt that Letta Code ships includes an already-captured check, "If memory or skills already contain this information adequately, skip it.", an instruction to a model rather than a threshold in code.

Supermemory takes a description you write of your organisation (customization): "Tell Supermemory what your organization does and what content matters during ingestion. This steers what gets extracted into memories across every namespace." In v3 and v4 that field was called filterPrompt, and the same page says: "The legacy shouldLLMFilter, categories, includeItems, and excludeItems settings are not part of the v5 organization resource." The ingestion page ties duplicate handling to an ID you supply: "Pass id to identify content and avoid duplicates". Its graph memory page lists noise filtering under automatic forgetting, as a tendency: "casual, non-meaningful chatter is less likely to become durable memory".

Zep shows the difference between filtering extraction and refusing a write. With strict ontology on, an entity that does not match a declared type is dropped, while "the raw source material remains searchable and retrievable" (how graph creation works). Its ingestion guide adds a sameness test on extraction, "When Zep extracts entities from episodes, it deduplicates them primarily by name.", and a hard refusal on size: "Zep rejects an episode larger than 10,000 characters rather than truncating it".

Mnemoverse says what its gate does on its getting started page: "The write gate compares each write with the nearest existing memory in the same domain and refuses only a write the embedder cannot tell apart from one already stored: stored is then false. The number in importance is that novelty score; the gate does not judge how important or how true a memory is." A refused write has no id: the API reference defines atom_id as "UUID of the stored atom, or null if filtered" and reason as "Why stored or filtered". So the field called importance is a novelty score, and this gate belongs to the sameness family: it stops a domain from filling with copies the embedder cannot tell apart, and it does not judge whether a new line is worth keeping. Chatter that differs from everything stored has to be kept out by what the agent chooses to write, or by a list or a model in front of the write.

Check it with a control

Four writes in a fresh domain, with mnemoverse 0.4.0:

from mnemoverse import MnemoClient

client = MnemoClient()  # reads MNEMOVERSE_API_KEY

writes = [
    "The deployment region is Dublin.",
    "The deployment region is Dublin.",             # identical
    "Deployments run in the Dublin region.",        # reworded
    "The staging database is backed up nightly.",   # control: a new fact
]
for text in writes:
    r = client.write(text, domain="project:gate-check")
    print(r.stored, r.atom_id, round(r.importance, 2), r.reason, "|", text)

The identical sentence is the case the docs describe as refused: expect stored False, no id and a reason. Record the reworded line rather than assume it. The last write is the control: a new fact has to come back stored; if it is refused, the check is broken.

Then write a correction phrased like the fact it corrects, "The deployment region is now Frankfurt.", because a sameness test has to tell a correction from a restatement; on Mnemoverse the correction can name what it replaces with supersedes. Run the same cases on any store and insist on a reason for each refusal: a silent filter is a write path you cannot debug.

The library page has the full comparison with every source and carries the film that goes with it. Which noise does your store keep that its gate was never built to see?

CodeRabbit vs Bugbot?

Edward Izgorodin — Mon, 12 Oct 2026 11:12:00 +0000

Pick by where your team already works, how you want the bill to grow, and whether the reviewer must run inside your network. Both review pull requests on GitHub, GitLab, Bitbucket and Azure DevOps. Bugbot is part of Cursor and bills each run from Cursor usage, $1.00 to $1.50 on average by Cursor's figure, and I found no self-hosted Bugbot in Cursor's docs. CodeRabbit bills per developer who opens pull requests, from $24 a month on an annual plan, self-hosts on Enterprise from 500 seats, and also works inside Cursor through an extension and a plugin. Neither publishes a neutral head-to-head number, so the tiebreaker is both 14-day trials on the same pull requests.

Every fact below comes from each vendor's own pages as I read them on 10 October 2026, and neither CodeRabbit nor Cursor saw this text before publication.

The two side by side

Each cell is from the vendor's own pages; links are at the end. "Not found" means not found on the docs, product, pricing, help and changelog pages I searched that day.

	CodeRabbit	Cursor Bugbot
Company, as each page states it	CodeRabbit Inc.	Cursor (Anysphere, Inc.); "Cursor has officially been acquired by SpaceX." (14 August 2026)
Code hosts listed	GitHub, GitLab, Azure DevOps, Bitbucket Cloud and Data Center, GitHub Enterprise Server, self-managed GitLab	Origin (Cursor's own Git forge, in early beta), GitHub with Enterprise Server, GitLab with Self-Hosted, Bitbucket with Data Center, Azure DevOps Services
When it reviews	when a PR opens against the main branch, then on new commits; `@coderabbitai review` on demand	when a PR is created or updated, by default only the changes since its last review; `bugbot run` on demand; can be set to once per PR
What you pay for	developers who create pull requests: Essentials $24 per developer per month billed annually, $30 monthly; 5 PR reviews per developer per hour on Essentials; optional overflow at $0.25 per reviewed file	each run, from included usage first on Individual plans and from on-demand spend on Teams; listed on Cursor's Individual (from $20 a month) and Teams ($40 per user per month) plans
Free entry	PR summaries; reviews in the VS Code extension and CLI; Team features for open-source projects; a 14-day Advanced trial for new organizations	14-day trial for all plans; some plans include monthly Bugbot usage; a free or open-source offer not found
Self-hosting	Enterprise, 500 or more user seats, with your own model provider	a self-hosted Bugbot not found; for GitHub Enterprise Server, Cursor documents IP allowlisting or, on Enterprise, AWS PrivateLink or a Cloudflare Tunnel, which it offers for an "outbound-only deployment model"
Model providers (cloud)	"Your code is shared with OpenAI and/or Anthropic for reviewing purposes only"	Cursor sends "prompts and code context to language model providers like OpenAI, Anthropic, and Google"; Bugbot uses "a combination of frontier and in-house models"
Training on your code	"CodeRabbit never uses customer code for model training."	not with Privacy Mode on, which is "on by default for Enterprise teams"; with it off, Cursor may train on code data
How a finding is checked	a Verification agent, sandboxed execution with the repository cloned, 50+ static analyzers	an agent reviews the diff and calls tools; running code to verify its own reports is listed as a next capability (January 2026)
Fixes	`@coderabbitai autofix`, Azure DevOps included	Autofix spawns a Cloud Agent; no Autofix mode for Azure DevOps
Before the pull request	IDE extension, CLI, a Cursor plugin	`/review-bugbot` in Cursor and its CLI; a later PR with the same diff is skipped

How each one says it handles false positives

CodeRabbit describes a pipeline that filters before it posts. Its architecture page lists "Specialized AI agents working in parallel: Review, Verification, Chat, Pre-Merge Checks", on top of "Sandboxed cloud execution with your full repository cloned for isolated analysis". Its September write-up says what reaches you: "Reported comments is the post-pipeline count after verification, deduplication, and filtering; someone still has to read each one."

Cursor describes a reviewer tuned against a fix rate. The product page says "Bugbot detects the hardest logic bugs with a low false positive rate." and "Bugbot optimizes for bugs that get fixed." Cursor's January write-up defines that rate: "It uses AI to determine, at PR merge time, which bugs were actually resolved by the author in the final code." It describes a launch version that used "a validator model to catch false positives", and a later switch to "a fully agentic design".

On running code, the two write in different tenses. The same Cursor write-up says: "The next major capabilities include letting Bugbot run code to verify its own bug reports and enabling deep research when it encounters complex issues." I found no later Cursor page saying this shipped, in the Bugbot docs, product and help pages, or the changelog from June 2025 to October 2026. Code does run on the fix side: Bugbot Autofix, a separate setting, "runs cloud agents on their own machines to test changes and propose fixes directly on your PR." On the review side, CodeRabbit's architecture page puts "Sandboxed cloud execution" behind each comment, and its FAQ says the reviewer "Can execute shell commands and perform deep static analysis against your codebase".

What each publishes as numbers, and how

	CodeRabbit	Cursor Bugbot
What is compared	Claude models inside CodeRabbit's own pipeline	Bugbot against five other AI reviewers, CodeRabbit among them
Metric and data	known issues caught through actionable comments, on 13 hardest known-bug cases	resolution rate, the share of flagged bugs resolved by merge; "We analyzed public repositories only."
Who judges	"an independent judge scored every comment with three votes against the known issue, and only majority-PASS comments count"	"using an LLM judge", spot-checked with PR authors while the metric was built
Headline	Sonnet 5.5 caught 6 of 13 issues, at 41.2% actionable precision (passing actionable comments divided by all actionable comments)	Bugbot first of six, at a 78.13% resolution rate on 50,310 pull requests
When	28 September 2026	8 April 2026
What it leaves out	"Thirteen cases is a small set, and we say so throughout."	by its definition, a bug nobody flagged never enters the rate
A number with little method beside it	"reducing PR comment noise by 80%" (IDE extension)	high effort "finds 35% more bugs while resolution rate stays constant at 80%", stated "From our internal runs"

The two headlines answer different questions: CodeRabbit's is about which model it runs, Cursor's ranks Bugbot against rivals on a metric Cursor defined. Cursor's table has a row for CodeRabbit; I do not repeat that figure, because it is Cursor's metric applied to CodeRabbit. I found no CodeRabbit page about Bugbot in its sitemap (596 addresses), llms.txt or docs index. What CodeRabbit does publish is a Cursor plugin, and its 25 August 2026 post about it says "Our partnership with Cursor brings code creation and agentic change management closer together." A comparison written by anyone who sells a reviewer is that seller's case, so each tool here is described from its own pages.

How to choose for a team

If this is true for your team	Look first at	What the pages say
Code must stay inside your network	CodeRabbit, at 500 seats or more	self-hosted on Enterprise from 500 user seats; a self-hosted Bugbot not found
The team already pays for Cursor Teams	Bugbot	reviews bill from the same on-demand spend; `/review-bugbot` before a push
The bill should follow headcount	CodeRabbit	per developer who opens pull requests; Bugbot bills per run
You do not know which bill is smaller	count runs, not pull requests	$24 per developer per month equals 16 to 24 Bugbot runs at Cursor's average, and Bugbot runs on every PR update unless set to once per PR
Azure DevOps, with automatic fixes	CodeRabbit	`@coderabbitai autofix` lists Azure DevOps; Bugbot's Autofix table marks it No for both modes
Your policy rules out training on your code	both data pages, with whoever owns the policy	CodeRabbit never trains on customer code; at Cursor it depends on Privacy Mode, which a team admin can enforce
Each finding should pass a separate check before it is posted	CodeRabbit; on GitHub, also Sigma (Mnemoverse, the author's company), in closed beta by invitation	CodeRabbit lists a Verification agent among its agents; for Bugbot, Cursor describes a validator model at launch and a later switch to "a fully agentic design"; Sigma's page says "Sigma checks potential issues and brings the evidence back to your code.", its docs document that a fresh verifier "confirms, rejects or reclassifies" each candidate, that "only confirmed candidates are verified findings" and that suspicions no verifier confirmed stay labeled separately; Sigma runs on Claude Code and OpenAI models and reviews its team's own repositories every day; its page also says "A request does not grant access automatically."

A two-week test that settles it

CodeRabbit's plans page says new organizations start with a "14-day Advanced trial", and Cursor says "We offer a 14-day free trial for all plans." Install both on one busy repository. Take five bugs your team fixed after merge, open the commits that introduced them as new pull requests, and, if your Bugbot plan offers effort levels, run some reviews at High, since Cursor's docs say that at Default "Bugbot may find fewer bugs". Mark every comment as a real bug, a wrong claim or noise, and time each confirmation. Two weeks give you known bugs caught out of five, wrong claims per pull request, minutes per comment, and a count of Bugbot runs to price against CodeRabbit's seats. The same test works for any other reviewer on your shortlist, such as GitHub Copilot code review, Greptile or Sigma.

Sources, all read on 10 October 2026. CodeRabbit: homepage, pricing, plans, platforms, self-hosted, FAQ, architecture, pull request review, review commands, IDE and CLI, docs index, Sonnet 5.5 write-up, Cursor plugin, sitemap. Cursor: Bugbot, Bugbot docs, help, usage billing, pricing, May 2026 changes, Building a better Bugbot, learned rules and resolution rates, Autofix changelog, changelog, GitHub integration, Origin, privacy, data use, joining SpaceX. Sigma: home page, docs, reading a review.

How to disable Copilot code review in GitHub?

Edward Izgorodin — Sun, 11 Oct 2026 10:35:00 +0000

Copilot reviews a pull request only when someone asks, unless automatic review is switched on, so the first step is to find out which switch asked. GitHub documents four sources: your own "Automatic Copilot code review" setting, a repository ruleset, an organization or enterprise ruleset with the rule "Automatically request Copilot code review", and a person or a bot requesting Copilot as a reviewer. Turn off the one that applies. The automatic ones are independent: "These configurations are not hierarchical; neither inherits from or overrides the other." To stop people who bring their own Copilot license from requesting reviews in your repository, a repository admin or organization owner enables "Only allow Copilot code review to be triggered by authorized users". An organization owner can turn off the Copilot code review option for members who get Copilot from the organization, and an enterprise can block it in all its repositories.

Every step below is from GitHub's own documentation as I read it on 9 October 2026, and GitHub did not see this text before publication.

Where the review comes from and who can turn it off

Where the review comes from	Who can turn it off	Where	What it does not stop
Your own automatic setting	you	profile picture > Copilot settings > Code review: turn off "Automatic Copilot code review"	rulesets and other people's requests
A repository ruleset	repository admins, or a custom role with "edit repository rules"	Settings > Rulesets: clear "Automatically request Copilot code review", set the ruleset to Disabled, or delete it	the author's own setting
An organization ruleset	organization owners and users with "Manage organization ref update rules and rulesets"	organization Settings > Repository > Rulesets	the same
An enterprise ruleset	enterprise owners	the enterprise-level branch ruleset	the same
A Copilot license from outside your organization or enterprise	repository admins, or organization owners for all repositories	Settings > Copilot > Code review: enable "Only allow Copilot code review to be triggered by authorized users"	ruleset reviews
Copilot from your organization	organization owners	organization Settings > Copilot > Policies: the Copilot code review option	an enterprise policy; a second organization that enables it
Members without a license	enterprise administrators or organization owners	keep "Allow members without a Copilot license to use Copilot code review in GitHub.com" disabled, its default	members with a license
Every user in an enterprise's repositories	enterprise owners and AI managers	AI controls > Agents > Copilot code review: "Block Copilot code review in all enterprise repositories"	nothing named; it covers personal plans too
One pull request	anyone who can request reviews	the Reviewers sidebar, or `gh pr edit`	not said for a review already running or posted

How to tell which switch asked

If no setting of yours asked, look at the author: their own automatic review covers their pull requests "in any repository where Copilot code review is available to you". An author on Copilot Free has no such setting, because the Free plan "does not include Copilot code review".

Then the rulesets. Anyone with read access can view the active ones, and the shortcut is "adding the /rules slug to the repository's URL". Or, from a terminal:

gh ruleset check main

Last, the requester. GitHub's general rule for review requests is that "you need write access to the repository", and that page does not say whether it covers Copilot. Requests also come through the REST API as "copilot-pull-request-reviewer[bot]", and through GraphQL since 2 October 2026, so a workflow or a bot can ask. By default, AI credits go to the pull request author when a repository requests the review automatically and to the requester for a manual one; the organization pays "when a bot requests the review", and the organization or enterprise pays for people without a Copilot license or on Copilot Free. For members with a paid Copilot license, an enterprise or organization owner "can instead choose to bill the organization".

What each switch leaves running

Your own setting exists on the Copilot Pro, Copilot Pro+ and Copilot Max plans and with a Copilot Business or Copilot Enterprise license, not for managed user accounts. Turning it off does not touch rulesets: "Your user settings cannot disable push or draft reviews that a ruleset has enabled." Your review effort stays as set. A repository's automatic review lives in its ruleset, under "Branch rules", not in Settings > Copilot > Code review.

A license is external when it is "not provided by the organization or enterprise that owns the repository", and by default people can use one to request a review. With the authorized-users setting on, "Copilot is not offered as a reviewer to people who are not authorized, and API review requests from those people do not start a review." In a personal repository only the owner or a direct collaborator can then request one. Automatic reviews from personal settings of people who are not authorized stop. "Automatic reviews configured by repository or organization rulesets still run." Set at the organization, it cannot be turned off per repository. GitHub documented it on 7 October 2026.

The organization option governs reviews "on GitHub.com or in GitHub Mobile" for members who get Copilot from that organization: "Generally, policies only apply to users on your Copilot plan." An enterprise choice wins: "you cannot override that setting at the organization level." For a person with Copilot from several organizations in one enterprise the policy is "Least restrictive": "if any of the organizations has enabled a feature, this feature is enabled for the user everywhere."

The enterprise block reaches further, "including for users who get access to Copilot from a personal plan or another enterprise." Turning the enterprise's Copilot code review policy off instead covers its licensed users and also removes pull request summaries: the policy "allows your licensed users to request reviews from Copilot and use Copilot to generate pull request summaries."

For one pull request:

gh pr edit 123 --remove-reviewer "@copilot"

The @copilot value is "not supported on GitHub Enterprise Server", where Copilot is not available. The pages I read do not say what removing the request does to a review already running or posted, and a review "usually takes less than 30 seconds". Resolving a Copilot comment does not keep it away: "Copilot may repeat the same comments again, even if they have been dismissed".

Before 22 October 2026, for enterprises

GitHub's default availability page says the "Default policy for new features" policy "will start applying to new and existing GA features from October 22, 2026." The covered features include the Copilot code review policy on the Agents page. The default policy itself starts enabled, and "unconfigured features will be enabled on October 22". It covers enterprises with Copilot Business or Copilot Enterprise, and organizations that were left to decide and have not configured the feature. To keep Copilot code review off, set its policy explicitly before 22 October 2026 or disable the default policy. The date will change availability, not automatic review, which will still need a ruleset or a person's own setting.

If you want review only on request

Tool	By default	Request-only switch	How to ask
GitHub Copilot	"By default, Copilot only reviews a pull request if you assign it to the pull request."	leave automatic review off everywhere	Reviewers sidebar, or `gh pr edit 123 --add-reviewer "@copilot"`
CodeRabbit	"CodeRabbit reviews every eligible PR automatically"	`enabled: false` under `reviews.auto_review`	`@coderabbitai review` (incremental) or `@coderabbitai full review`, "Regardless of any auto-review configuration"
Cursor Bugbot	"Runs automatic reviews on every PR update"	personal setting "only when mentioned"; per repository, `manualTriggerOnly` in the Bugbot Admin API	`cursor review` or `bugbot run`
Greptile	config default `"autoReview": ["open"]`, which starts a review "unasked" when a pull request is opened	`"autoReview": []`	`@greptileai`
Qodo	"Automatic is the default."	Code review trigger set to Manual only	`/agentic_review`
Sigma (Mnemoverse, the author's company)	closed beta on GitHub for invited accounts; documented modes Automatic, On request and Off, invited accounts start with On request	On request: "Explicit requests only. A push alone does not start this reviewer."; Off: "No new review or recheck work."	`/sigma review`; documented: invited accounts need GitHub-confirmed admin, maintain or write access

Sources, read on 9 October 2026. GitHub Docs: Configuring code review by GitHub Copilot, About GitHub Copilot code review, Using GitHub Copilot code review, organization policies, policy conflicts, enterprise and organization policies, enterprise code review policy, blocking agentic features, default availability, repository rulesets, organization rulesets, enterprise rulesets, requesting a review, plans. GitHub CLI manual: gh pr edit, gh ruleset check. GitHub changelog, 2 October 2026. The docs change of 7 October 2026. CodeRabbit automatic review controls, Cursor Bugbot docs, Greptile trigger configuration, Greptile config reference, Qodo, trigger a code review. Sigma: its public home page and documentation.

CodeRabbit vs Copilot?

Edward Izgorodin — Sat, 10 Oct 2026 13:14:00 +0000

Pick by four things your team already knows: where your repositories live, whether a bot should review every pull request or only on request, how you want to be billed, and whether the reviewer must run on your own servers. On their own pages, GitHub Copilot code review works on GitHub.com (Azure DevOps in public preview), reviews a pull request when someone requests it unless you turn on automatic reviews, and bills each review in GitHub AI Credits plus Actions minutes; CodeRabbit covers GitHub, GitHub Enterprise Server, GitLab, Azure DevOps and Bitbucket, reviews every eligible pull request by default, bills per developer who opens pull requests and self-hosts from 500 seats. On neither vendor's pages did I find a head-to-head result with a method behind it, so the tiebreaker is both tools on the same pull requests.

Every fact below comes from each vendor's own pages as I read them on 9 and 10 October 2026, and neither GitHub nor CodeRabbit saw this text before publication.

The two side by side

Each cell is from the vendor's own pages, read on 9 and 10 October 2026; links are at the end. "Not found" means not found on those pages or in the vendor's docs index that day.

	CodeRabbit	GitHub Copilot code review
Where it reviews pull requests	GitHub, GitHub Enterprise Server, GitLab and self-managed GitLab, Azure DevOps, Bitbucket Cloud and Data Center	GitHub.com, GitHub CLI and GitHub Mobile; Azure DevOps in public preview; GitLab and Bitbucket not found
GitHub Enterprise Server	supported, with a reverse tunnel when the server cannot accept inbound access; also on self-hosted CodeRabbit	"Copilot is not currently available for GitHub Enterprise Server."
When it reviews	every eligible pull request to the default branch, automatically, drafts skipped; again on each push, pausing after 5 reviewed commits by default; `@coderabbitai review` on demand	when someone requests Copilot as a reviewer (web, CLI, Mobile, API); automatically when an author turns it on for their own pull requests or a ruleset does; once per pull request unless "Review new pushes" is on or someone re-requests it
Replies in the thread	answers when you reply with `@coderabbitai`	replies are not visible to Copilot, and "Copilot won't reply"
What you pay for	developers who create pull requests: Essentials $24 per developer per month billed annually, $30 monthly; 5 PR reviews per developer per hour; optional overflow at $0.25 per reviewed file, with a monthly spending cap	GitHub AI Credits at $0.01 each, from a plan that includes code review (Business: $19 per granted seat per month, 1,900 credits per user per month, pooled); GitHub estimates $0.05 to $1 per review on Lite effort and $0.25 to $5 on Balanced, plus Actions minutes
Default level	Chill profile; Quiet, Chill and Assertive set how much it comments	Balanced effort since 28 September 2026; Lite and Balanced set how deep it analyses, and Balanced uses more credits
Free entry	PR summaries; reviews in the VS Code extension and CLI; Team features for open-source projects; a 14-day Advanced trial for new organizations	Copilot Free does not include pull request review, and in VS Code offers only "Review selection"; verified students get Copilot Student, which includes code review, and verified teachers and maintainers of popular open-source projects may get Copilot Pro free
Self-hosting	Enterprise, 500 or more user seats, with your own model provider	a self-hosted review service not found; the agentic steps can run on your own self-hosted runners
Models and training	cloud: "Your code is shared with OpenAI and/or Anthropic for reviewing purposes only"; "CodeRabbit never uses customer code for model training."	a model mix chosen by GitHub, "Model switching is not supported"; Business and Enterprise data not used for training; Free, Pro and Pro+ interactions may be used unless the user opts out
Instruction files it reads	AGENTS.md, CLAUDE.md, Cursor rules, `.github/copilot-instructions.md` and more	`.github/copilot-instructions.md`, path-specific `.instructions.md` files, AGENTS.md, CLAUDE.md, GEMINI.md, REVIEW.md

How each one talks about noise

GitHub put its position in three sentences, in a March 2026 post: "Silence is better than noise. In 71% of the reviews, Copilot code review surfaces actionable feedback. In the remaining 29%, the agent says nothing at all." That number splits reviews into those that leave feedback and those that stay silent. It is not a precision figure, and I did not find on that page a definition of "actionable" or the period and sample behind the 71%. The method is given in general terms: "We evaluate performance in two ways: through internal testing against known code issues, and through production signals from real pull requests." The post predates Balanced as the default effort.

In its docs, CodeRabbit makes noise a setting rather than a number. Quiet, added in July 2026, posts "only the most important comments" inline, and "Every other comment is grouped into collapsed sections in the review summary, so nothing is lost while the inline noise stays low." Incremental reviews pause after 5 reviewed commits by default, "To avoid noisy feedback". The one measure of noise I found in those docs, "reducing PR comment noise by 80%", is about the IDE extension and has no method on the page. Its blog does measure precision with a stated method: a September 2026 post scores the models behind CodeRabbit's own reviewer on known bugs from open-source pull requests, which compares models inside CodeRabbit, not CodeRabbit with Copilot.

Out of the box the two sit at opposite ends: Copilot waits to be asked and reviews once per request, CodeRabbit reviews every eligible pull request and follows each push. Settings move each toward the other, as both tables show.

What each says about the other

CodeRabbit's case is about who reviews whom. Its webinar page "Who reviews Copilot's code?" says: "Copilot is great at writing code, but asking any coding agent to review its own output is a self-review." The multiplier and the precision figure on that page compare CodeRabbit with "self-reviews by coding agents", not with Copilot code review, and come with no method, so I leave them out. GitHub describes its reviewer as "a purpose-built product that uses a carefully tuned mix of models, prompts, and system behaviors", and is plain about the limit: "Copilot is not guaranteed to spot all problems or issues in a pull request. Sometimes it will make mistakes." I found no mention of CodeRabbit on the GitHub pages I read, and no Copilot comparison page among the 596 addresses in CodeRabbit's sitemap.

How to choose for a team

If this is true for your team	Look first at	What the pages say
Repositories live in GitLab or Bitbucket	CodeRabbit	not found on Copilot's code review pages
You run GitHub Enterprise Server	CodeRabbit	"Copilot is not currently available for GitHub Enterprise Server."
Code must stay on your own servers	CodeRabbit, from 500 seats, with a model provider you choose	a self-hosted Copilot review service not found; below 500 seats, neither of these two
You already pay for Copilot Business or Enterprise on GitHub.com	Copilot, as the first trial	nothing to install; by default reviews draw on the pooled credits, and an enterprise or organization owner can choose to bill the organization instead; members without a license can be reviewed once an enterprise administrator or organization owner enables it, billed to the organization or enterprise
Reviews only when someone asks	Copilot	its default; CodeRabbit gets there with automatic reviews off plus a label or `@coderabbitai review`
The bill should follow headcount, not review volume	CodeRabbit	per developer who opens pull requests, with an hourly allowance; at Copilot each seat adds credits to a pool, and by default each review draws on it by pull request size and effort
Review before commit in Visual Studio, JetBrains or Xcode	Copilot	Copilot lists VS Code, Visual Studio, JetBrains IDEs and Xcode; CodeRabbit lists VS Code-based editors and a CLI
Each finding should pass a separate check before it is posted	CodeRabbit; on GitHub, also Sigma (Mnemoverse, the author's company), in closed beta by invitation	CodeRabbit's architecture page lists "Specialized AI agents working in parallel: Review, Verification, Chat, Pre-Merge Checks"; Sigma's page says "Sigma checks potential issues and brings the evidence back to your code.", its docs document that a fresh verifier "confirms, rejects or reclassifies" each candidate, that "only confirmed candidates are verified findings" and that suspicions no verifier confirmed stay labeled separately; Sigma runs on Claude Code and OpenAI models and reviews its team's own repositories every day; its page also says "A request does not grant access automatically."

A two-week test that settles it

CodeRabbit's plans page says new organizations start with a "14-day Advanced trial". On the Copilot side, a team whose plan includes code review can request Copilot on the same pull requests, which keeps the cost of the test in your hands. Set the effort level on purpose: since 28 September 2026 the built-in default is Balanced, the more expensive of the two levels on offer.

Take five bugs you already fixed, reopen the commits that introduced them as new pull requests, and mark every comment as a real bug, a wrong claim or noise. After two weeks you have numbers of your own: known bugs caught out of five, wrong claims per pull request, minutes per comment, and what each review cost. They answer CodeRabbit vs Copilot for your code, which no vendor's chart can do. The same test works for any other reviewer on your shortlist, such as Cursor's Bugbot, Greptile or Sigma.

Sources, all read on 9 and 10 October 2026. GitHub: Copilot code review, using code review, configuring code review, plans (docs), plans and data FAQ, effort default changelog, 60 million reviews post, docs index. CodeRabbit: pricing, plans, platforms, GitHub Enterprise Server, self-hosted, automatic review controls, pull request reviews, configuration reference, architecture, code guidelines, IDE and CLI, IDE extension, FAQ, changelog, docs index, webinar page, model benchmark post, sitemap. Sigma: home page, docs, reading a review.

How to implement context decay so an AI agent forgets stale or incorrect instructions over time?

Edward Izgorodin — Fri, 09 Oct 2026 09:18:00 +0000

A year into a project, one agent's memory holds three instructions that should no longer win. It says to install packages with npm, and since June it also says to use pnpm; both are still there, and either can come back first. It holds a workaround for a library bug that was fixed in the spring, and nothing has needed it for months. It says to retry a failing integration test until it passes, and the last time the agent did that, the retries hid a real regression. Each one matches the question it answers exactly as well as on the day it was written.

The short answer: forgetting stale or incorrect instructions takes three operations, and decay is only one of them. Close an instruction when a newer one replaces it: keep it, mark the date it stopped applying and what replaced it, and make reads prefer open instructions. Decay the ones that go unused and unconfirmed for a long time, lowering their ranking with time so they stop competing at full strength. Push down an instruction that misled when the agent acted on it, with an explicit negative mark. None of the three deletes anything. Deletion stays for secrets, personal data on request, and noise nothing ever depended on.

Why a store never forgets on its own

A vector store ranks by closeness in embedding space, and age, deprecation and replacement are not dimensions of that space. Similarity has no age and no status: last year's convention matches today's query exactly as well as it ever did, and nothing in cosine distance says deprecated. The store is not broken. It answers "what is most similar?", while the agent needs "what is currently true?".

Diligence makes this worse: the more carefully agents write memory, the more retired instructions the store holds, and the higher the odds that a recall surfaces one.

Three operations, not one

Context decay lowers an entry's recall priority as time passes without it being used or confirmed, so it drifts down the ranking instead of competing at full strength. It changes ranking, not storage. Each of the three operations answers a different reason an instruction should stop winning:

Operation	When it applies	What changes	What it must not do
Close	A newer instruction replaces it	Marked closed, with the date and its successor; reads prefer open entries	Overwrite or delete the old entry
Decay	Nobody uses, confirms or contradicts it for a long time	Its ranking weight falls with time since it was last used or confirmed	Delete silently
Push down	Acting on it failed	An explicit negative mark ranks it below the alternatives	Spread beyond the entry that misled
Delete	A secret, personal data on request, noise with no history	The entry is gone	Touch anything a past decision depended on

Closing. When an instruction is replaced, do not overwrite it and do not delete it. Mark it closed, record when it stopped applying, and link its successor: "install with npm, true until 2026-06, replaced by pnpm". Reads prefer open instructions, but the closed one still exists, and that matters more than it seems: an agent asked why the January branch has a package-lock.json needs January's instruction to answer. Overwriting rewrites history; closing versions it.

Closing needs to know what replaced what, and that is known for certain only at the moment of the correction. So the correction should name the instruction it closes when it is written, rather than leave a later pass to guess from two similar texts.

Decay. Instructions that are never recalled, never confirmed and never contradicted should not keep competing at full strength forever. One way to build it on a store you control: keep a last-used and a last-confirmed date on each entry, both set when it is written. At read time, fetch more candidates than you need, multiply each retrieval score by a factor that shrinks with the time since the later of the two dates, and stop that factor at a floor above zero, so an old entry that matches a question closely can still come back. Decay should demote, not erase. Decay that quietly deletes cannot be told apart from data loss.

Pushing down. Some instructions are not old, just wrong, and you know they are wrong because acting on them failed. Those deserve an explicit negative mark that ranks them below the alternatives the next time the same question comes up. Push-down is targeted: it lands on the entry that misled. Decay is ambient: it touches everything that goes unused.

Deleting. Hard deletion keeps a narrow, real role. The test is simple: if nothing ever depended on the entry, delete it; if anything did, close it instead.

With plain files, and with a memory system

With plain files, all three are editorial habits: a status line on each entry (active, or closed, replaced by ...), a periodic review that produces a list for a person to approve instead of silent removals, and a rule never to rewrite an old entry in place. It works, and a person is the garbage collector.

With a memory system, the same three become properties to look for: statuses and validity windows on entries, decay that demotes rather than deletes, and a feedback channel for marking what misled.

Closing an instruction in code

The code uses mnemoverse 0.4.0 from PyPI, the Python SDK of Mnemoverse (the author's company), with setup on the Python SDK page. The example covers closing, on the write and on the read, plus a rating after the agent acts. The agent's own logic is left out.

from mnemoverse import MnemoClient

client = MnemoClient()  # reads MNEMOVERSE_API_KEY
DOMAIN = "project:web"

# January: the instruction as it was given
old = client.write(
    "Instruction (2026-01, repo: web): install packages with npm.",
    concepts=["instruction", "package-manager", "npm"],
    domain=DOMAIN,
)
if not old.stored:
    raise SystemExit(f"Not stored: {old.reason}")

# June: the correction names the instruction it closes, in the same write
new = client.write(
    "Instruction (2026-06, repo: web): install packages with pnpm, not npm. "
    "Replaces the 2026-01 npm instruction.",
    concepts=["instruction", "package-manager", "pnpm", "npm"],
    domain=DOMAIN,
    supersedes=[str(old.atom_id)],
)
if not new.stored:
    raise SystemExit(f"Not stored: {new.reason}")
print(new.superseded)  # the ids this write marked as replaced

# Before acting: read, and act only on instructions nothing has replaced
result = client.read("how do I install packages in the web repo", domain=DOMAIN)
current = [item for item in result.items if item.superseded_by is None]
for item in current:
    print(item.content)

# After acting: rate what was used (1.0 helped, -1.0 misled)
if current:
    client.feedback(
        atom_ids=[item.atom_id for item in current],
        outcome=1.0,
        query_concepts=result.query_concepts,
        domain=DOMAIN,
    )

# Explaining the past: ask for replaced instructions too
history = client.read(
    "which package manager did the web repo use in January",
    domain=DOMAIN,
    include_history=True,
)
for item in history.items:
    print("replaced" if item.superseded_by else "current", item.content)

The June write names the January record in supersedes, and the API reference says what happens to a record named there: "A target is not deleted; it gains a superseded_by pointer to the new atom and stays fetchable by ID". Hiding replaced records from ordinary reads is an organisation setting, "Hide replaced memories" under Settings in the console, and it is off by default, so a read can return the January and the June instructions side by side. For that case the reference names the field to check: "while filtering is off, this field is how you tell a replaced revision from a live one". That is why the code filters on superseded_by itself, which gives the same result with the setting on or off. With it on, ordinary reads return current records only, and include_history=True makes replaced ones eligible again under the same ranking, as Reading history describes.

Ratings re-rank what comes back next. The overview states the limit of that: feedback "changes the order of the next read, not the stored text". The two stored checks are there for the write gate: a write that is too similar to the nearest memory in the same domain is not stored, and a refused write returns no id to pass to supersedes.

Check it with a control

Write an instruction, then a correction that names it as replaced. Ask the agent how to do the task. It should follow the correction, not the original.
Ask it to explain something that happened under the old instruction, such as the January lockfile. It should find the closed instruction and say it was replaced, which shows that closing kept the history a deletion would have lost.
Control: ask about an instruction that was never replaced, such as how tests are run. It should come back as current. If it comes back marked as replaced, or the npm instruction comes back unmarked, the closing is not working, and the first answer proves nothing.

The library page has the same three operations in a shorter form, including what to look for in a memory system before you trust it with instructions. Which retired instruction is your agent still following?

DEV Community: Edward Izgorodin

Claude vs Coderabbit for code reviews? Where do we stand on this?

Where things stand on 17 October 2026

What is different since 15 October

If your team is on Pro or Max

If your team is on Team or Enterprise

Running both

How to choose

A test on your own pull requests

What options exist for connecting an AI agent memory layer across both ChatGPT web interfaces and localized coding environments?

The four documented bridge patterns

ChatGPT custom MCP servers, remote MCP, and plugins

The ChatGPT Plugin Directory

OAuth and account identity determine whether memory is shared

Claude Code, Cursor, VS Code, Devin, and Codex setup

What a connected memory server can see

Memory-layer options documented by vendors

OpenAI's Computer History and dots

Six steps to one memory in ChatGPT and your coding tools

Common questions

What options exist for connecting an AI agent memory layer across both ChatGPT web interfaces and localized coding environments?

Can an external memory layer read ChatGPT's saved memory?

Does connecting a memory plugin in ChatGPT also connect Claude Code, Cursor, VS Code, or Codex?

Which ChatGPT plans support custom remote MCP servers?

Do ChatGPT MCP apps work on mobile?

Can ChatGPT and local Codex use the same built-in memory?

Sources

OpenAI: ChatGPT help center

OpenAI: developer documentation and API references

Coding tools

Memory layers and extensions

Related

How to maintain session knowledge across a fleet of specialized developer bots?

Session state and session knowledge

Three kinds of knowledge, three readers

One run, start to finish

If every bot in the fleet is GitHub's own

A minimal version in code

When the bots run under different accounts

Check it with a control

Qodo vs CodeRabbit?

Qodo and CodeRabbit side by side

What the bill depends on

How each one describes noise and checking

What each publishes as numbers, and how

How to choose for a team

A two-week test that settles it

My custom AI bot keeps giving bad advice because it cannot retain feedback from past calls

Why the bot does not learn from its own calls

What to keep from each call

Where the verdict comes from

What a rating changes, and what it does not

A minimal version in code

Check it with a control

AI assistant keeps giving outdated answers after codebase refactoring, how to update its learned knowledge?

Why a refactor leaves the assistant on the old code

Copilot Memory, Claude Code, Cursor, Devin and Cline compared

GitHub Copilot Memory checks cited code against the current branch

Claude Code auto memory dates notes and warns when they are used

Cursor rules should reference files, not copy them

Devin memory links each entry to the session it came from

Cline Memory Bank is documentation you keep current

Memory layers trace a fact to a conversation or document, not to code

Remember or re-read: what the October 2026 preprints measured

Replace the stale note, do not append a correction

A rating moves a note down, it does not say why

What to do after a refactor

Common questions

AI assistant keeps giving outdated answers after codebase refactoring, how to update its learned knowledge?

Why does my AI coding assistant still suggest a function I renamed?

Does Claude Code update its memory after a refactor?

How does GitHub Copilot Memory keep facts from going stale?

Can a thumbs-down rating fix an outdated memory?

Related

CodeRabbit vs Claude Code?

The four options side by side

Why not just ask Claude Code to review the pull request?

What each one costs, in its own unit

Running both

How to choose