I think I'd be happier with a standard .agents directory and have all of these in there. I imagine each agent is going to need its own tweaks to get it to work just right with their system prompts, just as Claude already has it's project-specfic .claude directory for hooks and commands and whatnot.

I'd rather .agents/claude or something so we can get these files out of the root directory, which, at least for typescript projects, is already a confetti-like jumble of json files for every little "simple" tool that needs its own configuration file.

I get why package.json isn't enough. But would a .config directory standard really have hurt us so much?

Every time I’ve ever read a {CLAUDE|GEMINI|QWEN}.md I’ve thought all this information could just be in CONTRIBUTING.md instead.

That sounds nice and I have the same pain, but not sure AGENT.md is the right abstraction either. After all, these models are indeed different and will respond differently even given the same prompting. Not to mention that different wrappers around those models have different capabilities.

e.g. maybe for CURSOR.md you just want to provide context and best practices without any tool-calling context (because you've found it doesn't do a great job of tool-calling), while for CLAUDE.md (for use with Claude Code) you might want to specify tools that are available to it (because it does a great job with tool calling).

Probably best if you have an AGENT.md that applies to all, and then the tools can also ingest their particular flavor in addition, which (if anything is in conflict) would trump the baseline AGENT file.

  AGENT.md
  AGENT.CLAUDE.md

  @agent-disable CLAUDE
  These instructions are not parsed by claude
  @agent-enable CLAUDE

I asked claude code for a guidelines file so it would collaborate with windsurf. This is what it proposed:

---

    This project uses shared planning documents for collaboration with Claude Code. Please:

    1. First read and understand these files:

       - PLAN.md - current project roadmap and objectives

       - ARCHITECTURE.md - technical decisions and system design

       - TODO.md - current tasks and their status

       - DECISIONS.md - decision history with rationale

       - COLLABORATION.md - handoff notes from other tools

    2. Before making any significant changes, check these documents for:

       - Existing architectural decisions

       - Current sprint priorities

       - Tasks already in progress

       - Previous context from Claude Code

    3. After completing work, update the relevant planning documents with:

       - Task completion status

       - New decisions made

       - Any changes to architecture or approach

       - Notes for future collaboration

    Always treat these files as the single source of truth for project state.

  @AGENTS.md

I really like the idea of standardizing on AGENT.md, although it's too bad it doesn't really work with the .cursor/rules/ approach of having several rules files that get included based on matching the descriptions or file globs in frontmatter. Then again, I'm not sure if any other agents support an approach like that, and in my experience Cursor isn't entirely predictable about which rules files it ends up including in the context.

I guess having links to supplementary rules files is an option, but I'm not sure which agents (if any) would work well with that.

Yep, that's a peeve of mine. I've resorted to using AGENT.md, and aliasing Claude, Gemini, etc to a command that calls them with an initial instruction to read that file. But of course they will forget after some time.

The whole agentic coding via CLI experience could be much improved by:

- Making it easy to see what command I last issued, without having to scroll up through reams of output hunting for context - Making it easy to spin up a proper sandbox to run sessions unattended - Etc.

Maybe for code generation, what we actually need is a code generator that is itself deterministic but uses AI, instead of AI that does code generation.

That's a more obvious (but less fun) name than what I've been using: ROBOTS.md with symlinks.

(I work at Cursor) The CLI supports AGENT.md as well as CLAUDE.md and Cursor Rules.

When they stop getting desperate for differentiation by spamming their brand advertising in your repo against your will.

Claude Code likes to add "attribution" in commit messages, which is just pure spam.

Never. It's a marketing strategy. Some percentage of users will check these files into their repos, and some percentage of repo browsers will think "what is this X.md?" Given how much money people are spending on these things the value of having a unique filename must be enormous.

I just wish the AGENTS.md standard wasn't a single file. I have a lot of smaller context documents that aren't applicable to every task, so I like to throw them into a folder (.ai/ or .agents/) and then selectively cat them together or tell the agent to read them.

Agree. It's all English. That's the whole point of these tools.

Why are we purposely creating CLI dialects?

FWIW at least with Claude and Jules on a project I have a decent setup where I put all of the real content in an agents.md and then use “@agents.md” in CLAUDE.md. If all of the tools supported these kinds of context references in markdown it wouldn’t be that hard to have a single source of truth for memory files.

Yeah I suspect some of these providers will become Microsoft in the '90s type bully holdouts on implementing the emerging conventions. But ultimately with CLI interface you have workarounds to all the major providers read in your system guidelines. But in an IDE - e.g. like MS had with VisualStudio - you more lock-in potential for your config files.

Yesterday, I was writing about a way I found to pass the same guideline documents into Claude, Gemini, and Aider CLI-coders: https://github.com/sutt/agro/blob/master/docs/case-studies/a...

I haven't tried it yet myself, but I noticed their product page (https://cursor.com/cli) says:

> Set your own rules: Customize Cursor's work with rules, AGENTS.md, and MCP.

There's no mention of it in the docs, though. It's also interesting it's AGENTS.md on that page instead of AGENT.md, I wonder if that's a typo.

The deeper problem are the custom commands, hooks and subagents. The time has come that you need to make a strategic choice. Once you have heavily invested into CC, it is not easy to turn to an alternative.

Side remark: CC is very expensive when using API billing (compared to e.g. GPT-5). Once a company adopts CC and all developers start to adapt to it at full scale, the bill will go out of the roof.

Symlinks $AGENT.md to AGENT.md in your repo.

For example: i'm using Claude Code mostly + Gemini CLI. Gemini CLI is not such powerful as CC, also it won't work with some mcp's. So i have different *.md files.

Different file names is easy analytics (ex: 'how many OSS projects use gemini.md and claude.md' is a mere search query).

The font on that RFC is aggressively squashed and aliased, why?

Thank you so much for this!

Symlink?

Think how many JavaScript frameworks can be vibe coded now!

This made me chuckle. Excellent comparison. I share your sentiment; it’s more exciting than distracting.

Think how much training has been done on such Javascript frameworks... no one stops wondering what the outcome would be. The only fact that when I ask to create an app, without any further detail about what to use, and it defaults on React, imo it's a total failure whatever the agent

The joke's tired now bro. It hasn't been true for a good 5-7 years now.

IDE UI should shift to focusing on catching agentic problems early and obviously, and providing drop dead simple rollback strategies, parallel survival-of-the-fittest solution generation, etc

I think the complete opposite. I love the ux for claude code, but it would be better if it wasnt locked to a single vendor's model. It seems pretty clear to me that a vendor neutral product with a UX as good as Claude Code would be the clear winner.

I'm actually starting to think the opposite.

If Cursor can build the better UX for all the use-cases, mobile/desktop chatbot, assistant, in IDE coding agent, CLI coding agent, web-based container coding agent, etc.

In theory, they can spend all their resourcing on this, so you could assume they could have those be more polished.

If they win the market-share here, than the models are just commodity, Cursor lets you pick which ever is best at any given time.

In a sense, "users" are going to get locked in on the tooling. They learn the commands, configuration, and so on of Cursor, it's a higher cost for them to re-learn a different UX. Uninstalling and re-installing another app, plugin, etc. is annoying.

Why not? Have you ever actually used these things? The risk is incredibly low. I run claude code with zero permissions every day for hours. Never a problem.

For example, Gemini CLI [1] can use native sandboxing on macOS. It's just a matter of time before every major coding agent will run inside of an operating system's native sandbox/container/jail/VM.

[1]: https://github.com/google-gemini/gemini-cli/blob/main/docs/c...

The permissions is quite well defined, by default it will ask you for your approval before every cli command that it will run

(I work at Cursor) We also support running the agent in a VM at cursor.com/agents

In one of their Claude Code talks they said it didn’t seem worth it, given their expectation that all IDEs will become obsolete by next year.

If I'm not mistaken, it may be feasible to build one with the Claude Code sdk

Isn't that Claude Desktop?

People have preferred either the terminal or chunky IDEs for decades. Neither are wrong.

I like that I can use the ide while a cli is working, keep an eye on git changes and interrupt where needed.

I find in ide they like opening documents/changing tabs too much and it means j can't do other things.

i’d respectfully bet against this.

cursor and 3rd party tools will, unless they make their own superior foundation model, will always have to fight the higher marginal cost battle. This is particularly bad insofar that they offer fixed pricing subscriptions. That means they’re going to have to employ more context saving tricks which are at odds with better performance.

If the cost economics result in Cursor holding, say, 20% fewer tokens in context versus model-provider coding agents, they will necessarily get worse performance, all things equal.

Unless Cursor offers something dramatically different outside of the basic agentic coding stack it’s hard to see why the market will converge to cursor.

> we should always promote low switching costs between model providers (by supporting independent companies), keeping incentives toward improving the models not ui/data/network lock-in

You’re underestimating the dollars at play here. With cursor routing all your tokens, they will become a foundation model play sooner than you may think

Happy to short that bet as I think agentic harnesses will be molded along the RL training of the actual model. Tony + the suit created together. Why Claude in Claude Code became existential for Cursor, why cursor moved quick to go agentic and build up with OpenAI in big header line way here.

Unless they pair up with OpenAI or Meta.

Flip your thinking around for a second and consider why an IDE is required for an agent that codes for you?

The IDE/editor is for me, the agent doesn't need it. That also means I am not forced to used whatever imperfect forked IDE the agent is implemented against.

Many of these companies are realizing that mainline VSCode is a moat of sorts. I and many people I know won't use any of these that require forking VSCode.

With the benefit that you can also pull in people who don't like using VSCode such as people who use Jetbrains or terminal based code editors.

Actually, I think where Claude Code shines, is with the VSCode Extension. It's a great mix between a CLI that could be used in a bash script for automation, as well as a coding assistant.

I haven't found however if Cursor cli provides this kind of extension

You can already have that with Jules. It's quite impressive.

https://jules.google/

I noticed it was taking awhile on the first large-ish task I gave it. I'm assuming it was just a bit overloaded at the moment.

Shell commands and files on disk are the classic narrow waist, and this type of tool, exemplified by Claude Code, locates a coding agent down in that ecosystem.

Why shouldn't you be able to use the abilities of this tool as a batch command, connected with all your other basic tools, in addition to interactive sessions?

Cursor's chat being locked in an IDE sidebar has felt like driving with a trailer attached. For some tasks the editor is secondary or unnecessary, and as a papered-over VS Code fork, Cursor has a lot of warts that you just had to accept. Now you can just use your favorite editor.

Companies make apps but want to be platforms, so they try to put everything in one app and help you forget about everything else. VS Code and Figma, for example, make their own extension ecosystems rather than connecting outward, because it makes them platforms-as-apps and harder to leave. But a desktop task workflow spans many apps and windows. You compose it yourself to your needs. We are computer users more than app users.

To me as a computer user, a tool that's compact and has compatible outward extension points feels good.

Because you can script terminal app (ideally, at least you can do that with opencode.ai) and that opens some amazing opportunities.

Cursor minus CLI is already that.

Interesting, are you saying you would setup a Stop Hook in Claude Code that calls the Cursor CLI to have it validate and prompt Claude Code with further instructions?

Claude Code can use GPT-5 via LiteLLM

https://docs.anthropic.com/en/docs/claude-code/llm-gateway#l...

https://docs.litellm.ai/docs/tutorials/claude_responses_api

and access to Cursor's background agent on the web as well, like ChatGPT Codex. So to this point, I'm regret cancelling my Cursor subscription already

I would highly doubt it. Even when you BYOK inside of Cursor they still say it's routed through their servers.

We (Codex) shipped a pretty large CLI update today and have many more improvements coming. Give it a try if you haven't.

https://x.com/OpenAIDevs/status/1953559797883891735 (0.19 now)

My company has a huge codebase, for me cursor would freeze up / not find relevant files. Claude code seems able to find the right files by itself.

I seem to always have better outcomes with Claude code.

Because iterating multiple sessions through multiple terminals is obviously more efficient and seamless than interacting thought a scuffed IDE side panel ui.

Claude Code has some non-LLM magic in it that just makes it better for code in general, despite (or because of) having minimal IDE integration.

What I have found Claude Code is extremely good at is that it makes one change at a time, gives you a chance to read the code its changing, and lets you give feedback in real time and steer it properly. I find the mental load with this method to be MUCH lower than Cursor or any of the other tools which give you two very different options: "Ask" mode which dumps a ton of suggestions on your and then requires semi-manual implementation, or "Agent" mode which dumps a ton of actual changes on you and requires your inspection and feedback and roll-backs, etc.

This may not work for everyone, but as a solo dev who wants to keep a real mental model of my work (and not let it get polluted with AI slop), the Claude Code approach just works really well for me. It's like having a coding partner who can iterate and change direction as you talk, not a junior dev who dumps a pile of code on your plate without discussion.

In my experience, it is much better at tool-calling, which is huge when we're talking about agentic coding. It also seems to do a better job of keeping things cleaning and not going off on tangents for anything that isn't accomplished in one shot.

CC just feeds the whole codebase and entire files into the model, no RAG, nothing in the way. It works substantially better because of that, but it's $expensive$.