DEV Community: awesome fred

My Claude Code token log, week of Oct 19

awesome fred — Mon, 19 Oct 2026 00:05:42 +0000

Numbers only, measured from my own local Claude Code session logs (2026-10-12 to 2026-10-18, 7-day daily average).

Calls per day: 2,772
Cache-read tokens per day: 315M
Output tokens per day: 2.4M

Share of cost by slice:

Slice	Share of cost
Base (system prompt + tool list)	43.3%
Model replies	25.5%
User input + attachments	21.6%
Shell command output	6.1%
Subagents	2.1%
File reads	1.2%
Search (grep/glob)	0.1%
MCP + other tools	0.1%
Web fetch	0.0%

Cost weights: input 1, cache write 1.25, cache read 0.1, output 5 (input token = 1).
Takeaway: the biggest slice is the fixed context that gets re-read on every call, so shorter sessions help more than trimming tool output.

Where my Claude Code tokens actually go: 7 days of logs, and why tool output isn't the problem

awesome fred — Wed, 14 Oct 2026 10:30:56 +0000

A few days ago I tested three Claude Code token-saving tools, and all three raised my cost. So this time I stopped testing tools and measured where my cost actually comes from.

How I measured

My local Claude Code session logs, numbers only, 7 days (about 4,400 model calls per day)
Cost-weighted tokens: input 1, cache write 1.25, cache read 0.1, output 5

Where it goes

Where	Share of daily cost
Cache reads (re-reading context every call)	66%
Cache writes	18%
Output	15%

The average call carried about 184K tokens of context. Calls with more than 200K were 56% of the cost.
The median session starts at about 62K tokens before I type anything (system prompt, instructions, tool and skill lists).
Cache breaks cost 6.5%. Three quarters of that came after a gap of more than 60 minutes.
Command output was about 6.8% and file reads 2.6%. That's why compressing tool output didn't help me.
Moving bulk work from subagents to plain scripts cut subagent cost by 78%.
My manager session (the one that coordinates other sessions) costs 11.3% per day. My hooks cost 0.8%.

Replaying my real calls with different habits

Rule	Upper bound	Expected (half, for re-reading)
`/clear` + short handover when context passes 150K	−29.0%	about −14%
Start fresh after a gap of more than 60 minutes	−14.8%	about −7% (overlaps with the above)
Trim the always-loaded context from ~62K to ~32K	−9.4%	about −5%
All three	−42.6%	about −21%

I keep auto-compact off and use /clear with a handover note, because a compacted conversation can't be undone.

Full numbers: https://github.com/awesomefred0827-hash/claude-token-log/blob/main/FINDINGS-2026-10-08.md

Questions

When do you /clear: at a token count, at a task boundary, or after a break?
Has anyone measured how much re-reading a fresh session needs after /clear? That decides whether my "half" assumption is too optimistic.

What my one-person OS handles now (3/3)

awesome fred — Sun, 11 Oct 2026 10:06:47 +0000

What it handles now:
schedule, social media, trend tracking, marketing, accounting, samples.
Accounting, clients, marketing... I still do it all myself.
The system does the heavy lifting
AI is the best. Seriously. (3/3)

accounting and samples too. All handled by me, through one system

Screens are from my own system. Client names and numbers are hidden.

From one order tool to a whole control room (2/3)

awesome fred — Sun, 11 Oct 2026 10:06:15 +0000

Then I kept adding one feature at a time...
and somehow it turned into a whole OS
This is the control room now. Everything runs through here. (2/3)

Screens are from my own system. Client names and numbers are hidden.

I run my whole business alone, so I built my own OS with Claude Code (1/3)

awesome fred — Sun, 11 Oct 2026 04:25:45 +0000

I handle accounting, client management and marketing all by myself. 30 clients.
Keeping track of every order by hand was eating my whole day.
So the first thing I built was an order automation system.
That's how it started. (1/3)

Screens are from my own system. Client names and numbers are hidden.

"Token-saving" tools made my Claude Code usage go up. Here's the measurement.

awesome fred — Wed, 07 Oct 2026 08:55:04 +0000

I kept hitting Claude Code's weekly limit, so before keeping any token-saving tool I now measure it on a fixed task set.

How I measured

5 fixed tasks: fix a bug, scan a log, check git changes, summarize a CSV, summarize test results
3 runs per task, same day, same test repo, claude -p --output-format json
Cost-weighted tokens = input 1, cache write 1.25, cache read 0.1, output 5
Answer quality counted as part of correctness

Results

Tool	What it does	Cost-weighted tokens vs baseline	Correct
rtk v0.51.0	compresses shell output via a hook	+7.1%	15/15
caveman v3.1.0	makes replies ultra-terse	+10.9%	15/15
pxpipe v0.14.0	renders bulky context as images via a local proxy	+196.7%	15/15

Why all three went up

Fewer tokens per step can mean more steps. rtk trimmed output by ~63%, but Claude ran extra commands to see what was cut. Each turn re-reads the context, so cache reads rose 19%.
Anything added to the system prompt is paid on every call. caveman's rules (~2,900 tokens) cost more than the 12% output it saved.
Images are not free. pxpipe's rendered context cost more than the original text; cache writes on the first call went from ~27K to ~102K.

Where my tokens actually go

About 42% of my cost is the always-loaded context (system prompt, instructions, tool list). Command output is about 6%.

Raw numbers and method: https://github.com/awesomefred0827-hash/claude-token-log

Next: vendor and patch

I'm thinking of vendoring all three (pulling the source and patching it myself):

rtk: keep error lines uncompressed
caveman: one "be brief" rule, no skill list
pxpipe: compress only past a context-size threshold

What do you think? Would these patches work, or would you fix them differently? I'll re-test whatever you suggest and post the results.