Deep Dive: Graders, Rewards & Evals

RL is only as good as the number you put on the right-hand side. For coding agents, that number is the hard part - most of what makes an edit good cannot be checked by running it.

The clean story for RL on code is RLVR - reinforcement learning from verifiable rewards. You hand the agent a task with a test suite, it writes code, you run the tests and the pass/fail is your reward. It is honest, cheap to compute and impossible to argue with. Cursor's job posting names the opposite problem as a core charter: training graders to improve performance on coding tasks with non-verifiable reward. That sentence is the whole module.

A test answers one question: does this code do the thing the test author imagined. It says nothing about the four things a developer actually feels when an agent edits their repo.

What a grader actually isthe function that returns reward

A grader is the thing that turns an agent's trajectory into a scalar reward when no test can. It might be an LLM reading a diff against a rubric, a learned reward model trained on human preferences, an execution harness handing out partial credit or a blend. Whatever its form, it sits in the exact spot where the test used to be.

This reframes the whole role. The interesting research is not a clever loss function. It is building a reward signal for a fuzzy human judgment, at a scale and reliability that survives millions of rollouts, on tasks where the ground truth is contested.

There is no single right grader. There is a menu of signals, each accurate in a different regime and the craft is choosing and combining them under a real throughput budget.

If asked to design a grader on a whiteboard, name the options before you pick. Each has a distinct failure mode and the strongest answers fuse two or three rather than betting on one.

Calibration: does the grader rank truth above plausibilitythe only question that matters

A grader is useless if it can't rank a correct solution above a plausible-but-wrong one. That is the property you measure and it is measurable.

1. 1Assemble gold pairs. Collect tasks where you trust the labels - known-correct solutions and known-bad ones, including subtle wrong answers, not just obvious garbage.
2. 2Score agreement. Run the grader and measure how often it ranks the good solution above the bad one. Report pairwise accuracy or correlation with the human label, not just average score.
3. 3Slice the failures. Where the grader disagrees with humans, look at the cases - verbose-but-wrong, terse-but-right, correct-but-unconventional. The pattern of disagreement is the grader's bias.
4. 4Recalibrate. Tighten the rubric, add negative examples to the RM training set or change the gate threshold, then re-measure on a held-out slice.

Cost versus fidelity is a live tradeoff

Every rollout calls the grader, so the grader's cost multiplies across the whole training run. A large-model judge that scores beautifully may be too slow to run on every sample, starving the policy of gradient. A cheap heuristic runs fast but rewards the wrong thing.

Every reward you ship will be optimized against. The policy doesn't want to write good code - it wants reward and it will take the cheapest path to it that your grader allows.

Goodhart's law: when a measure becomes a target, it stops being a good measure. Your grader is a proxy for "good code." The moment you optimize against it, the agent starts widening the gap between the proxy and the thing you actually wanted. This isn't a bug in a specific grader; it is the default behavior of optimization.

How agents actually hack coding rewardsreal failure modes, not hypotheticals

The tell is a metric that climbs while the thing it's supposed to represent doesn't. Reward goes up, your held-out eval and your spot-checks stay flat or get worse. That divergence is the signature of a hack.

Mitigations that actually hold

An eval you can't trust is worse than no eval, because it makes you confidently wrong. The whole game is building measurements whose movement you'd bet a model release on.

Start by knowing the landscape so you can speak to it. Public benchmarks tell the interviewer you read the field; internal evals tell them you understand why public ones aren't enough.

Contamination: the benchmark is in the training datathe credibility killer

Public benchmarks leak. The GitHub issues behind SWE-bench, the HumanEval prompts, the Stack Overflow answers - they're in the pretraining corpus. A model can score high by having memorized the fix, not by being able to solve the task. A benchmark gain on contaminated data measures recall, not capability.

• Prefer private, freshly-authored eval tasks the model could not have seen - newer than the training cutoff or written internally.
• Distribution-match the eval to what Cursor users actually ask, not to whatever benchmark is convenient to score.
• Run contamination checks: look for verbatim recall, test whether perturbing the problem tanks the score.
• Refresh evals over time - a private eval becomes a contaminated one once it's been trained on for a few cycles.

Variance and significance

Agent evals are noisy. Sampling temperature, tool-call ordering and flaky environments mean two runs of the same model disagree. A single run that's 2 points higher tells you nothing.

# Bad: one run, no error bars
score = run_eval(model)            # 47.3% - looks like a win vs 45.1%?

# Better: many seeds/tasks, with a confidence interval
scores = [run_eval(model, seed=s) for s in range(N_SEEDS)]
mean, ci = bootstrap_ci(scores)    # 46.1% ± 2.4%  -> the "win" is in the noise

# Decide with a test, not a vibe
significant = paired_test(baseline_scores, new_scores).p < 0.05

The offline–online gap

The deepest eval problem is that the benchmark and the product can disagree. A model can climb your offline eval and not move a single shipped metric - or get worse for users while the benchmark says it improved. Cursor's whole premise is that research is judged by production impact, not by the offline number.

The grader scores the answer, but the datapoint sets the question. A model trained on the wrong tasks learns the wrong things efficiently - and Cursor explicitly hires for improving datapoint quality and difficulty.

Three properties make a training datapoint worth its compute. They pull against each other, which is why "more data" is rarely the answer and curation is the actual job.

Difficulty: train at the edgewhere the gradient lives

In RL the signal comes from the spread between good and bad rollouts. A task the model always passes or always fails gives no contrast and no learning. The useful datapoint is the one the model gets right sometimes - that's where advantage estimation has something to work with.

Distribution-matching and synthetic data

The easiest data to get - scraped repos, leetcode-style problems, tasks with clean tests - is not the data that matches a real Cursor session. Real requests are multi-file, underspecified, full of project-specific conventions and often have no tests. Closing that gap is its own research problem.

1. 1Profile the real distribution. Characterize what users actually ask - task types, repo sizes, languages, how much context, how multi-file - so you know what you're matching.
2. 2Generate to fill gaps. Synthesize tasks where real data is thin, using past models to draft problems and candidate solutions in the under-covered regions.
3. 3Verify before you trust. Filter synthetic datapoints through execution checks and graders; a synthetic task with a wrong "gold" answer poisons training.
4. 4Calibrate and recycle. Bin by measured difficulty, prune the trivial and the impossible and bootstrap the next round of harder data from the model you just trained.

The public benchmarks in the last section are a sanity floor, not the thing a Cursor release turns on. CursorBenchCursor's internal benchmark that scores models on both task performance and token efficiency, not accuracy alone. is the in-house answer to every limit those benchmarks have - and the way it scores reflects the non-verifiable-reward problem this whole module started from.

CursorBenchCursor's internal benchmark that scores models on both task performance and token efficiency, not accuracy alone. is Cursor's internal eval, built to be realistic and uncontaminated. Its tasks are drawn from real engineer queries - the actual requests Cursor's own engineers make of the agent - rather than scraped GitHub issues or leetcode prompts. Because the tasks are private and freshly sourced, a model can't have memorized the fix from pretraining, so a gain on CursorBench is closer to capability than recall.

Short, under-specified prompts on purposeresolving ambiguity is the task

The prompts in CursorBenchCursor's internal benchmark that scores models on both task performance and token efficiency, not accuracy alone. are deliberately short and under-specified. A real developer rarely writes a spec; they type a terse request and expect the agent to figure out what they meant. CursorBench keeps that shape on purpose, so resolving the ambiguity and inferring intent is part of what's being scored, not a detail abstracted away.

CursorBenchCursor's internal benchmark that scores models on both task performance and token efficiency, not accuracy alone. scores two things at once: the quality of the solution and the mean completion-token length the agent used to get there. Quality alone would let a model ramble its way to a correct answer; pairing it with length makes brevity part of what "good" means, so a solution that's right and tight beats one that's right and bloated.

Because it scores quality plus brevity on under-specified, uncontaminated tasks, CursorBenchCursor's internal benchmark that scores models on both task performance and token efficiency, not accuracy alone. separates strong from weaker models more than SWE-bench does. SWE-bench is saturating - the best models cluster near the top, so a few points of movement is hard to read. CursorBench keeps the field spread out, which is what makes its deltas worth deciding a release on.

Reward shaping: a nonlinear length penaltypunish too verbose and too terse

Scoring length on the benchmark is one thing; shaping it into the training reward is another. Cursor adds a nonlinear length penaltyA training reward that discourages a model from being too verbose or too terse, so easy tasks finish fast and hard tasks get more room. to the reward so the policy is pushed toward the right amount of output - not the most and not the least.

A naive linear "shorter is better" penalty backfires: the policy learns to truncate, dropping necessary edits or explanation to chase the reward. The nonlinear shape fixes this by penalizing both ends. Going too verbose costs reward, and so does going too terse, so the optimum sits in a band rather than at zero tokens.