Re-measure one fixed task before you trust a harness savings claim

After a coding-agent harness change ships, a SaaS team should re-measure one fixed task before it books a vendor percentage as its own bill. Keep a short standing file in the repo. Load each skill only when that task needs it. Run the same prompt on the same commit twice, once before the file change and once after, and keep a savings line only when the task still finishes.

On 23 September 2026, Jediah Katz, Connor O'Keefe, and Calvin Yee published Cursor's account of harness work that reduced token costs for Cursor's users by 7% without reducing agent quality. That 7% is their result on their traffic. Your invoice moves when the same task, on your repo, uses fewer tokens and still finishes.

What Cursor changed in the harnessCopy Anchor Link

Agents now run longer and carry context from step to step. Each turn resends tools, system instructions, setup, and the conversation, with a stable opening and a growing end. Cursor's production view splits spend into output, uncached input, and cached input. System and tool definitions in that view include compaction summaries. User text includes skills attached by hand. Skills and plugins include skill descriptions, MCP tool descriptions, and rules that sit in static context.

Cursor controls the system prompt on every turn. As models improved, long lists of "do not," "you must," and "important" gave way to a shorter description of how a tool behaves. Cursor trimmed roughly 66% of that system prompt, across model families. They still add and remove lines when a new model needs guidance. They judge those edits with A/B tests on a large user base, because evals often represent hard problems and miss the true mix of requests.

Tool definitions grew with background shell monitoring, cloud subagents, and more reliable web access. Most of those tools matter, and each is needed in fewer than 20% of conversations. Cursor had moved MCP tools into dynamic context earlier, which reduced total tokens by 46.9% on sessions that called an MCP tool. They applied the same pattern to built-in tools and A/B tested which ones stay visible from the first turn, watching tokens, cost, latency, tool-call errors, and agent usage. Reading, searching, editing, and the shell stayed in static context, along with ask_question, because some models invented calls to it, and flow tools such as create_plan in Plan Mode. The rest load when the agent needs them. That offload cut static-context description tokens by 60%.

They then placed cache breakpoints after the stable layers and before the growing conversation. Before GPT-5.6 the cache boundary followed the latest request. Since GPT-5.6 the OpenAI API accepts explicit breakpoints beside its implicit cache. Cursor kept rarely changing tools and system instructions in front of that boundary, and moved skills, subagents, and environment info into a "phantom user message." Those cache changes reduced the rate of cold cache misses by 20%.

The Read tool now numbers every tenth line. One line number uses around three to five tokens, and numbering every tenth line reduced cache-read tokens by 1.6% with no reduction in quality. Cursor also dropped instructions that strongly pushed subagents for codebase exploration, and a subagent switches model only when the user or the harness directs it. Those edits stay in their harness.

Why the 7% stays on their trafficCopy Anchor Link

The 7% is the combined result on Cursor's users, with no reduction in agent quality. The inner figures use other denominators. The 66% is Cursor's system prompt. The 60% is static tool-description tokens after the built-in-tool offload. The 20% is the rate of cold cache misses. The 46.9% is total tokens on sessions that called an MCP tool. The 1.6% is cache-read tokens from the Read tool's line numbers. Keep each figure on its denominator. Your figure is the gap between two finished runs of one task you already ship.

Evals on Cursor's side often represent hard problems and miss everyday requests. A one-off hard task has the same limit, so pick a task from a normal week. Hold the model fixed. Model choice is a separate decision, in how to route a coding agent across models. Hold the effort setting fixed too, as in the effort knob on a coding agent. When the model, the effort setting, or the commit changes between runs, label the pair mixed and rerun with those three held still.

Keep a short standing fileCopy Anchor Link

A long standing file rides along on tasks that never use most of it. Keep that file short. Put each skill in its own file and read it only for the matching task. Cursor put skills in the phantom user message so variable setup sat past the cache boundary. The block below is a team file shape. Cursor left the repo layout to the team.

# agent/standing.md
# Short on purpose. Change it in a reviewed diff.
# Keep skill bodies in their own files.

Run the app with the command in the README.
The fixed billing task is: add a usage row for the signed-in workspace and show it on the dashboard.
Tests for that task are the usage tests named in the README.
Edit the usage path and its test. Leave payment webhooks on their current path.
When the task is the usage row, read agent/skills/usage-row.md.
For any other task, leave that skill unread.

A reviewer should read this file in one sitting. Keep project instructions that short. A skill body inside this file makes every later task pay for one task's steps.

Load the skill only for that taskCopy Anchor Link

The standing file names the path. The agent reads it for the usage-row task and skips it otherwise. That follows the same idea as Cursor loading a built-in tool when the turn needs it, using files in your repo.

# agent/skills/usage-row.md
# Read this only when the task is the usage row.

Read the workspace id from the session the app already uses.
Write one usage row for that workspace.
Show the row on the dashboard page that already lists usage.
If the workspace id is missing, stop and leave the workspace list unchanged.

Edit the skill in place. The next run that reads the path sees the diff. Point the agent at that path like any other file in the repo. There is no extra service to call. Leave one short rule in the standing file when every task needs it. Move a second skill out when unrelated tasks would carry it.

Measure the same task twiceCopy Anchor Link

Use one prompt, one commit, and one model. Start each run in a fresh chat. Record only fields the product shows.

# agent/checks/usage-row-remeasure.txt
# Fill both columns from the product. Leave an unknown cell blank.

prompt: (paste the exact task prompt)
commit:
model:
effort setting, if the product has one:

                before                 after
standing file:  previous copy          short file + skill path
task finished:
input tokens:
cached input:
uncached input:
output tokens:
cost shown:

Completion comes first. A lower token count is a candidate saving only when the after run still finishes. Cursor paired their 7% with no reduction in agent quality. Your check is this task's diff and its test.

Fill token cells from the product. When you only have a monthly invoice, write "not shown" and note the invoice period. A monthly total that mixes other people and other tasks stays a monthly total. Change one thing between the columns: shorten the standing file, or move one skill out of it. When a Cursor update lands in the same window, rerun after it settles, with the file as the only change.

When you don't need thisCopy Anchor Link

Skip the files when this repo has no coding agent. The post is still worth reading. The re-measure is for a team about to book a savings line.

Skip the pair while this repo still runs the build from before the harness change. Skip a second pair when someone already recorded two runs of this prompt and the standing file is unchanged. Run again when the next sprint would copy 7% onto a forecast.

Skip the skill split when one short rule serves every task. Leave Cursor's tool list, cache breakpoints, and tenth-line numbering in their harness. The 60%, the 20%, and the 1.6% stay on the denominators in their post.

Commit the standing file, the skill file, and the re-measure note together. Fill the before column from a run you trust. Run the after column in a fresh chat at that commit. Write a savings line only after both runs finish and the token cells come from the product.

Ship the usage surface that task edits from the SaaS dashboard template: https://otf-kit.dev/templates/saas-dashboard

The template is the product shell for that dashboard. You add the standing file and the skill in the repo you already ship.

SourcesCopy Anchor Link

• https://cursor.com/blog/improved-token-efficiency