RemyBlog
does starting a new session save money with coding agentsnew session coding agent token costreduce Claude Code token usage

Does Starting a New Session Save Money With Coding Agents?

Usually yes. A new session stops the old chat history from being resent with every request. Here is the token math, when it backfires, and how to check.

Portrait of Luis Chavez-Mattos
Edited by Luis Chavez-Mattos, Director, Product··RSS

For Finance and Engineering

A person cuts an impossibly long, trailing receipt with scissors to stop the old history from piling up.

Does starting a new session save money with coding agents?

Usually, yes, if you pay per token. Coding agents resend the accumulated conversation (system prompt, tool definitions, file contents, prior turns) with every request. A long session therefore makes each new request more expensive than the last. A fresh session resets that baseline. The savings depend on how long the old session ran and how much you must re-explain to the new one. If you pay a flat price per request, a new session mostly won't change your bill.

TL;DR

  • Per-token agents resend the whole history every turn, so input cost per request grows as a session gets longer.
  • Total input cost over a session grows faster than linearly, which is why splitting one long session into two shorter ones can cut input tokens by a third or more in the example below.
  • The saving shrinks when you must re-load the same files and instructions in the new session.
  • Prompt caching discounts repeated context, so real dollar savings are usually smaller than raw token counts suggest.
  • On flat per-request plans, a new session saves little money, though it can still help output quality.
  • Your own usage logs are the only reliable way to measure what you would save.

Why does a long session cost more per request?

Language models are stateless. The agent has no memory between calls, so it sends everything it needs to know each time. One write-up on agent costs describes this directly: agents re-send the system prompt, tool definitions, file contents, and conversation history on every turn, and a long-running session with a big repo can re-bill the same context dozens of times.

Agent work also multiplies the number of requests. A single task is not one prompt. The agent reads files, plans, calls tools, runs tests, reads the output, and loops. Each loop is another request carrying the full history.

So input tokens, usually the largest cost line, depend on two things: how many requests you make and how big the context is at each one. A new session attacks the second factor.

What does the token math look like?

These numbers are illustrative assumptions, not measurements from any specific tool. Suppose:

  • The system prompt and tool definitions take 10k tokens.
  • Each turn adds 2k tokens of new history (your message, tool output, the reply).
  • You work for 50 turns.

Request n sends about 10k + 2k × n tokens. Summed over 50 turns, that is roughly 3.05M input tokens.

Now split the work into two 25-turn sessions. The first session sends about 0.9M tokens. Assume the second session needs a 5k-token briefing to get back up to speed, so its baseline is 15k. It sends about 1.03M. The total is roughly 1.9M, or about 37% less than the single session.

ScenarioTurnsApprox. input tokens
One long session503.05M
Two sessions, 5k re-briefing25 + 251.9M

The pattern matters more than the exact figures. Because each turn re-bills everything before it, cumulative cost grows roughly with the square of session length. Cutting a session in half cuts more than half of the history cost.

When does a new session not save money?

Several things shrink or erase the benefit.

Re-explaining is expensive. If the new session must re-read the same large files, rebuild a plan, and re-learn conventions, you pay for that setup again. A short session that spends its first ten turns rediscovering the project can cost more than continuing.

Caching changes the price of repeated context. Providers such as Anthropic offer prompt caching, which bills repeated prefix tokens at a fraction of the normal input rate. In a cached session, the old history is cheap to resend, so the dollar gap between a long and a fresh session is smaller than the token gap. Caches also expire after idle time, so a session you left for a while may pay full price to rebuild its cache anyway. In that case, starting fresh costs little extra.

The old session is still short. At 5 or 10 turns, the history is small. Starting over saves almost nothing and throws away useful context.

You are mid-task. Dropping the history in the middle of a debugging chain can make the agent repeat failed attempts. Retries are a cost driver of their own.

Does this apply to subscription plans?

Mostly not. Subscription tools such as Cursor, Copilot, and Windsurf have been described as charging a fixed price per request, with extra blocks costing around $0.04 each. If the price is fixed regardless of context, a smaller context does not lower your bill. Your cost depends on how many requests you make.

The same Reddit discussion argues that, compared to the subscription plan agents, pay-as-you-go agents have no financial incentive to compact your context. That is one writer's opinion, not a documented fact. It does suggest a different reason to reset on those tools: a clean, focused context may give better results than one the tool has been trimming behind the scenes.

On pay-as-you-go tools such as Cline, Roo, Aider, and Claude Code, you supply an API key and pay for input and output tokens. Here context size converts directly into money. Cline ships /smol and /newtask commands for managing context, which shows how much this matters in practice.

How do I measure the savings in my own usage?

Do not trust a rule of thumb. Check your logs.

  1. Find per-request or per-session usage data. Your provider's usage dashboard shows daily totals. Many agents also keep local session logs with token counts per request. Claude Code has a /cost command for the current session, and community tools such as ccusage read its local logs.
  2. Plot input tokens against turn number. In a long session, you should see the line climb. If it climbs steeply, resets will help.
  3. Separate cached from uncached input. If most of the climb is cache reads, which are billed at a discount, the savings are smaller than the raw curve implies.
  4. Find your longest sessions. Cost concentrates in a few of them. Compare their total cost to the typical short session.
  5. Measure the restart penalty. Look at the first few requests of a fresh session. If they load the same files you had before, that is your re-briefing cost.
  6. Run a simple test. Do comparable tasks both ways for a week and compare cost per completed task, not cost per session.

If a session crosses the point where its marginal request costs several times what a fresh session's first request would, a reset is probably worth it.

How do I reset without losing the plot?

Resetting is cheaper when the handoff is small.

  • Write a short summary of decisions, current state, and next steps before you close the session. Keep it in a file the new session can read.
  • Keep project conventions in a persistent instruction file rather than retyping them. Keep that file lean, since it is resent on every request too.
  • Reset at natural boundaries: a finished feature, a merged fix, a change of subsystem.
  • Use the agent's compaction or summarize command when you want to keep the thread but shrink it. Compaction is a middle path, though it costs a request to run and may drop details.
  • Point the agent at specific files instead of letting it read the whole repo again.

Is starting a new session worth it?

For per-token tools and sessions past a few dozen turns, usually yes. The history you drag along is a recurring charge, and most of it is no longer relevant to the current step. For flat per-request plans, or for short sessions, the effect on cost is small and the decision should rest on output quality.

Cost reports in mid-2026 suggest companies are now tracking agent spend closely, with at least one large employer reportedly capping usage of tools like Claude Code. Session hygiene is one of the cheaper levers available, since it needs no new tooling and no change in model. Model choice, retries, and context size at the start of each session matter too, and a reset does not fix those.

Frequently Asked Questions

4 questions

Does starting a new chat reduce my Claude Code bill?

On API billing, it generally does, because each request carries less history. The size of the saving depends on session length, caching, and how much you must reload. Check your usage logs rather than assuming a fixed percentage.

How long should a session be before I reset?

There is no universal number. A reasonable signal is when cost per request has climbed well above where it started and the early history no longer matters to the current task. Natural breakpoints, like a finished feature, are the best places to reset.

Is compacting the same as starting a new session?

No. Compacting summarizes the existing history and keeps working in the same session, so some context carries over. A new session starts from the base prompt plus whatever you load. Compaction is easier but keeps more tokens, and the summary can lose details.

Does a new session help on Cursor or Copilot?

Probably not on cost. Those plans charge per request, so context size does not change the price. A fresh session may still help the agent focus, which can mean fewer wasted requests.

How we source, write, and correct our articles. Editorial standards

Related articles

Straight to your inbox.
New pieces as they publish. No noise.