Cursor Boost
The 25% (default) multiplier applied to a developer’s Cursor adoption score before it layers into the headline Agent Adoption Score.
- Family
- Adoption & Agentic
At a glance
GitKraken Insights treats Claude Code and Codex as “primary” AI tools and Cursor as a “secondary” one. Primary tools have their events unioned at the factor level into one combined score. Cursor is scored independently and added to that primary score at a discount — the Cursor Boost rate — before the final score is capped at 100. The default discount is 25%, configurable via an environment variable.
This page exists so admins understand why a developer’s Cursor activity contributes meaningfully to their Adoption Score but doesn’t dominate it.
Formula
Final Adoption (pre-maturity) = min(Primary + secondaryBoost × Cursor, 100) Primary = blend(Claude ∪ Codex) Cursor = blend(Cursor events alone) secondaryBoost = 0.25 (default)
If Cursor data is absent (nil), the boost term is dropped entirely — no Cursor activity, no boost.
How GitKraken Insights calculates it
Per-provider scoring for Cursor runs the same four-factor blend (Daily Use, Hourly Spread, Prompts, Output) used for Claude and Codex — see Agent Adoption Score for the mechanics.
The resulting Cursor score (0–100) is multiplied by the
secondaryBoostrate (default 0.25 = 25%). So a developer at Cursor=80 contributes 80 × 0.25 = 20 points of additional adoption.The boosted value is added to the Primary score (Claude ∪ Codex) and the sum is capped at 100 before Maturity Factor scaling.
Edge case: primary is zero. If a developer has no Claude/Codex activity but has Cursor activity, they still get the Cursor boost as their entire pre-maturity score. So a dev with Primary=0, Cursor=80 gets 0 + 20 = 20 pre-maturity, which becomes 15 at the default Maturity Factor of 0.75. They land in Emerging but at the high end — visible as “trying Cursor only.”
Why the asymmetric treatment
Claude Code and Codex export OpenTelemetry traces with detailed prompt/response/token/tool data. Cursor’s API exports a less complete event stream — fewer fields, sparser timing, no token counts in some cases. We use Cursor data as confirmatory signal rather than primary evidence:
- If a developer is using Cursor consistently, we want their Adoption Score to reflect that.
- But we don’t trust Cursor data enough to make it a 1:1 substitute for Claude / Codex.
The 25% boost rate is the empirical middle ground — high enough that Cursor power-users score meaningfully, low enough that incomplete data doesn’t mask gaps in primary-tool adoption.
How to read it
You don’t typically read the Cursor Boost in isolation. What you read is the breakdown on a developer’s expanded detail panel:
- A developer with Claude=70, Cursor=80 has Primary=70 + boost=20 → pre-maturity 90 (capped at 100), final 67.5 at MF=0.75.
- A developer with Claude=70, no Cursor data has Primary=70, no boost → pre-maturity 70, final 52.5.
The difference (15 points) is what Cursor adoption is contributing in that developer’s case.
Settings that affect it
SCORE_SECONDARY_BOOSTenvironment variable. Default 0.25. Range 0.0 to 1.0+. Changing it requires a backend restart.
The Cursor Boost rate is not currently exposed in the Settings UI. Ask your account manager if you need it tunable.
How to use it
Cases where you might want to change the boost rate:
- You’ve standardized on Cursor as a primary tool. If your org has gone “Cursor-first” rather than “Claude-first,” consider raising the boost to 0.5 or higher so Cursor adoption contributes proportionally.
- You want Cursor to count equally with Claude / Codex. Set the boost to 1.0. Now a Cursor-only developer can score the same as a Claude-only developer.
- You want to phase Cursor out. Set the boost to 0. Cursor data is ignored in adoption math (it still appears in /data and other detail views).
In most orgs, the default 0.25 is the right answer. Touch it only when your provider mix has genuinely shifted.
Limitations and gotchas
- No agentic score from Cursor. Cursor’s events don’t expose tool-call data in a way we can score for the Agent Autonomy Score. So a developer doing all their autonomous AI work in Cursor will look low-Autonomy in the dashboard regardless of their actual practice.
- Boost is additive, not blended. We don’t union Cursor events with Claude/Codex at the factor level (the way we do for Claude+Codex). Cursor is scored separately and then layered on.
- Pre-cap addition. Because we cap at 100 after the boost is added, a developer at Primary=95 + Cursor=80 caps at 100 — the last 15 points of potential Cursor contribution are wasted.
FAQ
Why isn’t Cursor unioned with Claude / Codex?
Their event streams aren’t comparable enough at the field level. We’d need consistent prompt counts, token counts, and tool counts across all three providers to union them; Cursor doesn’t currently export that consistently. As Cursor’s API matures, this could change.
A developer uses Cursor exclusively and shows score 15. Is that right?
At default settings, yes. Cursor=80 × 0.25 boost × 0.75 Maturity Factor = 15. If your org is Cursor-first, raise SCORE_SECONDARY_BOOST to 0.75 or 1.0 to give Cursor users a fair share of the score.
Why default 25% and not 50%?
Empirically, the data we get from Cursor today is roughly a quarter as rich as what we get from Claude / Codex OTEL traces. 25% reflects “Cursor counts about as much as the data we have on it.” If Cursor’s event coverage improves, we’d raise the default.
Related metrics
| Metric | Relationship |
|---|---|
| Agent Adoption Score | Cursor Boost is one of two terms in the Adoption Score formula. |
| AI Tier | Indirectly — Cursor adoption shows up here via Adoption Score. |
Where it appears
/developersexpanded panel breaks down “Claude contribution” / “Codex contribution” / “Cursor contribution” so you can see what each tool is doing for a developer’s score.- Behind the scenes in every Adoption Score on the dashboard.