Claude Code Now Falls Back to AGENTS.md: What the Standard Merge Means for Multi Agent Repos
Claude Code 2.1.277, shipped September 18, 2026, adds a fallback mode called claude.md or agents.md: if no CLAUDE.md file exists in a project, Claude Code now reads AGENTS.md instead. A CLAUDE.md file, even an empty one, still wins. AGENTS.md passed CLAUDE.md in GitHub adoption back in May, and this fallback is the clearest sign yet that a single project instructions file, not a file per vendor, is becoming the default for teams running more than one coding agent against the same repository.
Claude Code Now Falls Back to AGENTS.md: What the Standard Merge Means for Multi Agent Repos
Claude Code 2.1.277, released September 18, 2026, quietly changed how the tool decides what a repository wants it to know. Before this release, Claude Code read CLAUDE.md and nothing else. Now it runs a fallback: if no CLAUDE.md file exists anywhere in the resolution path, Claude Code reads AGENTS.md instead. If a CLAUDE.md file is present, even an empty one, AGENTS.md is ignored entirely. Anthropic calls the new default mode "claude.md or agents.md," and it is configurable through the Project Instructions setting in /config for teams that want different behavior.
This is a small mechanical change with a larger implication behind it. AGENTS.md is not Anthropic's format. It is an open convention that other agent vendors, including OpenAI's Codex, already read, and by May 2026 it had passed CLAUDE.md in raw GitHub adoption, landing on about 6.2 percent of repositories against a smaller share for CLAUDE.md specifically. Claude Code supporting it as a fallback is Anthropic acknowledging that most serious engineering teams are no longer running one coding agent against a repo. They are running two or three, and maintaining a separate instructions file for each one is exactly the kind of duplicated, drifting configuration that causes agents to disagree with each other about how a codebase actually works.
How the fallback actually resolves
| Scenario | What Claude Code reads |
|---|---|
| CLAUDE.md exists, AGENTS.md does not | CLAUDE.md |
| CLAUDE.md exists and AGENTS.md also exists | CLAUDE.md only, AGENTS.md is not read |
| CLAUDE.md is empty but present | CLAUDE.md (empty), AGENTS.md is not read |
| No CLAUDE.md, AGENTS.md exists | AGENTS.md |
| Neither file exists | No project instructions loaded |
The resolution logic is deliberately conservative. An empty CLAUDE.md still blocks the fallback, which means a stray placeholder file left over from a template or a previous setup silently prevents Claude Code from ever reading a team's AGENTS.md, with no warning that this happened. Anyone migrating toward a single shared instructions file needs to actually delete the old CLAUDE.md, not just empty it out, or the fallback never triggers and the agent runs with no project context at all.
The fallback is implemented as a built in Claude Code Mod, part of the mods system Anthropic uses to ship optional or configurable behavior without hardcoding it into the core agent loop. That framing matters more than it looks: mods are the same mechanism teams can use to build their own custom project instruction handling, which means the AGENTS.md fallback is a reference implementation as much as it is a shipped feature. A team with unusual instruction file conventions, a monorepo with per package files, for instance, has a documented pattern to extend from rather than a black box to work around.
One real limitation as of this release: the fallback is unavailable on Amazon Bedrock, Google Vertex AI, and Microsoft Foundry at launch. Teams running Claude Code through any of those three cloud deployment paths do not get AGENTS.md support yet and still need an explicit CLAUDE.md, regardless of what other agents in their stack are already reading.
Why this is really about the multi agent repo, not the file format
A single project instructions file sounds like a minor convenience until you actually run more than one coding agent against the same repository, which is now the common case rather than the exception. We have covered the shift toward Claude Code, Codex, and Cursor running together as a composable stack rather than as competing exclusive choices, with orchestration, execution, and review split across tools instead of consolidated into one. That pattern only works cleanly if every agent in the stack is reasoning from the same understanding of how the codebase is organized, which conventions it follows, and which commands are safe to run. Two files that drift out of sync, one maintained for Claude Code and a separate one for Codex, is a bug generator: an instruction updated in one file and forgotten in the other produces agents that behave inconsistently on the exact same task, for reasons that are invisible until something breaks in a way that traces back to stale context.
AGENTS.md becoming the shared convention removes that failure mode for any team willing to consolidate. Codex already reads it natively. Cursor and other agent tools have been converging on the same format over the course of 2026 as the ecosystem settled on a lowest common denominator for project level instructions, separate from each vendor's tool specific configuration. Claude Code's fallback is not Anthropic inventing a new standard, it is Anthropic joining one that was already winning on adoption, while preserving CLAUDE.md as the higher precedence option for teams that specifically want Claude Code flavored instructions distinct from what other agents read.
What this changes for how you structure a repo
The practical decision for any team running more than one coding agent is whether to consolidate on AGENTS.md now or keep a CLAUDE.md around for Claude Code specific guidance. Consolidating makes sense when your instructions are genuinely tool agnostic: repository layout, coding conventions, test commands, deployment gotchas, and the kind of institutional knowledge that should be identical no matter which agent is reading it. A CLAUDE.md still earns its keep when you have guidance that is specifically about how to work with Claude Code's particular behavior, permission model, or tool use patterns, content that would be actively wrong if a different agent absorbed it as general instruction.
The failure mode to watch for during migration is exactly the resolution table above: delete the old CLAUDE.md fully rather than emptying it, verify the fallback actually triggered rather than assuming it did, and check whether any part of your deployment runs through Bedrock, Vertex, or Foundry, where the fallback is not yet available and an explicit CLAUDE.md is still required. Repos that already carry both files today are in the safest position; nothing changes for them until they choose to remove the CLAUDE.md deliberately. Repos maintaining a single stale CLAUDE.md purely out of habit are the ones actually affected, and now have a real reason to reconsider that habit.
FAQ
Does Claude Code read both CLAUDE.md and AGENTS.md at the same time? No. If a CLAUDE.md file exists in the resolution path, even if it is empty, Claude Code reads only that file and ignores any AGENTS.md present in the same location.
Do I need to change anything if I already use CLAUDE.md? No. Nothing changes for a repo with an existing CLAUDE.md unless you deliberately remove it to switch to AGENTS.md. The fallback only activates when no CLAUDE.md is present at all.
Does this work with Claude Code on Bedrock or Vertex AI? Not yet. The AGENTS.md fallback is unavailable on Amazon Bedrock, Google Vertex AI, and Microsoft Foundry at launch. Those deployments still require an explicit CLAUDE.md.
Can I customize how the fallback behaves? Yes. The default mode, "claude.md or agents.md," is configurable through the Project Instructions setting in /config, and the fallback itself is implemented as a Claude Code Mod, the same extension mechanism available for building custom instruction handling.
When this applies to your stack
If your engineering team already runs Claude Code alongside Codex, Cursor, or another agent against the same repositories, this release is a real opportunity to collapse duplicated instruction files into one AGENTS.md and remove a quiet source of agent inconsistency. Auditing which repos actually need that consolidation, and which still need Claude Code specific guidance kept separate, is the kind of agent engineering and developer tooling work we do at Contra Collective.
More from the lab.
vLLM vs SGLang: Choosing a Production LLM Inference Engine in Late 2026
vLLM and SGLang are both open source, both built to serve LLMs at production scale, and both frequently recommended for the exact same job, which is exactly why teams keep picking the wrong one. The real difference is not a benchmark number. It is which attention and caching architecture matches your actual traffic pattern, and most teams never check that before they commit infrastructure budget to one or the other.
Ollama's MLX Backend Beats Metal by 93 Percent: Apple Silicon Local Inference Tested (October 2026)
Ollama's 0.19 release notes say it plainly: on Apple Silicon, Ollama is now built on top of Apple's MLX framework to take advantage of its unified memory architecture, rather than the Metal backed llama.cpp path it shipped for years. On an M4 Max running Qwen3.5, that swap took decode speed from 57.8 tokens per second to 111.4, a 93 percent improvement, and prefill from 1,154 to 1,810 tokens per second. The catch is in the fine print: the MLX runner is in preview, it needs 32GB or more of unified memory to activate at all, and as of this release it only accelerates one model family. Here is what actually changed, what it costs to turn on, and where it still falls back silently to the slower path.
DGX Spark vs Mac Studio M5 Ultra: Local LLM Inference Benchmarked (October 2026)
The M5 Ultra Mac Studio shipping in September 2026 is a quad die chip with 1.2 terabytes per second of memory bandwidth and up to 256GB of unified memory, with a 512GB configuration arriving in late October. Against a single NVIDIA DGX Spark, it is not close: on a 27B dense model, the Mac decodes at roughly four times the speed. Cluster two DGX Spark units together over NVIDIA's GX10 networking instead, and the comparison flips for a different workload entirely, concurrent multi user serving. Neither machine is the right answer for every workload, and the decision comes down to whether you are serving one user or several at once.