HarnessAgent pricing workflow: cost-aware routing for Codex, Cursor and Claude Code

Learn a concrete HarnessAgent pricing workflow to route Codex, Cursor and Claude Code by cost, with Vercel caps and clear token budgets.

If you mix Cursor, Claude Code and Codex/OpenAI in one stack without a plan, your AI bill becomes guesswork. A reliable pattern is to treat HarnessAgent as a cost-aware router: give every model explicit price metadata, route work to the cheapest acceptable lane, and back that with Vercel-level hard caps.

This article lays out a concrete workflow for a small team: Cursor and Claude Code for IDE work, HarnessAgent for backend agents, OpenAI GPT‑4.1 mini as the cheap default and Claude Opus 4.7 as a guarded heavy-coding lane. It shows how to encode costs into HarnessAgent, how to keep Cursor IDE-only, how to wire Vercel limits around each route, and how shifting workload between lanes changes blended cost per 1M tokens using only official OpenAI and Anthropic pricing.

Why you need a pricing workflow for HarnessAgent, not just ‘the best model’

HarnessAgent is an open-source multi-agent harness that runs multiple LLM providers behind one abstraction layer. Its configuration supports multiple providers and models with cost_per_1M metadata for routing decisions, according to the repository docs. That makes it a natural place to turn model choice into an explicit pricing workflow instead of ad‑hoc prompts.

Once Cursor and Claude Code join the mix, you are no longer optimising a single per‑token API bill. You are juggling three distinct pricing regimes:

Pure per‑token APIs (OpenAI GPT‑4.1, GPT‑4.1 mini, Claude Opus 4.7 API).
Seat-based IDE assistants with credit pools (Cursor).
Seat-based Claude subscriptions (Claude Pro/Team and Claude Code) that bundle IDE/assistant usage and, in some tiers, API or agent usage.

The goal for a small team is not to squeeze every last cent out of a single model. It is to:

Keep low-risk work on prepaid seats where marginal cost is flat.
Use cheap API models (e.g. GPT‑4.1 mini) for generic backend tasks.
Reserve premium models like Claude Opus for heavy coding with strict limits.
Prevent backend agents from consuming Cursor credits at all.

That requires routing by cost and usage scope, not just by quality. HarnessAgent’s cost metadata plus infra caps on Vercel give the necessary hooks to do it predictably.

For deeper context on how Cursor and Claude Code differ as IDE-first vs agent-first stacks, see the internal analysis in Cursor vs Claude Code vs code or terminal agents, how their combined cost behaves in the real cost of running Cursor, Codex and Claude Code together, and how they behave in CI in AI coding agents in CI: keep Cursor, Claude Code and Codex away from production.

The three pricing regimes you are actually paying for

The pricing logic here rests on official documentation only: Cursor’s pricing page and team docs, Anthropic’s Claude API list prices for Claude Opus 4.7, and OpenAI’s GPT‑4.1 pricing page.

1. Codex / ChatGPT / Claude API: pure per-token metering

OpenAI’s GPT‑4.1 family (including GPT‑4.1 mini) is billed per 1M tokens of input, cached input and output in the API, as documented on OpenAI’s GPT‑4.1 pricing page. As of the latest published table, GPT‑4.1 mini is priced lower per 1M tokens than GPT‑4.1 for both input and output. Because OpenAI updates prices over time, this workflow treats the GPT‑4.1 and GPT‑4.1 mini prices as symbolic variables (P_mini_in, P_mini_out, etc.) that must be filled in from the current official pricing table before any cost calculations are run.

Anthropic’s Claude API price list sets Claude Opus 4.7 (Standard, global tier) at US$5.00 per 1M input tokens and US$25.00 per 1M output tokens. Prompt caching is billed separately. In the 2026‑05‑27 Anthropic list‑price PDF for Claude Opus 4.7 (Standard, global), cache hits and refreshes are listed at US$0.50 per 1M cached tokens, 5M cache writes at US$6.25, and 1‑hour cache writes at US$10.00. Batch pricing and any variant‑specific discounts should be taken directly from the latest Anthropic list‑price PDF at the time this workflow is implemented.

These APIs are the flexible, but potentially unbounded, part of spend. HarnessAgent can treat each model as a row in a cost table and explicitly choose cheaper models for appropriate work.

2. Cursor: seat-based with finite usage pools

Cursor’s pricing page currently lists multiple plans whose names and prices have changed over time. Because Cursor iterates on pricing and usage frequently and the exact Hobby/Pro/Teams Standard prices used in some prior analyses (for example, US$12/US$20/US$40) are no longer shown on the live page, all concrete seat prices here should be treated as examples only. Before using this workflow, replace any example seat prices with the current figures from Cursor’s pricing page and update any derived calculations accordingly.

All Cursor plans are per-seat subscriptions with usage-limited AI credits; the exact token pools are not published. The team docs for Members, Roles, and Seat Types explain that:

Team members can have Standard or Premium seats, as described in Cursor’s Members, Roles, and Seat Types documentation, and those seat types have different usage characteristics and limits at the plan level (exact token pools are not fully specified in public docs).
Each member or admin (except certain unpaid admin roles) is a billable seat.

Because Cursor does not expose per-token pricing for its credit pools, this workflow treats Cursor as a fixed monthly cost per developer that should only be consumed from the IDE. Cursor usage triggered from server-side agents or CI jobs would make seat consumption unpredictable.

For a deeper breakdown of Cursor seat economics, see Cursor pricing 2026: plans, limits, real cost and how Cursor behaves in production repos in production-ready Cursor rules for real repos.

3. Claude Code and Claude Team/Pro: subscription-backed coding

Anthropic’s Claude Pro and Team plans, and Claude Code itself, are sold per seat, bundling interactive chat and coding usage. Public docs focus on seat prices and API list prices separately; they do not give a full per-token breakdown of bundled usage inside Claude Code seats. For this workflow Claude seats are treated as fixed monthly costs that enable:

Interactive Claude Code usage in editors and terminals.
Access to Claude models via API with list-price token billing (Opus, Sonnet, Haiku etc.).

The important distinction is that Claude Code and Claude Team/Pro sit alongside, not instead of, the Claude API pricing. Heavy automated workloads via the API will be billed per token even if humans also use Claude Code in their IDEs.

Designing a small but real HarnessAgent setup

Consider a small team with:

3 engineers.
1 tech lead.
VS Code as the main editor, with support for multiple agent harnesses as described in Microsoft’s agent harness docs.

Assume the following subscriptions and APIs:

3 Cursor seats for the engineers, using the current per‑seat price from Cursor’s official pricing page (denote this as C_cursor_seat for the algebra below rather than hard‑coding a number that may be stale).
3 Claude Pro or Claude Team seats (denoted as a symbolic ClaudeSeatPrice here so the algebra stays stable as Anthropic updates pricing; fill this in from the current Claude Pro/Team pricing page before using the workflow in production).
OpenAI API access to GPT‑4.1 and GPT‑4.1 mini, billed per token.
Anthropic Claude API access to Claude Opus 4.7, billed per token.

Explicit monthly budget envelope: US$300 for the combination of Cursor, Claude seats and variable API usage.

High-level roles in the system:

IDE agents – Cursor and Claude Code, chosen inside VS Code via the Session Target, consuming seat quotas, not API keys.
Backend agents – HarnessAgent-managed routes running on Vercel, calling OpenAI and Anthropic APIs with project keys.

HarnessAgent agents in this setup:

cheap_default – uses GPT‑4.1 mini or similar low-cost model.
heavy_code – uses Claude Opus 4.7 API for complex refactors and reviews.
batch_codex_api – uses GPT‑4.1 or a similar higher-quality model in batch or cron jobs.

Cursor is deliberately not wired into HarnessAgent. It only exists for interactive IDE use.

The three pricing regimes at a glance

Option	Best for	Starting price	Main strength	Main limitation
OpenAI GPT‑4.1 mini via HarnessAgent	Low-risk backend tasks, default agent traffic	Lower than GPT‑4.1 per 1M tokens (OpenAI list prices)	Cheapest generally capable model in this stack	Not ideal for the most complex refactors
Claude Opus 4.7 API via HarnessAgent	Heavy coding, repo-wide refactors, complex reviews	US$5 input / US$25 output per 1M tokens (standard global)	High quality for complex coding problems	Significantly higher per‑token cost
Cursor seats	Interactive IDE assistance for individuals	Per-seat subscription; use current pricing page for exact figures	Fixed monthly cost, tight IDE integration	Opaque token pool; not suitable for backend use
Claude Pro/Team + Claude Code	Interactive Claude-based coding and chat	Per-seat subscription; see current Anthropic pricing	Good for structured refactors and reviews in IDE	API usage still billed separately by token

Routing rule #1: low-risk, low-context tasks stay on prepaid subscriptions

For many tasks – short refactors, doc edits, Q&A – the cheapest option is whatever is already bundled into a seat paid for every month. The marginal cost of another conversion or suggestion on Cursor or Claude Pro/Team is effectively zero until soft usage limits are hit.

The pattern:

In the editor, use the VS Code Session Target to choose Cursor or Claude Code for local assistance. These harnesses consume seat quotas, not the API budget.
On the backend, use HarnessAgent’s cheap_default route backed by GPT‑4.1 mini for small, low-risk API calls.

Inside HarnessAgent, cost can be modelled like this (the exact syntax may differ; this reflects the repository’s pattern of a cost table with cost_per_1M):

providers:
  openai:
    api_key: ${OPENAI_API_KEY}
    models:
      gpt4_1_mini:
        id: gpt-4.1-mini
        cost_per_1M:
          input:  P_mini_in   # from OpenAI GPT-4.1 mini input price
          output: P_mini_out  # from OpenAI GPT-4.1 mini output price

agents:
  cheap_default:
    provider: openai
    model: gpt4_1_mini
    max_input_tokens: 4096
    max_output_tokens: 512
    purpose: low_risk_low_context

Replace P_mini_in and P_mini_out with the per‑1M token prices from OpenAI’s GPT‑4.1 pricing table. By explicitly labelling this agent as low_risk_low_context, the router can default to it whenever the task classification allows.

Routing rule #2: reserve Cursor for interactive IDE usage only

Cursor is designed as an IDE assistant: inline edits, code chat, repo-aware context. It is billed per seat with usage-limited credit pools. According to the Cursor pricing page, there are multiple plan tiers, with details and pricing that change over time.

The Members, Roles, and Seat Types page clarifies that each member or admin (excluding certain unpaid roles) is a billable seat, and that different seat types (Standard vs Premium) have different usage characteristics and limits at the plan level. This makes Cursor the wrong tool to expose to backend or CI agents: one misconfigured job could burn a large share of a team’s seat quota.

Policy for this workflow:

Only humans in the IDE call Cursor.
HarnessAgent never talks to Cursor.
VS Code Session Target determines whether a developer uses Cursor, Claude Code or another harness for local help.

Technically, the simplest enforcement is omission: do not configure a Cursor provider in HarnessAgent at all. All server-side and CI traffic flows through OpenAI and Anthropic project API keys, which can be controlled with quotas and Vercel limits. If you later want Cursor-like behaviour in CI without touching seats, follow the patterns in safe AI coding agent PR workflow for production combined with this HarnessAgent pricing setup.

Routing rule #3: Claude Code as the heavy coding lane with guardrails

Claude Code and Claude Team/Pro seats are the natural home for large, structured refactors and deep code reviews initiated by humans. For automated heavy work – such as CI checks or branch-wide refactors – the Claude API with Opus 4.7 can be used as a guarded heavy_code lane.

From Anthropic’s list prices, Claude Opus 4.7 at the standard global tier costs US$5.00 per 1M input tokens and US$25.00 per 1M output tokens. That makes it significantly more expensive per token than typical smaller models such as GPT‑4.1 mini.

A HarnessAgent configuration for this lane can be:

providers:
  anthropic:
    api_key: ${ANTHROPIC_API_KEY}
    models:
      opus_4_7:
        id: claude-3-opus-4.7
        cost_per_1M:
          input: 5.00
          output: 25.00

agents:
  heavy_code:
    provider: anthropic
    model: opus_4_7
    max_input_tokens: 20000
    max_output_tokens: 2000
    purpose: heavy_code_review

Guardrails for this lane:

Only certain routes (e.g. CI jobs, tech lead tools) may call heavy_code.
Per-request max input and output tokens are capped.
Vercel function timeouts are set so a single request cannot stream endless tokens.

For CI and GitHub Actions-specific patterns around heavy coding agents, see the companion guide on safe workflows in run AI coding agents in GitHub Actions safely.

Unifying the three models into one cost equation

This section uses algebra and official prices to show how routing changes move blended cost per 1M tokens. The seat costs for Claude Pro/Team are left symbolic so equations remain valid as pricing shifts.

Symbol definitions

C_cursor = monthly Cursor seat spend = 3 × C_cursor_seat (per-seat price from the current Cursor pricing page).
C_claude_seats = 3 × ClaudeSeatPrice (per-seat price from the current Anthropic Claude Pro/Team pricing page).
P_mini_in, P_mini_out = GPT‑4.1 mini per‑1M input/output prices from OpenAI docs.
P_opus_in = 5.00 (US$ per 1M input tokens at the standard global tier for Opus 4.7).
P_opus_out = 25.00 (US$ per 1M output tokens at the standard global tier for Opus 4.7).

Scenario 1: small team with mixed seats and modest API usage

Assume:

10M tokens/month on GPT‑4.1 mini, with an effective blended price P_mini_eff (a mix of input and output based on usage).
2M tokens/month on Claude Opus 4.7, with an effective blended price P_opus_eff.

From Anthropic pricing, if a workload uses equal input and output tokens, a simple effective Opus price is:

P_opus_eff = (P_opus_in + P_opus_out) / 2 = (5.00 + 25.00) / 2 = 15.00 US$/1M tokens

This is an illustrative normalised assumption; real mixes will differ. The same idea applies for GPT‑4.1 mini using its OpenAI prices:

P_mini_eff = (P_mini_in + P_mini_out) / 2

Total monthly spend:

Total = C_cursor + C_claude_seats + 10 × P_mini_eff + 2 × P_opus_eff

The effective cost per 1M API tokens across both models is:

API_tokens_total = 10M + 2M = 12M
API_cost_total = 10 × P_mini_eff + 2 × P_opus_eff
Effective_cost_per_1M = API_cost_total / 12

This algebra shows that Opus usage, even at 2M/12M tokens, can have an outsized impact on effective price in typical configurations where P_opus_eff is substantially higher than P_mini_eff. Plugging in current OpenAI prices for GPT‑4.1 mini gives the specific ratio for a given deployment.

Scenario 2: routing optimisation by shifting heavy tasks

Let H be the total heavy-coding workload in million tokens per month. Baseline: 100% of H runs on Claude Opus 4.7 at P_opus_eff.

Total cost baseline:

Cost_baseline = H × P_opus_eff

Optimised: route a fraction r of H to GPT‑4.1 mini (e.g. tasks where mini’s quality is acceptable) and keep (1 − r) on Opus.

New blended cost for that heavy lane:

Cost_new = (1 − r) × H × P_opus_eff + r × H × P_mini_eff
Blended_price_new = Cost_new / H
                  = (1 − r) × P_opus_eff + r × P_mini_eff

If P_mini_eff is significantly lower than P_opus_eff, increasing r reduces the blended effective cost linearly. For example, if:

P_opus_eff = 15 US$/1M (from the illustrative equal input/output assumption above), and
P_mini_eff = k US$/1M from OpenAI’s table (where k < 15 for many practical configurations),

then at r = 0.3 (30% of heavy work moved to GPT‑4.1 mini):

Blended_price_new = 0.7 × 15 + 0.3 × k

This equation provides a clear lever: adjust r via HarnessAgent routing rules and observe how Blended_price_new moves for the actual chosen k.

Implementing hard caps with Vercel and HarnessAgent

Routing by cost metadata is not enough. Agents can loop, prompts can grow, and a single request can consume large numbers of tokens if unconstrained. Infra-level limits keep that from happening.

On Vercel, per-function runtime settings can be configured. A simple vercel.json might look like:

{
  "functions": {
    "api/cheap-default.ts": {
      "runtime": "nodejs22.x",
      "memory": 256,
      "maxDuration": 10
    },
    "api/heavy-code.ts": {
      "runtime": "nodejs22.x",
      "memory": 512,
      "maxDuration": 30
    }
  }
}

This caps execution time and memory. Combined with max_input_tokens and max_output_tokens in HarnessAgent, it defines a hard envelope around token usage per request.

In TypeScript, an API route can enforce per-route budgets before calling HarnessAgent. The following sketch uses an estimated token count and an environment variable budget:

// api/heavy-code.ts
import type { VercelRequest, VercelResponse } from '@vercel/node';
import { runAgent } from './harnessClient'; // your HarnessAgent HTTP client

const MAX_COST_PER_REQUEST_USD = Number(process.env.HEAVY_CODE_MAX_COST_USD || '1');
const P_OPUS_EFF = 15; // US$/1M tokens, from illustrative effective price assumption

function estimateTokens(prompt: string): number {
  // Very rough heuristic: 4 chars/token
  return Math.ceil(prompt.length / 4);
}

export default async function handler(req: VercelRequest, res: VercelResponse) {
  const { prompt } = req.body as { prompt: string };

  const estimatedTokens = estimateTokens(prompt) + 2000; // add headroom for output
  const estimatedCost = (estimatedTokens / 1_000_000) * P_OPUS_EFF;

  if (estimatedCost > MAX_COST_PER_REQUEST_USD) {
    return res.status(400).json({
      error: 'Request too large for heavy_code lane',
      estimatedCost,
      maxAllowed: MAX_COST_PER_REQUEST_USD,
    });
  }

  const result = await runAgent('heavy_code', { prompt });
  return res.status(200).json({ result });
}

Key points:

P_OPUS_EFF comes from the Anthropic pricing table and the chosen input/output mix.
MAX_COST_PER_REQUEST_USD is configured per environment or per function.
Mis-sized requests fail early instead of quietly consuming budget.

Similar logic can enforce a monthly or daily token budget by tracking cumulative usage in a small store (e.g. Redis, Supabase) keyed by provider and project. For a full CI/CD picture, you can pair this HarnessAgent layer with the guardrails in where AI coding agents should and shouldn’t touch your CI/CD.

Putting it together: a reference HarnessAgent pricing workflow

The pricing workflow combines three routing rules and infra caps into a concrete loop.

Step 1: classify the task

IDE-only, low risk – local edits, quick suggestions → Cursor or Claude Code via VS Code Session Target.
Backend low risk – simple Q&A, small transformations → cheap_default agent (GPT‑4.1 mini).
Backend heavy code – repo-wide analysis, plan-and-apply refactors → heavy_code agent (Claude Opus), only from approved routes.

Step 2: pick a route via HarnessAgent

A minimal routing function (e.g. inside a backend service) could be:

type TaskType = 'low_risk' | 'heavy_code';

function chooseAgent(taskType: TaskType): string {
  switch (taskType) {
    case 'heavy_code':
      return 'heavy_code';
    case 'low_risk':
    default:
      return 'cheap_default';
  }
}

For more nuance, this function can read remaining budget from a store and down-route heavy tasks when close to limits.

Step 3: enforce per-route caps

Combine:

max_input_tokens and max_output_tokens per agent in HarnessAgent.
Estimated-cost checks as in the Vercel route examples.
maxDuration and memory constraints in vercel.json.

For Codex and OpenAI agents tied to Vercel preview deployments, see the complementary patterns in Codex + Vercel: safe branch-only AI deploys for deployment hardening.

Step 4: record estimated cost per call

Each backend handler can log:

Agent name.
Estimated tokens (and later, actual tokens from provider metadata where available).
Estimated cost using the per‑1M prices from the internal registry.

Storing this in a simple table (e.g. Supabase) enables computation of effective cost per 1M tokens per agent and tuning of budgets over time.

Step 5: monthly review and adjustment

Operational cadence:

Once per month, pull token and cost logs for cheap_default and heavy_code.
Calculate effective blended price per 1M tokens for each lane and overall, using the algebra above.
Decide whether to:
Raise or lower MAX_COST_PER_REQUEST_USD per route.
Move more workload from Opus to GPT‑4.1 mini or vice versa.
Adjust seat counts for Cursor and Claude Code if humans are under- or over-using them.

Limitations, moving targets and how to keep this accurate

OpenAI, Anthropic and Cursor all change pricing and seat mechanics periodically. Anthropic’s Claude API price list referenced above is dated 2026‑05‑27; Cursor’s and OpenAI’s pricing pages include their own as‑of timestamps. Those may change without strong public signalling beyond documentation updates.

To keep the workflow accurate:

Maintain a small pricing registry in Git (JSON/YAML) with:
Per-seat prices (Cursor plans, Claude seat prices).
Per‑1M token prices (OpenAI GPT‑4.1, GPT‑4.1 mini; Anthropic Claude Opus 4.7 input, output, cache).
Date last updated and source URLs.
Wire this registry into HarnessAgent’s cost_per_1M fields so configuration and documentation stay in sync.
Review the following sources at least quarterly:
Cursor pricing and team docs.
Anthropic’s Claude API list prices PDF.
OpenAI’s GPT‑4.1 pricing page.
VS Code agent harness docs for changes to how harnesses are selected.

Routing and budgets can then be adjusted without surprises, and without rewriting application logic. The cost-aware harness remains the single place where OpenAI Codex, Cursor and Claude Code meet.

What changes the decision

This workflow assumes mixed seat subscriptions and API use. In some cases, the decision flips.

No Cursor or Claude Code seats – If the team relies entirely on API models, a simpler HarnessAgent setup with fewer routing lanes is enough. Routing can be based on token price and quality alone; there is no need to protect subscription pools.
Tiny AI budget (e.g. < US$50/month) – The overhead of multi-lane routing and Vercel caps may exceed the savings. Using a single low-cost model like GPT‑4.1 mini via one default route can be more practical until usage grows.
Single harness policy (e.g. GitHub Copilot only in VS Code) – If organisational policy standardises on one agent harness and forbids others, HarnessAgent cannot be the central router. In that case, focus on governance and provider quotas around that single harness.
Strict key isolation policies – If security policy forbids sharing API keys across services or a central router, separate, per-team or per-repo HarnessAgent instances or equivalent logic may be needed, each with its own pricing registry and caps.

FAQ

How do I stop HarnessAgent from accidentally using premium models for cheap tasks?

Use explicit agents and routing:

Cursor pricing page showing multiple seat-based plans with per-user monthly pricing and usage-based sections — Cursor’s official pricing page confirms that plans are sold per seat with usage-based AI credits, reinforcing the recommendation to keep Cursor usage confined to human IDE sessions.

Define separate cheap_default and premium agents with different models and strict max_*_tokens.
Implement a routing function that only selects the premium agent for tasks marked as high risk or heavy code.
Wrap premium routes in Vercel handlers with hard timeouts and cost checks so mis-routed calls cannot run indefinitely.

Can I safely mix Cursor, Claude Code, and OpenAI API usage in the same project?

Yes, provided each is treated as a separate cost surface:

Cursor and Claude Code as per-seat subscriptions used only in the IDE.
OpenAI and Claude APIs as metered by token behind HarnessAgent.
No backend or CI pathway into Cursor; IDEs are the only consumers of Cursor seats.

How do I estimate my monthly spend before going live with HarnessAgent?

A simple estimation loop:

List the seats (Cursor, Claude Pro/Team) and multiply by monthly prices from the current pricing pages.
For each agent, estimate median input and output tokens per request and multiply by expected volume.
Apply the per‑1M token prices from OpenAI and Anthropic to those estimates.
Pilot with a subset of users, log actual token usage per route, and update estimates before opening to the full team.

What is the simplest way to implement a hard budget cap?

Minimal approach:

Track cumulative spend per provider in a small store, using prices from the registry.
Before each API call, a Vercel handler reads the remaining budget; if the next call would cross it, down-route or return a controlled error.
Combine this with provider-side quotas where available, so overshoots fail fast.

How often should routing and pricing assumptions be revisited?

At least quarterly, and whenever OpenAI, Anthropic or Cursor announce material changes in their docs or changelogs. Re-running the algebra with updated per‑1M prices and seat costs keeps HarnessAgent routing aligned with current pricing rather than historical assumptions.