The Session That Never Ends

TL;DR

• Part 1 found skills looping on the same fetch, a project re-sending two big CSVs on every turn, and six people building the same email triage. We spent the month fixing those and coaching the heaviest users, and the September problems moved.
• With the loud problems quieter, the biggest one left is easy to see: 52 percent of October's bill was long-lived context, sessions and chats kept open for days and reused for each new task.
• 26 of the 30 longest-open sessions ran on Sonnet. Switching models wouldn't touch this; it's a habit, and the fix is giving people somewhere cheaper to keep their context.
• The scripts that found it are open source at HGInsights/claude-consumption-analysis. I share the relevant parts below.

---

Half the bill is old context

Part 1 was a diagnosis; the month after was treatment. We fixed the skills that looped, split out the oversized project and sat down with the heaviest users. October shows it: no project among the top spenders carried more than 50k tokens (one re-sent 520k on every message in September), and repeated tool calls now cost roughly 5 percent of the bill.

With those quieter, pulling cost data across all 115 people with spend made the next problem hard to miss. Analytics breaks spend down by how big the context was on each request. October split like this:

Context per request	Share of requests	Share of spend	Cost per request
Under 200k tokens	69%	48%	$0.056
200k to 1M tokens	31%	52%	$0.135

Under a third of the requests produced over half the bill, at 2.4 times the price each.

The mechanism is simple once you see it. A model has no memory between requests, so every message re-sends the entire conversation so far: every earlier message, every file read, every tool result. The toolkit's README puts it in one line:

text
billed_input = Σ over assistant turns i of ( overhead + Σ tokens of turns before i )

That makes cost quadratic in conversation length, not linear. Day one of a session, the history is a few thousand tokens. Day nine, it's 400,000, and you're paying for all of it to ask "can you tighten the second paragraph?"

Prompt caching softens this but doesn't remove it. Cached reads are cheap, but writing to the cache costs more than plain input, and caches expire after an hour at most. Come back to a session after lunch and the whole history gets written again at full freight. Of the long-context spend, 47 percent was cache writes and 39 percent cache reads. The model's actual output was about 13 percent.

By surface, about 59 percent of the long-context money came from Cowork, 23 percent from chat and 18 percent from Claude Code. This isn't confined to engineers; it shows up everywhere people work.

---

Nobody is on the wrong model

The obvious first check is whether someone's running Fable on a three-week-old session. So I pulled the 30 longest-open sessions and read their shape.

• 369 sessions across the org stayed open more than a day; 102 stayed open more than a week. The longest ran 28 days.
• The median long session was active on 21 percent of the days it was open. It sits idle, then gets picked up for the next thing.
• 16 of the 30 grew past 200k tokens of context.
• 18 of the 30 were resumed after more than an hour idle while carrying over 100k tokens.
• 26 of the 30 ran on Sonnet.

These are people on the sensible default, doing a reasonable thing in an expensive way. A model policy wouldn't reach them.

Why people do it

The data fits one explanation: the session is their memory. It holds the account history, the decisions, the half-finished draft and the three files they uploaded last Tuesday. Closing it means rebuilding all of that, and rebuilding feels like work.

While I was writing this, someone on our RevOps team sent me the question in their own words. Claude Code kept telling them "/clear to save 779.9k tokens," and they wanted to know what that meant and "how can I actually save them without losing the context of the project that I'm working on?"

That's the individual version of the part 1 conclusion. Part 1 said our team has no shared memory. Each person, it turns out, quietly built a private one, and it's the most expensive memory available: a context window re-billed on every message.

Session age is the wrong flag

The obvious admin move is to hunt for sessions open longer than a week. I tried it. Among users spending over $50, the share of their spend that's long-context and the number of sessions they kept open past a day don't correlate at all (r = −0.08).

Eleven of the 39 most long-context-heavy users never kept a session open for a day; eight of them work in chat. One person spent $342 in October across four chats, averaging 488k tokens per request, with 95 percent of their spend in long context. No marathon session, just four conversations that never changed topic.

So target the dollars, not the clock. Analytics tells you each person's long-context share; that's the list. Our top nine run between 62 and 95 percent.

---

How to end a session without losing it

Here's the answer to that question, written for people who aren't engineers.

What the number means

That hint is Claude Code telling you how much history the session is carrying: 779.9k tokens. Every message you send re-sends all of it, and so does every step Claude takes on its own while it works. A task that "crunches for five minutes" can be dozens of those steps.

On Sonnet, re-reading 780k tokens from a warm cache costs about 16 cents a step. Come back after the cache has expired and the first step pays nearly $2 just to load the history again. Clearing doesn't save 780k tokens once; it saves them on every step that follows.

Move the memory out of the session

The fix is to keep the context somewhere that doesn't get re-sent: a short file that Claude reads when it needs to. The routine is the same everywhere:

1. Before you switch tasks, ask for a brief. "Update brief.md with where we are: the goal, what we decided and why, current state, open items, where the files are. Keep it under a page."
2. Clear, or start a new session.
3. Open the next one with "Read brief.md, then..." and the new task.

Here's roughly what a brief looks like:

markdown
# Q4 renewal: Acme
Goal: renewal proposal to their CFO by 14 Nov.
Decided: lead with usage growth, not discount (CFO pushed back on price in Sept call).
State: draft v2 in /drafts, pricing table still open.
Open: confirm seat count with their admin; legal redlines pending.
Files: /calls (3 transcripts), /drafts, /pricing.xlsx

That's a few hundred tokens doing the job a 780k-token session was doing. Claude reads it, opens the one or two files it needs, and starts from a clean context.

Where things live depends on the surface:

	The brief	Standing instructions	Starting fresh
Cowork	A file in the project folder	Project instructions	A new session in the same project
Claude Code	A file in your working folder	CLAUDE.md, loaded every session	/clear, or a new terminal tab
Chat	A five-line summary you paste	Project instructions	A new chat

In Cowork, give each recurring area of work its own project (folders, instructions, links and memory carry over to every new session inside it), and keep its instructions to one line: read the brief first, update it before finishing.

Three habits cover most of it:

• New task, new session. Two terminals for two tasks is the right instinct; the trick is not letting either one run for days.
• Back after more than an hour? Start fresh from the brief rather than picking the old session back up.
• Mid-task and can't stop? In Claude Code, /compact summarises the history in place and carries on with a smaller context. It's a reasonable fallback, but you don't choose what the summary keeps. A brief you asked for, you can read.

---

Find it in your own org

Everything above came out of claude-consumption-analysis: standard-library Python, no dependencies, Apache-2.0. Here are the parts that matter for this post.

Step 1: the dollars, with no content read

Analytics prices every request into a context_window bucket, and 200k is the boundary. So the long-context share needs no transcripts at all, only cost rows:

python
def is_long_context(window):
    """True for any Analytics context bucket above the 200k boundary."""
    w = (window or "").lower()
    return bool(w) and not w.startswith("0-")

# summarise_cost(), trimmed
for r in rows:
    by_ctx[r["context_window"] or "unknown"] += r["amount"]
total = sum(by_ctx.values())
long_ = sum(v for k, v in by_ctx.items() if is_long_context(k))
share = long_ / total if total else 0

Run it across the org with python3 org_scan.py --days 30. You get the org split, every user's long-context share, and a ranked list of who to talk to first. This is the step most orgs should stop at; it reads cost data, not conversations.

Step 2: the shape, if you have sign-off

To see why sessions are long, the script reads timestamps and sizes from the longest-open sessions (--transcripts --deep 30). The core of it is a resume check: a turn that comes more than an hour after the last response has outlived the cache, so if it's carrying a big history, all of that gets re-sent.

python
# Past the longest cache TTL (1h), a resume re-sends the full prefix uncached.
IDLE_RESUME_SECONDS = 60 * 60
# An idle resume only matters if there is a lot to re-send.
STALE_RESUME_TOKENS = 100_000

if role == "assistant":
    ctx = min(running_tokens, CONTEXT_WINDOW_MAX)
    peak_context = max(peak_context, ctx)
    if ts and last_assistant_ts and \
            (ts - last_assistant_ts).total_seconds() >= IDLE_RESUME_SECONDS:
        idle_resumes += 1
        if ctx >= STALE_RESUME_TOKENS:
            stale_resumes += 1

Content is measured in memory and discarded; only the shape is kept. The sizes are approximate (the script says so and caps them at the 1M window), so use them to rank sessions, never to price them. Dollars come from Analytics only.

---

What I don't know yet, and what's next

The ceiling first. If every long-context request in October had cost what a short one does, we'd have saved close to a third of the bill. We won't get that. Some work genuinely needs a big context: a long contract, a gnarly codebase, a multi-day investigation. The real recovery is a fraction of the ceiling, and I don't know which fraction.

I also can't tell how much of the cache-write line is avoidable. Some writes are unavoidable (every new tool result has to be cached once); some are pure waste (re-writing a three-week history because the cache expired over the weekend). Analytics doesn't separate them.

And one RevOps question isn't a survey. "To keep context" fits the data, and it's what our RevOps colleague asked about, but the toolkit's own rule is to interview your top spenders before drawing conclusions from their data. Two or three more conversations come before any rollout.

What I am doing: walking the nine heaviest long-context users through the project-plus-brief setup this month, then re-running the numbers in December. Long-context share was 52 percent in October. If the habit change works, that number moves, the same way the September ones did.

Long context isn't the only thing left. A third of the bill is premium models, some of it on versions that now cost more than their successors and can be switched off in an admin panel the same day. A tenth of all sessions were scheduled jobs, including forty personal briefings and digests that are close to the same job built forty times. And the duplicate calls that remain mostly land on connectors we built ourselves. That's part 3.