---
title: "How I am measuring the real cost of Claude and Codex"
source: "https://www.matteovincenti.com/en/blog/reduce-claude-codex-tokens-experiments"
language: en
author: "Matteo Vincenti"
published: 2026-10-20
updated: 2026-10-23
category: "AI"
tags: ["AI tokens", "Claude Code", "Codex"]
---

# How I am measuring the real cost of Claude and Codex

Research in progress on the cost of Claude and Codex tasks: usage, time and human review, with commands and settings for the workflow variants to compare.

![A green strip passes through a cutter, with offcuts beside it](https://cdn.sanity.io/images/xrqkwry7/production/faa5fca87061089e868e9e917424379aaf6e6525-1728x910.png?w=1400&fit=max&auto=format)

Category: AI · Tags: AI tokens, Claude Code, Codex

I am investigating which changes to a Claude or Codex workflow reduce the resources needed to complete a task while keeping the result correct. Measuring the whole activity is the difficult part: a shorter answer may have required just as much reading, or left more corrections for the person reviewing it.

Tokens are the units in which the model processes text. To judge whether an optimisation is worthwhile, I also account for cost, elapsed time and human review. I have a prototype, automated checks and some bounded runs; I do not yet have enough comparative evidence to claim a percentage saving. [Claude Code usage and costs](https://code.claude.com/docs/en/costs).

The workspace already contained project instructions, skills, roles and scripts. The audit brought a measurement problem into focus: reconstructing consumption for the complete activity while distinguishing the requested configuration from what actually ran. The prototype I am developing uses a runner: a process that starts a bounded activity and collects the available execution data.

[Michele Cotti’s video on optimising Claude usage](https://www.youtube.com/watch?v=uNudoboecMk) adds useful ideas to this research: rewind, planning, handoffs and context management. I want to understand the conditions under which each intervention reduces the work needed to reach an acceptable result. The commands and settings below make those variants concrete enough to compare.

## What goes into the cost of a task

My unit of comparison is a task with a verified result. Its scope includes preparation, tool calls, handovers to another agent, checks and corrections. I fix the acceptance criteria beforehand: a procedure that stops without meeting them remains a failed attempt.

For example, a targeted pagination search might read fewer files while overlooking the ordering that produces duplicates. If it then has to broaden the search and repeat work, I want both attempts counted.

Context is the material available for the next response. Tokens are the units the model processes and generates. Usage accumulates across requests, including requests that reuse part of the same context.

A simple teaching model shows the effect of a growing conversation: if five requests contain one, two, three, four and five blocks of 1,000 tokens respectively, their combined input is 15,000 tokens, not 5,000. This is a sum of lengths rather than exponential growth. Calculating a price also requires the model, caching and output.

On a subscription, using fewer tokens does not automatically return money. The benefit may be more work within the allowance, fewer interruptions or less paid extra usage. With an API key, service rates apply instead. Check how you are authenticated: a configured API key can put Claude Code on API billing. [Pro/Max plans and API billing](https://support.claude.com/en/articles/11145838-use-claude-code-with-your-pro-or-max-plan).

In Claude Code, `/usage` shows available usage and limit information; the local dollar amount is an API estimate. Shares attributed to skills, agents or integrations describe affected usage and may overlap. They are not predictions of how much you could save. [Official cost guide](https://code.claude.com/docs/en/costs).

The comparison record needs to connect a difference in usage to what happened during the task:

_What goes into the cost of a task_

| Data | What I compare |
| --- | --- |
| Task, revision and acceptance | The same starting point and required result |
| Requested and observed configuration | The chosen variant and what the client confirms it ran |
| Input, cache and output | Available components, with their counters and units |
| Attempts, outcome and corrections | Work through acceptance, including failures |
| Time and human review | Waiting, restarts and work left to the reviewer |

An unavailable measurement stays marked as unavailable. The record also needs to expose cases where two runs cannot be meaningfully compared.

## Where the load starts

Before changing the workflow, I need to understand what the client loads and which data it exposes. In Claude Code, `/context` shows what occupies context; `/usage` helps explain usage and the components involved. Material present before the task is prepared input. Its presence alone does not establish that a billable request has just occurred.

Use `/doctor` to review the setup. This included skill can propose changes for you to confirm. Recent-usage recommendations require Claude Code 2.1.305 or later, an eligible plan and a session outside Remote Control. The terminal command `claude doctor` checks the installation instead. [Setup checks with /doctor](https://code.claude.com/docs/en/skills#check-your-setup-with-doctor).

A plugin packages extensions: it can include skills, which provide procedures for a task, and MCP (Model Context Protocol) servers, which make tools available to the agent. A tool schema describes what the tool does and which arguments it accepts; its output contains the call’s result.

For a particular plugin, run `claude plugin details plugin-name` in the terminal, replacing the name with an installed plugin. It separates estimated always-present material from material loaded on invocation. Inspect the session context for MCP schemas resolved at runtime. [Measuring plugin cost](https://code.claude.com/docs/en/plugins/measure).

Those signals help identify a variable worth testing:

_Where the load starts_

| Signal | First change | What to check afterwards |
| --- | --- | --- |
| Many instructions before work begins | Remove duplication and separate occasional procedures | Can the agent still find the required rules and commands? |
| Broad searches and huge results | Narrow the scope and return relevant passages | Are errors and decision-changing cases still visible? |
| Repeated corrections along the same path | Stop, clarify the requirement and consider a checkpoint | Do the conversation and files describe the same state? |
| Resumed sessions repeat the exploration | Improve the handoff and its references | Does the new session resume at the right point? |
| Several agents read the same material | Reduce overlap or use one agent | Does shorter elapsed time justify the extra work? |

## What is worth loading

One variant concerns the material loaded at startup. I would keep the task and model fixed while separating occasional procedures from recurring instructions. The record would compare initial context and subsequent reads: a lighter start loses its value if the agent has to find missing rules or redo a change. `CLAUDE.md` retains orientation, constraints and essential commands; a long, occasional procedure can live in a skill or reference read when needed. Splitting a file into several `@import` files still loaded together organises the documents without reducing their context footprint. The recommended target of fewer than 200 lines is guidance for concision, not a truncation limit for `CLAUDE.md`. [Effective instructions](https://code.claude.com/docs/en/memory#write-effective-instructions).

An installed skill does not normally mean its full contents are already loaded. Claude Code starts with selection information and reads the body when it uses the skill. Skills explicitly preloaded into a subagent are an exception. The catalogue’s quality matters alongside its size. [Skill loading](https://code.claude.com/docs/en/skills).

Compatible clients and models can defer MCP tool schemas through tool search. Configuring a server does not imply that every definition is already in the prompt. Tool output still needs attention: a response containing thousands of records may outweigh the description that made the tool available. [MCP tool search](https://code.claude.com/docs/en/mcp#scale-with-mcp-tool-search).

The plugin count alone tells me little about a task’s cost. A code-navigation plugin can locate a symbol instead of requiring several searches and file reads. Removing it simply to reduce the plugin count would miss that benefit. The [cost guide](https://code.claude.com/docs/en/costs#install-code-intelligence-plugins-for-typed-languages) describes this option.

The guide to [skills for Claude and Codex](https://www.matteovincenti.com/en/blog/optimise-skills-claude-codex) develops the boundary between initial instructions and procedures loaded when needed.

## The cost of attempts along the wrong path

For substantial changes, I want to compare work with and without an explicit planning phase. A plan adds reading and reasoning at the start; it may avoid an unsuccessful approach and the corrections that follow. The record therefore also needs attempts after planning and time through acceptance. For a small, well-defined fix, that phase might add only overhead. In Claude Code, this variant can use `/plan` or start the CLI with `claude --permission-mode plan`. [When to use Plan Mode](https://code.claude.com/docs/en/best-practices#explore-first-then-plan-then-code).

Another variant supplies the criteria for one result together. “Fix pagination, add the final-page test and show the diff” makes the complete task visible before editing. I would compare it with a sequence that introduces the same criteria one at a time, including changes that need to be reopened. The expected benefit would disappear if the combined request became broad enough to miss a check. Keep unrelated tasks separate, along with steps that need a decision before implementation continues. Anthropic recommends [grouping related questions](https://support.claude.com/en/articles/9797557-usage-limit-best-practices).

If the approach is wrong, repeatedly saying “try again” can carry every failed attempt into subsequent context. In the web chat, you can rephrase an earlier message; Claude Code offers `/rewind` to return to a checkpoint. First retain the few useful discoveries and identify the approach to avoid.

The menu distinguishes restoring the conversation, files or both. Restoring only the conversation may leave existing edits in the working tree. Checkpoints also do not reverse every shell operation or change to an external service: a deployment or database update needs its own recovery procedure. [How checkpointing works](https://code.claude.com/docs/en/checkpointing).

## Continuity and the cost of compaction

Compaction is one of the interventions I want to compare across the complete activity. A useful summary needs to let the next session continue without repeating exploration or losing the requirement.

`/compact` summarises the history so work can continue. A new chat, or `/clear`, is more appropriate when the objective changes or you want to restart with only the information you choose to carry forward. Producing the summary takes model work, and resuming may require reading useful material again. Repeated compaction has a cost.

Before resuming, retain the requirement, decisions that constrain it, relevant files, completed checks and the next action. For example:

```txt
Task: fix pagination in the order list.
Constraint: keep ordering stable when two orders have the same date.
State: query changed; final-page test still needs to be added.
References: task issue, current commit, query file and relevant tests.
Next action: check for duplicates and skipped rows across consecutive pages.
```

This is a handoff format rather than a preinstalled command. A skill can produce it consistently; names such as `/handoff` or `/sessionoff` only work if you installed procedures using them. The next session also needs to inspect the actual files. The [memory and handoff article](https://www.matteovincenti.com/en/blog/context-engineering-memory-handoffs-wiki) covers that path.

Compaction does not fix oversized startup instructions: some are inserted into the next context again. Caching is a different mechanism, reusing an unchanged opening part of the request, called the prefix, subject to specific conditions and time limits. Changing the history or model can affect that reuse; retaining an enormous conversation solely for its cache can preserve a great deal of irrelevant material. [Context after compaction](https://code.claude.com/docs/en/context-window), [prompt caching](https://code.claude.com/docs/en/prompt-caching).

While you are still working and the cache is warm, the request that produces a summary can reuse the prefix. After a break longer than the cache lifetime, it has to process that history again: compacting on your return can require the very reading you wanted to avoid. At a natural stopping point, decide whether to summarise before leaving or retain a handoff for a new session. After the first response, `Prompt cache (main)` in `/usage` shows the main conversation’s cache state on version 2.1.251 or later; it excludes subagents. [Compaction and caching](https://code.claude.com/docs/en/prompt-caching#compacting-the-conversation).

Projects and personal instructions in Claude’s web app also help reuse information without repeatedly attaching or typing it. They do not make documents permanently free input. The [usage guide](https://support.claude.com/en/articles/9797557-usage-limit-best-practices) distinguishes reuse, caching and limits. In a repository, the practical counterpart is organising relevant instructions and references; web-chat settings are not universal configuration for every client.

### An automatic threshold as a variant

To isolate the threshold’s effect, I would compare default behaviour with an explicit threshold while keeping the task, model and instructions fixed. I would record context before and after summarisation, the summary’s usage and the reads needed to resume. A smaller context followed by repeated exploration or a lost requirement would be a reason to reconsider the setting.

The command requires Claude Code 2.1.221 or later. Check that Auto-compact is on in `/config`: setting a threshold does not enable a disabled feature. `DISABLE_AUTO_COMPACT` or `DISABLE_COMPACT` can also prevent it. If an organisation manages that policy, agree the change with its owner. [Compaction environment variables](https://code.claude.com/docs/en/env-vars).

To try a 200,000-token window for one launch, run these commands from the project directory:

```bash
claude --version
claude --autocompact 200k
```

Inside the session, `/autocompact` shows the setting and `/context` shows the context. Use `/autocompact 200k` to save the choice for the current model. `/autocompact auto` restores the product’s default behaviour. Before version 2.1.288, the saved setting was not per model.

I use 200,000 to illustrate the configuration, without treating it as an optimal threshold. The value is capped at the model’s context window; documented settings range from 100K to 1M tokens. Check overrides: `CLAUDE_CODE_AUTO_COMPACT_WINDOW` can take precedence. The status line’s percentage refers to the model’s window and does not necessarily identify the configured threshold. [Automatic compaction settings](https://code.claude.com/docs/en/model-config#set-the-auto-compact-window).

### When a Mod adds value

Official Claude Code Mods are JavaScript or TypeScript plugins that respond to session events. A Mod can read `$.session.usage()` and request `$.session.compact({ instructions })`, for example to connect compaction to a work checkpoint. For a token threshold alone, the native setting is simpler. [Mods reference](https://code.claude.com/docs/en/plugins/mods/reference).

The next variant would add early compaction tied to a checkpoint, keeping the native configuration as the fallback. The comparison needs to show whether choosing a point where the task state and next action are already recorded reduces reconstruction after summarisation. A custom policy could therefore compact before the native threshold only after you confirm that checkpoint. A command added by the Mod can collect that confirmation. If the early threshold is exceeded while a diagnosis remains open, the Mod can notify you and wait; native compaction stays enabled at its own limit. The module must consume or invalidate the confirmation when the state changes. Token counts do not establish whether the work is ready to summarise.

Compaction requests must be managed between turns, avoiding concurrent calls and endless retries after refusal. An event that updates usage does not always mean the agent is idle.

To make this variant implementable, the [official Mod creation process](https://code.claude.com/docs/en/plugins/mods/create) starts with Claude Code 2.1.287 or later and the included `/plugin-authoring` skill. The following prompt describes the proposed policy, which needs to become code before it can be tested:

```txt
Create a Claude Code mod using the types generated by my installed version.
Keep native auto-compaction enabled as the fallback.
Add a /context-ready command for this mod: I use it to confirm that the
current task state and next step have been recorded.
After a turn ends, check the observed context tokens. Above a configurable
early threshold, compact only if that explicit checkpoint is still valid.
Otherwise show a reminder and leave native compaction in control.
Consume the checkpoint after compaction and invalidate it on new work.
Preserve task, decisions, file references and open checks in the summary.
Handle missing measurements, concurrent calls and vetoes without retry loops.
Explain loading, tests and how to disable the mod before I approve running it.
```

Claude generates code for you to inspect and approve. The official guide explains loading, validation and tests; naming a threshold in a prompt is not enough to establish a reliable policy. I would record execution cost separately from the work of writing, checking and maintaining the Mod. If the summary lost information, the reads and corrections needed to resume could cancel the expected savings in subsequent requests.

## Models and delegation in the final accounting

I am treating the model, reasoning effort and delegation as separate variables. Changing them alongside the instructions would make it difficult to attribute an outcome to a particular choice.

For model choice, I would distinguish changing the price per token from changing the work required to solve the task. A cheaper model may need more attempts; a more capable one or higher reasoning effort may avoid corrections on a difficult decision. The record would compare observed configuration, usage and acceptance within the same task class. The choice depends on the cost of all attempts, rather than the rate for the first request alone.

Subagents isolate research and bulky results from the main conversation, but make their own requests. For a bounded search, I would compare a single agent with delegation: aggregate usage, elapsed time and the work of reading and checking reports. Delegation may save time while increasing usage; having five agents reread the same repository may instead add preparation and coordination without improving the result. [Subagent context](https://code.claude.com/docs/en/sub-agents).

For a short side question, Claude Code provides `/btw question`: it uses available context without adding the exchange to the main history or using tools. Generating the response still requires a model call. If the result changes the task, bring it back into the main work. [Side questions with /btw](https://code.claude.com/docs/en/interactive-mode#side-questions-with-btw).

A status line can keep context occupancy visible. Also inspect allowance reset times: a short window resetting does not remove an exhausted weekly limit. Schedule useful tasks around both; consuming allowance merely because it is about to reset does not improve the result.

## The same hypotheses in the Codex client

These references concern the CLI; apps and integrations may expose different features. Similar goals do not make command names interchangeable. A fork separates conversation history without undoing changes to files or external services. A side chat also uses capacity.

_The same hypotheses in the Codex client_

| Need | Codex |
| --- | --- |
| Diagnose the installation and environment | `codex doctor` in the terminal |
| Inspect session configuration and state | `/status` |
| Inspect available activity and limit information | `/usage`, including daily and weekly views with supported authentication |
| Plan a substantial change | `/plan` |
| Prepare a summary without compaction | `/recap` |
| Summarise the current work | `/compact` |
| Return to an earlier request | In the CLI, press `Esc` twice with an empty composer to edit the previous message and fork from it |
| Ask a side question | `/side`, with `/btw` as a CLI alias |
| Keep status visible | `/statusline` |
| Start an independent task | `/new` |
| Manage recurring rules and procedures | Focused `AGENTS.md` instructions and relevant skills |
| Limit MCP and tool output | Enable servers and tools for the task; configure output budgets |

Sources: [session commands](https://learn.chatgpt.com/docs/developer-commands?surface=cli), [CLI diagnostics](https://learn.chatgpt.com/docs/cli/reference#codex-doctor), [skills](https://learn.chatgpt.com/docs/build-skills), [MCP](https://learn.chatgpt.com/docs/extend/mcp).

For automatic compaction, add or edit these top-level keys in `~/.codex/config.toml`, before any bracketed sections and without duplicating existing keys:

```toml
model_auto_compact_token_limit = 200000
model_auto_compact_token_limit_scope = "total"
```

This illustrative token setting requires a model window suitable for the chosen threshold. `total` counts the entire active context. Without an explicit threshold, model defaults apply. The [Codex configuration reference](https://learn.chatgpt.com/docs/config-file/config-reference) also documents tool-output limits: remove noise while retaining necessary diagnostics and errors. Start a new process after the change; `/debug-config` helps inspect configuration layers and overrides, while `/status` shows model and usage information. Profiles, project settings and CLI options can take precedence over the personal file. To undo the change, restore previous values; remove the keys if they were not present before.

In Codex, I would use the same record while preserving the meaning of the client’s counters. I would first compare the variant with the starting behaviour in the same environment. The question remains how much work reaching acceptance requires: does a skill avoid exploration, does a summary allow work to resume, does delegation reduce waiting? The [pricing and usage rules](https://learn.chatgpt.com/docs/pricing) distinguish ChatGPT plans and API usage. API rates do not automatically convert the remaining subscription allowance into money.

## The comparison I want to make

For the first comparison, I would start with a pagination fix: the same initial state, requirement and final-page test. One variant searches a broad area; the other narrows the search. If the second misses an important file and has to start again, I want that attempt to remain in the accounting.

I would change one variable at a time, recording the same indicator and its unit before and after: tokens consumed, allowance used or remaining, or an estimated amount. The comparison also includes elapsed time, checks and human corrections through acceptance. An allowance reset during the test needs to be recorded: subtracting percentages across a reset does not measure usage. Relevant sessions and agents belong within the scope without counting overlapping totals twice.

Where monetary cost is observable, the measure I propose is:

`cost per accepted task = cost of all attempts / number of accepted tasks`

The numerator includes rejected attempts and retries. If no task is accepted, the ratio is undefined: I would report the cost incurred and zero accepted tasks. I want to read that figure alongside success rate and review time; API rates alone do not measure the cost of my subscription.

The comparison should also tell me where to intervene next. If targeted searches reduce reading but increase attempts, I would first improve their selection criteria. If work repeats at every restart, I would look at the handoff and compaction. For the pagination example, I want to establish what it costs to deliver a fix that passes the final check, including the attempts needed to get there.