The Next AI Advantage Is Not a Better Model. It Is a Better Harness.

Most teams assume cutting AI costs means using cheaper models. We found the opposite: better context design helped us use more AI for less money. Between May and September 2026, PayU’s Cursor usage expanded—more active users and more engineering requests—while token cost, cost per active user and cost per request each fell by more than half. That is a strong signal that better harness design and intelligent model routing may improve cost efficiency without reducing engineering agility.

Imagine a busy kitchen preparing meals for thousands of people every day.

At first, the restaurant tries to reduce costs in the most obvious way: hire lower-skilled cooks instead of high-end chefs. But without a better system, the savings disappear: orders take longer, the wrong ingredients are pulled and low-quality dishes are remade.

Then someone asks a better question: what if the problem is not the cooks, but the way the kitchen is organised around them?

The restaurant redesigns the workflow. A clear kitchen map shows where every ingredient belongs. Each order carries only the recipe and customer details needed for that dish—not the entire cookbook. Routine orders go to efficient cooks, while experienced chefs step in for unusual, complex or high-risk dishes. A quick taste and safety check catches mistakes before a meal reaches the customer. The result is more orders completed, less ingredient waste, faster service and fewer remakes.

In AI terms, cooks represent models, while order tickets and ingredients represent tokens—the input and context supplied to each task. The kitchen workflow represents the system around the model: context, routing and evaluation. The lesson is that the cheapest model or the fewest tokens is not always the lowest-cost option; the real goal is a correct outcome with less waste and rework.

The harness matters more than the hype

A harness is the context, tools, instructions, routing and checks around an AI model. It shapes what the model can see, what it is asked to do, how its work is tested and how people decide whether the result is good enough. The thesis is simple: a better harness can improve quality while reducing cost, because it makes useful model capability more reliable and less wasteful.

Give AI a map, not a manual

PayU uses its Service Knowledge Graph (SKG), an internal system that captures and organises code knowledge and context for each repository. It helps reduce cost by giving the assistant relevant context earlier, reducing unnecessary file-reading and repeated context. The goal is not to put every file in front of the model. It is to help it find the parts that matter.

Make the repository teach the assistant

SKG is the shared organisational memory for engineers and AI—a map, not a 1,000-page manual. Short, linked, relevant guidance beats a large static document. At the repository level, make five things easy to find:

• Structure and ownership: how the system is organised and who owns it.
• Ways of working: how changes should be made.
• Boundaries: areas not to change casually.
• Checks: required tests and validation.
• Definition of done: what evidence shows the change is complete.

Kept concise and current, this gives context earlier. The assistant spends less time exploring files, asking repeated questions or making incorrect assumptions. Teams get fewer agent turns, lower token use and less human rework. For example, payment-webhook or payment-flow guidance can point to the responsible service and team, boundaries that protect payment handling, required tests and evidence that the change is complete—without describing every implementation detail.

Build feedback into the workflow

Give the workflow two controls:

• Feedforward before work starts—scope, constraints, examples and success criteria.
• Feedback during and after—tests, linters, contract checks, security checks and independent evaluators.

Fast, automated feedback catches errors while they are cheap to fix and turns recurring mistakes into better instructions or checks. Anthropic’s write-up on its multi-agent research system reinforces the value of evaluator-style checks when generation needs independent assessment.

Manage context over long tasks

Long tasks create a practical risk: a conversation can become so large that the assistant loses the thread. Focused sessions help keep the objective clear. Structured handoffs—such as a short progress note, a list of decisions and the next concrete step—let work continue without carrying every old message forward.

Here’s how to set up a handoff in Claude Code and Cursor:

Option 1: Claude Code (Custom Skill)

1. Create the Skill
Save a file named SKILL.md inside ~/.claude/skills/handoff/ and paste this code:

---
name: handoff
description: Generates a copy-pasteable summary for a new session.
---

Analyze our active conversation history and output this exact text block:
- Goal: [Main objective]
- Status & Files: [Done vs. In-progress / File paths]
- Dead Ends: [What failed, to avoid repeating it]
- Next Step: [The exact next prompt to execute]

2. Run & Reset
• Type /handoff in your terminal when the chat gets bloated.
• Copy the generated block into a fresh session.

Option 2: Cursor (Project Rule)

1. Save the Custom Rule
Create .cursor/rules/handoff.mdc with this text:

When I type "Generate a handoff", analyze our active chat history and output this exact block:
- Goal: [Main objective]
- Status & Files: [Done vs. In-progress / File paths]
- Dead Ends: [Approaches that failed]
- Next Step: [The absolute next task]

2. Run & Reset
• Type Generate a handoff in your Cursor chat sidebar.
• Copy the generated block into a fresh session.

Anthropic’s guidance on effective harnesses for long-running agents highlights decomposition and context resets for this reason. A fresh session is not a failure. It is often a quality control: remove stale history, restate the current goal and give the next assistant only the context it needs.

Use the right model for the job

Intelligent routing is not about always choosing the cheapest model. It is about matching model capability to the risk and difficulty of the task, then escalating only when the extra reasoning is likely to change the outcome.

A practical routing pattern is a cascade:

• Fast or light models for classification, extraction, formatting, simple explanations, syntax questions and low-risk lookups.
• Everyday coding models for most feature work, tests, refactors, pull-request fixes and well-scoped implementation tasks.
• Deep-reasoning models for production regressions, ambiguous architecture decisions, performance issues, race conditions, security-sensitive changes and anything where a wrong answer creates expensive rework.

The important discipline is to route by task class, confidence, risk and budget—not by habit. A smaller model can handle a clear, bounded task when the repository map, examples and checks are strong. A stronger model may be cheaper overall for a hard debugging session if it avoids repeated failed attempts, redundant context reads and a long human review cycle.

For engineering work, split planning and implementation only when the path is clear. A stronger model can be useful for the first planning pass on an ambiguous problem, but the handoff to an everyday coding model should happen only after the approach, constraints, tests and edge cases are explicit. For genuinely hard problems, stay with the stronger model for the whole session; otherwise the savings can disappear when missed edge cases lead to rework.

This is where routing becomes part of the harness. At PayU, we already use Cursor’s router to match many requests to a suitable model instead of asking every engineer to choose manually each time. We are also evaluating a move toward a central AI gateway for capabilities that sit around model selection, such as stronger spend controls, usage reporting, policy enforcement, fallback handling and auditability. Cursor helps with day-to-day model selection; a central gateway could give us a more consistent control plane across tools and teams. Over time, feedback from edits, rejections, tests and human review should make these routing guidelines sharper. The outcome to optimise is not model spend in isolation; it is the cost of a correct, reviewed and production-safe result.

The token-minimiser stack

Combining RTK, Headroom and Caveman is a practical way to reduce token waste across different stages of an AI-assisted engineering request. The tools can work together: RTK reduces noisy terminal output, Headroom compresses the wider context the agent sends to the model and Caveman encourages concise responses. Together, they can compound savings in workloads where long debugging sessions repeatedly send context to an AI service.

How each layer can save money

1. RTK — the Bash/Terminal filter. RTK targets input tokens produced by tools. When Cursor or Claude Code runs commands such as git diff, npm install or grep, raw terminal output can add thousands of noisy lines to the context. RTK intercepts and summarises this output locally, with the project reporting reductions of up to 90% for terminal noise. Smaller, cleaner tool results also help preserve a stable cache prefix and reduce unnecessary cache writes. The actual reduction depends on the command and workload.
2. Headroom — the local compression layer. Headroom compresses what the agent reads—tool outputs, logs, files, search results and conversation history—locally before it reaches the model. It keeps the originals available locally so the full text can be retrieved on demand when detail matters. The project reports 21–57% fewer input tokens across agent scenarios and 90%+ reductions on repeated JSON arrays and log lines, while noting that plain prose compresses much less.
3. Caveman — the output shortener. Caveman targets output tokens. Used as a prompt modifier or plugin, it encourages the model to remove introductions, politeness and repetitive explanations and return dense, actionable prose—for example, “New object ref each render. Wrap in useMemo.” instead of a long explanation. This does not reduce cached input, but it can reduce direct generation cost when output tokens are priced well above input tokens. Concision should remain appropriate to the task: design decisions, safety checks and customer-impacting changes still need enough explanation.

How to stack them

1. Install RTK and initialise it for the assistant you use. For example, on macOS or Linux:

   brew install rtk
   rtk init -g                 # Claude Code / Copilot
   rtk init -g --agent cursor  # Cursor

   RTK also supports Windows via winget install rtk-ai.rtk and a shell installer via curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh. After setup, restart the AI tool and verify with rtk gain.
2. Put concise Caveman-style response rules in system instructions, .cursorrules or Claude Code custom skills so they are present from the beginning of the cached context.
3. Install Headroom from PyPI for the CLI/proxy, for example uv tool install --python 3.13 "headroom-ai[all]" or pip install "headroom-ai[all]". For the setup we have tested with Claude Code, run headroom proxy --port 8787, then start Claude Code with ANTHROPIC_BASE_URL=http://localhost:8787 so requests go through the local Headroom proxy. Verify the setup with headroom doctor or headroom perf. We have tested this with Claude Code only.
4. Run before-and-after tests on representative tasks. Confirm that code accuracy, security checks and review quality remain unchanged while input, cache and output tokens fall.

But fewer tokens do not automatically mean a lower bill. Token reduction must be tested against quality, missed information and rework. The useful measure is the total cost of a correct outcome—not compression for its own sake.

PCI DSS caution: In payments environments, any token-saving proxy, logging layer, model gateway or external AI service should go through security and compliance review before code, logs, prompts or production data flow through it. Keep sensitive payment data out of prompts unless the path is explicitly approved, governed and auditable. Also check telemetry defaults for any local tool; for example, Headroom can send anonymous usage data by default, so disable it (HEADROOM_TELEMETRY=off) or get it approved before use in regulated environments.

This is a cultural shift

A harness works only when teams use it responsibly and keep improving it. AI should become a shared capability: engineers are empowered to use it, but remain accountable for the result. Leaders should reward quality, learning, sound judgment and ownership.

Early signals are encouraging. Over the same period, active usage and AI-assisted requests both grew. Cost efficiency improved at the same time. Quality signals improved too: the acceptance rate was already high in May and rose further by September. Accepts / (accepts + rejects) increased from 97.9% to 99.3% and AI’s share of lines added increased from 66.4% to 79.3%. These signals do not prove causation yet. Agent activity alone does not prove productivity, so the next step is to keep combining adoption data with quality, review and business outcomes.

Human accountability, focused testing and safe rollback stay in place for changes that could affect customers or money.

Key takeaway

The durable advantage is not simply access to frontier models. It is the ability to make AI useful, dependable and economical at organisational scale.

That is the shift we are seeing: a clear map reduces wasted context, living guidance reduces ambiguity, fast feedback catches errors early, focused sessions protect quality over long tasks and deliberate routing puts premium capability where it matters. Together, these practices make AI-assisted engineering a stronger operating capability—not a technology status contest.

What is in your AI harness today—and where is it still leaking (context, cost or quality)?