Over the last year we measured the race between coding agents almost exclusively with one question:
Which model is better?
Then the benchmarks arrived.
Then price comparisons.
Later we started looking at speed, context, tool use, and the ability to solve real tasks.
Now another metric appeared.
And, curiously, it might be one of the most interesting so far.
A recent analysis of public repositories shows that Codex CLI appears referenced in more repositories than Claude Code. Behind it are Copilot Agent, Gemini CLI, and Cursor.
The immediate reaction is obvious:
“So Codex won.”
But that conclusion is probably wrong.
Because this metric isn’t measuring the best agent.
It’s measuring something much more subtle.
Visibility is not the same as usage
First, it’s worth understanding what “appearing in a repository” really means.
It doesn’t necessarily mean a developer uses Codex every day.
What it means is that, somehow, Codex got recorded within the project.
It can be through:
AGENTS.md- scripts
- workflows
- documentation
- configurations
- examples
- bootstrap files
In other words, it leaves public evidence.
And that’s very different from measuring active users.
Claude Code, for example, might have massive usage in private projects that never publish their configuration.
OpenCode might live completely outside the repository.
Cursor might be used every day without leaving practically any trace.
The metric measures observable presence.
Not invisible usage.
And both tell different stories.
Codex has a natural advantage
There’s another detail.
OpenAI has been pushing Codex as part of a much broader ecosystem.
ChatGPT.
The API.
The CLI.
Integrations.
Documentation.
Official examples.
When thousands of developers copy examples directly from the documentation, those files end up on GitHub.
That hugely increases public visibility.
Not necessarily intensive usage.
But it does increase the observable surface.
Claude Code plays a different game
Claude Code, on the other hand, seems to have evolved toward a different kind of adoption.
Its community invests a lot of time building:
- Skills.
- Hooks.
- Plugins.
- MCP.
- Subagents.
- Workflows.
- Memory.
Much of that value lives outside the public repository.
Or within private infrastructure of teams.
That means comparing only “number of repositories” probably underestimates an important part of its ecosystem.
It’s like measuring Kubernetes by counting only public YAML files.
You’d get a useful signal.
But an incomplete one.
The truly interesting data point
What really matters isn’t who’s first.
It’s that for the first time we’re starting to have metrics beyond benchmarks.
For a long time the conversation was:
- SWE-bench
- HumanEval
- LiveCodeBench
All trying to answer one question:
“Which model programs better?”
Now new questions appear.
How many projects adopt it?
How much code persists?
How much does it cost to operate?
How many workflows depend on it?
How many plugins exist?
How many skills does the community share?
How many MCP Servers does it support?
We’re starting to measure ecosystems.
Not just models.
The new competition
That completely changes how we read the market.
Because a successful agent needs much more than a good LLM.
It needs:
- tools,
- memory,
- observability,
- documentation,
- community,
- examples,
- integrations,
- extensions.
It’s exactly what happened with IDEs.
Visual Studio Code didn’t win just because it edited text better.
It won because it built the strongest ecosystem.
Coding agents seem to be heading toward the same destination.
What should an Engineering Manager look at?
If your team evaluates an agent tomorrow, it probably makes sense to look at much more than benchmarks.
Questions like these are starting to be equally important:
- How easy is it to integrate?
- What community does it have?
- How many examples exist?
- Are there reusable Skills?
- Are there mature MCP servers?
- How portable is the workflow?
- How easy will it be to switch models in a year?
The last question is probably the most important of all.
Because models change.
The harness persists.
The metric still missing
There’s one statistic nobody publishes consistently yet.
And it’s probably the most valuable.
Not how many repositories mention an agent.
But:
How many real engineering hours does it produce?
Because an agent installed isn’t necessarily an agent used.
And an agent used doesn’t necessarily generate value.
Eventually we’ll start measuring:
- tasks completed,
- time saved,
- cost per workflow,
- percentage of code accepted,
- rework,
- developer satisfaction.
That day the conversation will change again.
The market starts maturing
What’s interesting about this ranking isn’t that Codex appears first.
It’s that for the first time, the discussion is starting to move beyond benchmarks.
We’re entering a stage where the ecosystem matters as much as the model.
Where adoption metrics start coexisting with performance metrics.
And where the question stops being:
“Which agent writes better code?”
To transform into something much more useful:
“Which agent becomes a permanent part of the engineering stack?”
That’s probably the competition that will really define the coming years.
By Grego — yoDEV
codex claudecode aiagents developertools #PlatformEngineering aiengineering #EngineeringManagement llmops #SoftwareEngineering opensource