On March 19, 2026, Cursor announced version 2 of their Composer coding model. The announcement post (linked here) boasts of "frontier-level coding intelligence" and an "optimal combination of intelligence and cost." And right at the top, there's this chart:
I wouldn't have published that as a final draft. This post is about why, and what I'd do instead.
Problems
Cost decreases from left to right, meaning cheaper is to the right. This cuts against a well-studied convention called the SNARC effect: in Western reading culture, smaller numbers belong on the left. The inversion seems intentional, pushing the "ideal zone" into the upper-right corner where readers expect to find it. But that trick only works if readers don't notice the axis is flipped. Many will.
Series labels are vague and unexplained. Opus and GPT-5.4 are each split into "high," "medium," and "low" points. If you've used these models via API, you probably recognize these as effort parameters. If you mostly use them through a chat UI, you're left guessing.
The Opus and GPT-5.4 effort levels are connected by lines; the Composer points aren't. The implied message is that Cursor's models don't degrade as you dial down cost. It's a real point worth making, but it's buried in a design choice that most readers won't decode on their own.
Color choices are all over the place. Opus is rendered in a muted brown for no clear reason. Composer 2 is brighter than Composer 1.5, apparently just for emphasis. And almost nothing passes WCAG 2.1 AA contrast requirements; Composer 2's orange is the only exception.
The bigger issue is that there are too many stories. The connected lines tell one story (how score changes across effort settings), the standalone points tell another (absolute cost vs. absolute score). My rule for static charts: one story per graph. If you need to tell multiple stories in a small space, build an interactive dashboard instead.
Solutions
The chart's best argument is simple: Composer 2 gives you the most performance per dollar. Everything should serve that point.
With that as a guide, I'd flip the x-axis so $0 is on the left, drop Composer 1.5 and the medium/low effort points for Opus and GPT-5.4, use a visual cue to mark the ideal zone explicitly, move the effort parameter explanation to a footnote, and audit every color against WCAG 2.1 - checking both text contrast and colorblind-safe encoding using different marker shapes, not just different hues.
I estimated the original coordinates, pulled the data into a Python environment (uv, marimo, polars), and built the new chart in matplotlib. I'd normally prefer something more declarative, but nothing in the Python ecosystem matches matplotlib's design control when you need it.
I stuck with a scatterplot rather than a cost-score ratio bar chart. The bar chart is simpler to read, but collapsing two dimensions into one ratio tosses too much information.
Here's what I came up with:
| Model | Cost | Score |
|---|---|---|
| Opus 4.6* | $2.50 | 57.5% |
| GPT-5.4* | $1.60 | 63.0% |
| Composer 2 | $0.20 | 60.0% |
*Benchmarks run with effort parameter set to "high"
I removed all plot borders except the left one, which signals that the axes extend beyond the frame. Green communicates both "good" and "money," which is why I chose it for the gradient and its label. Gridlines now meet WCAG 2.1 standards for UI elements.
On accessibility: contrast compliance is about readability as much as it's about inclusivity. A chart needs to work on a dimmed screen or in a printed grayscale report. If it fails there, the data story fails too.
This version doesn't show how Composer has evolved across model generations relative to competitors. That's a different story, and it deserves its own chart. Less is more here.
Lessons Learned
Pick one story before you touch the design. Try using subtraction to clarify static charts. At every step, ask whether an element supports the message or just adds style. And check your contrast ratios every time, not as an afterthought.