The Computomatix Times

For 90 days I logged every single Claude Code session: timestamp, prompt, response, token count, model, exit reason.
430 hours of work. 6 million input tokens. $1,340 in API spend.
Then I sat down with the data and asked the only question that mattered: how much of this was actually doing my work, and how much was overhead?
The answer was uncomfortable: 73% of my tokens went to nine invisible patterns that I'd been doing on autopilot.
Not bad prompts, I write decent prompts.
Not big models when I needed small ones, I knew that one already.
Patterns deeper than that. Patterns nobody talks about because they're invisible until you instrument them.
If you're hitting Claude Max usage limits more than once a week, you have at least 4 of these. Probably 7.
Below: each pattern, exactly how much it costs, and the 30-second fix.

Why this matters now
Anthropic admitted the problem in late March 2026: "people are hitting usage limits in Claude Code way faster than expected."
Max 5 subscribers reported quota exhaustion in 19 minutes instead of the expected 5 hours.
The Pro $200/year users said the limit maxed out every Monday and didn't reset until Saturday - "out of 30 days I get to use Claude 12."
Anthropic acknowledged the issue. The peak-hours quota change in late March explained part of it. The rest was a prompt-caching bug — two independent bugs in the cache layer that silently inflated costs by 10-20x for some sessions.
A user reverse-engineered the Claude Code binary to find it (GitHub issue #40524). Downgrading to v2.1.34 helped some people.
Some of it is real. Most of it is you.
I'm not going to tell you to "use Haiku for simple tasks" or "start a new chat every 15 messages."
Below: the patterns that the obvious advice misses.
The methodology
I ran an HTTP proxy between Claude Code and the Anthropic API. Logged every request: full payload, response, token counts (input/output/cache), latency, model. 90 days. 430 hours of active work.
For each request, I categorized the tokens into:
Productive — content that directly informed my actual question
Cache hit (free) — system prompt + CLAUDE.md cached, no marginal cost
Cache miss (paid) — same content, recomputed because cache expired
Conversation history re-read — re-tokenizing previous messages on every turn
Hook injection — pre-pended context from PreToolUse / UserPromptSubmit hooks
Skill loading — skill SKILL.md content loaded into context for invocations
Tool use overhead — JSON schemas, tool definitions, tool result blocks
Extended thinking — <thinking> blocks
CLAUDE.md — project rules loaded every turn

Productive tokens: 27%. The other 73% is the 9 patterns below, ranked by how much they cost me.
Pattern 1. CLAUDE.md bloat (~14% of total tokens)
The pattern: my CLAUDE.md grew to 4,800 tokens over 6 months. Every turn loaded all 4,800 tokens. Every session loaded them again on each new request. Most of the rules were never relevant to the task at hand.
A 5,000-token CLAUDE.md costs you 5,000 tokens before you've typed a word. Every turn. Every session. A constant baseline tax. Multiply by 200 turns per week and it's 1 million tokens a week of your CLAUDE.md alone.
The 30-second fix:

If you're over 1,500 tokens combined, refactor:
Move framework-specific rules to project-level CLAUDE.md (only loads in that project)
Extract repeated patterns into skills (loaded only when invoked)
Delete anything you can't remember writing
Convert "explain why" verbose rules into 3-word imperatives
I cut mine from 4,800 to 900 tokens. Same behavior. 31% reduction in baseline cost, instantly.
Pattern 2. Conversation history re-reads (~13% of total tokens)
The pattern: every follow-up message re-tokenizes the entire conversation history. By message 30 in a chat, each turn is paying for messages 1-29 to be read again. The math: at ~500 tokens per exchange, message 30 costs 30× message 1.
I had sessions with 60+ messages. The last message was costing 60× the first. Tokens spent re-reading old context: catastrophic.

The 30-second fix:
Edit the prior message instead of follow-up. Up-arrow -> edit -> re-send. The bad exchange gets replaced, not stacked.
Hard cap conversations at 20 messages. When you cross 20, ask Claude to summarize what's been done and start a fresh chat with that summary as the first message.
Use /compact instead of /clear when you need continuity. /compact summarizes and restarts. /clear nukes everything.
I went from 60-message sessions to 15-message average. 40% drop in conversation re-read cost.
Pattern 3. Hook injection waste (~11% of total tokens)
The pattern: I had 4 plugins installed. Three of them registered UserPromptSubmit hooks that injected context. Combined: 6,200 tokens of hook injection on every prompt I submitted, before Claude even read what I asked.
These hooks are designed to be helpful. They inject branch names, recent file changes, instinct summaries, memory snippets. Each one is small. Together they're a wall.
The 30-second fix:

Aud… continue on X ↗

I built an AI app that runs completely on device. No servers, API requests, or data leaving the device. Local models are finally getting good. Just look at the recent releases from @Alibaba_Qwen and @googlegemma to see that the gap is shrinking.
x.com/Alibaba_Qwen/status/2046939764428009914
I am excited about what this unlocks for hardware, consumer, and privacy.
Robots and edge devices can't rely on perfect signal for their user experience. A robot working in a farm, a construction site, or even a living room can't just freeze up the moment it loses connection. Smart glasses and similar devices running local models have lower latency and much better UX.
For consumer apps, local LLMs make free tiers economically viable. Growth at all costs becomes very expensive when every user burns GPUs on your dime. Local inference flips that math.
@signulll is clearly facing this now:
x.com/signulll/status/2044097057825124430
The third vector is privacy. I have mixed feelings here. Anecdotally, most of my friends don't care where their data goes. My guess is, in the future, privacy-sensitive fields like law and medicine will require on-device or on-prem models to stay compliant. Users won't care, but regulated professionals will.
The hardware is already here. We're all walking around with phones that can comfortably run 2B-parameter models. So I wanted to see how far I could push that with a real app.
Ambrosia
I built Ambrosia, an offline AI journaling app to track how my skin responds to different diets and products. I picked skin specifically for two reasons: I've always wanted a better way to watch conditions and progress over time, and photos are a natural unit of a journal entry.
Two things I love about the app:
1. AI-generated labels and trend tracking, all local
2. Everything including the images stays on device
The Base Model
I went with Qwen3-VL-2B: multimodal, small enough to run on my iPhone, and already well-optimized for llama.cpp. I used the Q4_K_M quantized version from @huggingface, and ran everything through @RunAnywhereAI because their on-device SDKs are the best I've used.
Finetuning the Model Locally
I wanted to prove that I could take a base model and finetune it end-to-end locally on my MacBook (M2 Max).
With Codex, I trained a small LoRA adapter on MedQA, then merged and exported it back into the same Q4_K_M GGUF format so that it would work on my iPhone.
I also experimented with autoresearch (@karpathy’s autonomous framework for model training) to maximize performance. I gave Codex the source code and let it sweep configurations. The sweep landed on a lower learning rate (1e-4) as the winner, beating baseline by ~5 points on the micro-run. Scaled up to full validation, it held at 47.88%.

Finetuned Model: huggingface.co/amankishore/qwen3-vl-2b-medqa-gguf
Constraining the Task
Initially I built Ambrosia as a chat first experience. It was bad. I would document a new skin issue, and the model would respond with three long paragraphs about consulting a dermatologist.
I constrained the task. Qwen was much better at generating labels from images and analyzing trends across journal entries. Ambrosia went from a worse medical ChatGPT to a journal with ambient AI trend analysis.
This is why small models are underrated. They should not be compared to general assistants like ChatGPT. They're much better as narrow specialists constrained to a few tasks.
Since this task is disjoint from MedQA, I built a small eval set of journal entries a user might track (acne, texture, redness, etc) and compared the finetuned model against the base. The finetune gave a small but real lift on label quality, while trend analysis was unchanged. For a 2B model doing a task it wasn't trained for, I'll take it.

Edge Intelligence
Ambrosia was a small experiment, but it maps to the shape of the future: take a small base model, aggressively constrain the domain, tune for your specific task, ship it. Repeat.
Chips keep getting faster. Small models keep getting smarter. Eventually these lines will converge. When they do, you’ll have the power of AGI, in the palm of your hand.

I've 2x’d my productivity as a VP of Product @mercury by creating a "Second Brain" using 5 years of work history, 15k docs with 3.5 million words, and every tool in my stack. It runs locally, is a core part of my every use of LLM, and gets better everyday.
Today, I want to share the stack, the workflow, and the prompt to build it:
Background
I am a VP of Product for @mercury, which is a long way of saying I'm in a lot of meetings, consuming a lot of content across different tools (linear, slack, notion, data analyses), and trying to make sure I actually get stuff done. Working at a company for 5 years and being an information addict, I am essentially a walking encyclopedia for Mercury post 2021-today -- but I've recently found that my scope + workload means I can't keep every plate spinning.
One day, I was scrolling X and came across a series of posts that caught my attention, starting with @tobi's QMD. QMD is a local vector search, and then a few other posts started to show up that connected a few dots for me:
Claude Code launched hooks (per-event prompt injections)
GasTown / OpenClaw launched with the power of orchestrators writing memory + delegating to sub-agents (among many other patterns)
MCPs/CLIs hit a critical mass, and enough of my core tools were available without having to ask admins to give me API keys
@tylercowen did an interview and talked extensively about "writing for AI" in a way that struck a chord - how much output of work already exists that I'm not using?
I decided that it was time to build
Prep work (~1-2 hours end to end)
To start, I needed a library of all the content I could know about... so I downloaded every document I've ever created for my job at Mercury + any relevant product strategy, analysis, retro, reflection on execution, etc. This netted out to over 15k documents and 3.5 million words. Maybe I've read them all, but I've forgotten most. These became a folder that I just called "raw data", and I ran QMD to index this on my computer.
To see if this worked, I used Claude Code to ask about random memories and surprising insights from this knowledge base - the amount of delight/surprise I experienced in seeing how much more capable vector search was than text-based search gave me the confidence to keep going. I asked one questions about books that it would think I like, and it was spooky how good of recommendations it gave me. I think this is my best advice in this journey: test every step of the way! Easy to get caught in hill climbing a local maxima
Train my brain and connect it to my tools (~2 hours)
With all the raw data, I needed to help it make sense of me + what my goals are + the tools I used, so pursued three paths:
Explain myself - to be able to create a second brain, it needed to know what mine was doing. I wrote up a me.md explaining who I am (work + life), gave it my goals + performance reviews for the last 5 years + set of personal priorities. The most humbling part was the system pointing out that I've been making the same strategic mistake for years, according to my own performance reviews, and was making it that week as I was setting up the system
"Distill" the data - I spun up an agent team to use the me.md + the knowledge base to create a set of docs between me <> raw knowledge base. This idea largely came from the idea that LLMs regularly distill down smaller models to take tasks, and I had no idea if it would help me in this, but Agent Teams had just launched and so I had a swarm of them find the main "themes" we've worked on from the knowledge, give sourced histories of this, and summarize key lessons. These created a context.md folder
Tools - I use a few tools (Google Docs, Linear, Notion, Metabase) , and luckily most have connectors on Claude Code or these companies are actively launching MCPs/CLIs. A few didn't, but I spun up specific skills that crafted direct API calls to be able to complete tasks like "run a query for XYZ".
Claude had access to all the information about me + the tools I used + had a massive library of all my work, but did it really know anything? Does anyone?
Wire it up (<1 hour)
At this point, I had so many words + documents that it was time to actually find use or abandon ship. But I didn't want to have to go search this every time and that's when "hooks" caught my attention.
Hooks from Claude Code let you insert content into your prompt without needing to ask (or when a session starts, after a tool use, or when a session stops). Using the UserPromptSubmit hook, I enabled my Claude Code to use qmd to find names + topics + specific documents related to my prompt.
This is a nerd-out moment, but when searching for files in Finder, it is mostly a name + raw text search.... but QMD can help bring context into searches. My system is tuned to figure out a query, then returns results using one of two techniques:
vsearch (semantic/vector) — understands meaning of my question. "How's the funnel performing?" finds … continue on X ↗