Tamarillo — AI Coding Harness Adoption

tamarillo — coding harness inspection

• filter criteria: PATTERNS per harness were defined (explained in detail in appendix A)
• repo search: Code searches on GitHub's REST API filtered against harness configuration files
• enriching stage: GitHub's GraphQL API was used to enrich files with commit count, file bytes, creation date, etc.

At the time of writing, the C4H (Claude Code, Codex, Copilot, Cursor, Hermes) dominates ~80% of the public repositories that expose harness configurations. This is the Pareto principle in action — an expected outcome given that power laws are usually at play in software and software tools. From ~20 harnesses, 5 dominate.

C4H domination

Throughout the years and months, the landscape changed. At the beginning the market share was pretty much dominated by Cursor. It is no surprise to confirm that, as well as the rise of Claude Code and shortly after Codex and Hermes. Below, two charts measure the following signals: recent adoption dynamics, and the current state of market share^[†].

• Rolling market share chart, showing the signal of recent adoption. That is, popularity calculated as the share for new repositories created in an x-day window, filtered by the date each harness config format became publicly available.
• Evolution of market share in absolute terms over the past ~2 years.

As stated above, the evolution of market share in absolute terms over the past ~2 years filters by release date without including the retroactive configured repos. The results displayed below are the cumulative share for each harness present in the selected group.

The cumulative adoption over time, filtered by harness release date, shows that:

• All growth shows exponential behavior.
• Harnesses experience rate discontinuity, e.g. Cursor ~2025-07, Copilot ~2025-11 (i.e. subtle change, but noticeable with eyesight on the rate of growth, the cause is up for elucubration)
• Even though harnesses like Claude Code or Codex were released later, they already caught up in terms of repo footprint.^[†].

Codex & Claude Code

• WIRED reports "5 percent as much use" (Sep 2025) and "40 percent of Claude Code's user base" (Jan 2026), attributed to "people with direct knowledge of the matter" — anonymous internal sources, no methodology disclosed. This chart counts public repos with a config file committed.
• Configs MAY be committed weeks or months after the user actually adopted the tool.

If each repo independently decides to adopt one more harness with constant probability , the count at follows a geometric distribution: . It MAY be a bit of a stretch, but there is no resistance to the temptation of fitting a line on a vs chart and interpreting what that constant probability means. is indexed over the count of co-occurrences of harness configurations in repos, so is the probability of adopting harness after already having . Note that it does not matter which harness is adopted (e.g. maybe it is always Claude Code because it is popular), what matters is that there is a new one. The decision to add harness does not depend on how many are already configured. The regression was done for harness counts because above that the counts drop to single digits. is obtained via OLS on . The 95% CI uses the textbook normal-theory slope CI and is then pushed through . The regression on is heteroscedastic (small counts are noisier), so the reported CI is slightly optimistic. A Poisson GLM fitting is the correct way of doing things. ^[†] [†] If only 2 harness are selected the linear regression will be evidently perfect.

Configuration surface anatomy

• system_prompt: CLAUDE.md, .cursorrules, copilot-instructions.md, HERMES.md, SOUL.md, AGENTS.md. One per repo, usually at root.
• rule: scoped rule files that apply only to specific paths or file globs: .cursor/rules/*.mdc, .github/instructions/*.instructions.md.
• agent: sub-agent: .claude/agents/*.md, .codex/agents/*.toml.
• skill: files following the Agent Skills standard: SKILL.md inside a skills/ directory.
• prompt: reusable prompt snippets / templates: .github/prompts/*.prompt.md, .continue/prompts/, .pi/prompts/.
• workflow: multi-step recipes the agent can execute: .windsurf/workflows/*.md, .clinerules/workflows/*.md.
• tool_mcp: Model Context Protocol server configs: .mcp.json, .vscode/mcp.json, .cursor/mcp.json, .codex/mcp.json.
• hook: lifecycle event handlers: .cursor/hooks.json, .windsurf/hooks.json, .github/hooks/*.json, .codex/hooks.json.
• plugin: packaged extensions: .claude-plugin/plugin.json, .cursor-plugin/plugin.json, .opencode/plugins/.
• ignore: files telling the agent what to skip: .aiderignore, .cursorignore, .codeiumignore.
• settings: everything else that configures behavior: config.yaml, settings.json, MEMORY.md, USER.md, model selection, etc.
• legacy: older command-style files that have largely been superseded by skills/agents: .claude/commands/*.md, .opencode/commands/*.md.

Surface decomposition per harness

File size distribution by surface

Surface:

[†] Two things explain why a harness MAY be empty for some surface.

• not every surface is available for every harness
• some harnesses dump everything into one file instead of separate ones

Total config bytes per repo — how heavy is the harness setup?

Top 25 repos by config-file count

harness agnostic power-law in config byte footprint

Config churn — write-once or iterate?

• Claude Code in comparison has high iteration of its system prompt in comparison to other harnesses
• Rule and Skill config churn is qualitatively consistent amongst harnesses
• Most configuration files are commited and never changed (i.e. 1 commit). This MAY speak to the relaxed and toy project nature of many of the repos that were fetched.

Surface:

system_promptruleagentskilltool_mcpsettings

Popularity vs stars

• Star CCDF per harness against the all-adopters baseline.
• Adoption rate across star buckets. inversing the condition: given the repo bucket (0 stars, 1–9, …, 10k+), what is the probability each harness is configured.

Star CCDF per harness

Star percentiles per harness

6 Star buckets categories were created to analyze the prevalence of harnesses. The categories are groups of OOM ranges. The adoption share shows a skew for Codex towards high-star repos. This was already visible in the CCDF slower death for Codex in particular. The reasons for said skew goes beyond the scope of this analysis but are definitely a trigger for future research.

Language and organizational signal

User vs organization differential

• raw adoption rate for each owner type,
• the log-ratio ^[†] to see the skew.

Language analysis

• Language rarity per harness. For the chosen language, to measure degree of indexation into a specific language.
• Language mix per harness. Dodged bars showing across the top languages.

Language:

Repo vitality & evolution

Is the repo still alive?

Methodology & limitations

How the dataset was assembled

• The first stage is pattern definition: for every harness in scope, a set of non exhaustive filename and path patterns are written. The full pattern list per harness is in appendix A.
• The second stage is repo search. Each pattern is fired against GitHub /search/code. GitHub caps any single query at 1000 results, queries were therefore adapted to be size-sharded by file byteSize until every shard returns under that cap. The output is one row per matched (repo, file) pair carrying full name, harness, label, path, and the blob SHA.
• The third stage is a two-phase GraphQL enrichment.
  • Repository query per repo to pull stars, forks, primary language, owner type (User or Organization), createdAt, pushedAt, default-branch commit total, topics and license.
  • Queries each file individually for Blob.byteSize plus the most recent commit, yielding per-file size, last_commit_date, and commit_count.

Time anchoring

Limitations

• Public repositories only. Private repos, enterprise installations, and home-directory configuration (~/.cursor/, ~/.claude/, ~/.codex/) are out of reach. Every curve is a lower bound on real adoption.
• Configuration intent is not active use. A repo with .cursorrules proves that someone set Cursor up at least once. Whether the harness is still being used daily is not observable from the file's existence.
• Pattern coverage is non-exhaustive. Each harness is covered by 2–11 patterns targeting known paths. Anything stored outside the repo tree, IDE-managed state, or runtime-generated artifacts is missed. Harnesses whose configuration surface lives primarily outside the repo (e.g. settings that only exist in the home directory) are systematically under-counted.
• Filename-only matching. Patterns match on path and filename, not content. filename:MEMORY.md matches a Hermes memory store and an unrelated MEMORY.md in some other repo equally; harness attribution is pattern matched, not verified through reading and analyzing content.
• Cross-tool attribution is a convention. The six shared files listed above are each credited to a single canonical owner. When several harnesses in the same repo would read the same file, only the canonical owner gets the count.
• Forks and templates are excluded at the source. A negligible (<0.1%) slice of the originally fetched repositories was filtered out before any aggregation.

Appendix A: search patterns per harness