The Computomatix Times

This is now also on the Claude Blog.

Markdown has become the dominant file format used by agents to communicate with us. It’s simple, portable, has some rich text capability and is easy for you to edit. Claude has even gotten surprisingly good at using ASCII to make diagrams inside of markdown files.
But as agents have become more and more powerful, I have felt that markdown has become a restricting format. I find it difficult to read a markdown file of more than a hundred lines. I want richer visualizations, color and diagrams and I want to be able to share them easily.
I'm also increasingly not editing these files myself, but using them as specs, reference files, brainstorming outputs, etc. When I do make edits, I’m usually prompting Claude to edit them, which removes one of markdown’s largest benefits.
I’ve started preferring HTML as an output format instead of Markdown and increasingly see this being used by others on the Claude Code team, this is why.
(if you want to start with some examples, you can see a bunch here: thariqs.github.io/html-effectiveness, just be sure to come back and read more about why)
Why HTML?
Information Density

HTML can convey much richer information compared to markdown. It can of course do simple document structure like headers and formatting, but it can also represent all sorts of other information such as:
Tabular data using tables
Design data with CSS
Illustrations with SVG
Code snippets with script tags
Interactions using HTML elements with javascript + CSS
Workflows using SVG and HTML
Spatial data using absolute positions and canvases
Images using image tags
I would go so far as to say that there is almost no set of information that Claude can read that you cannot fairly efficiently represent with HTML. This makes it a highly efficient way for the model to communicate in-depth information to you and for you to review it.
I’ve found that in the absence of being able to do this, the model may do more inefficient things in markdown like ASCII diagrams or, my favorite, estimating colors with unicode characters like in this screenshot from Claude Code.

Visual Clarity & Ease of Reading

As Claude is able to do more complex work, it is also writing larger and larger specs and plans. In practice, I've found I tend to not actually read more than a 100-line markdown file, and I certainly am not able to get anyone else in my organization to read it.
But HTML documents are much easier to read, Claude can organize the structure visually to be ideal to navigate with tabs, illustrations, links, etc. It can even be mobile responsive so you can read it differently based on your form factor.
Ease of Sharing
Markdown files are fairly hard to share since most browsers do not render them natively well. You often have to add them as attachments to emails or messages.
With HTML, as long as you upload the file (for example to S3), you can share the link easily. Your colleagues can open it wherever they wish and easily reference it.
The chance of someone actually reading your spec, report or PR writeup is much much higher if it’s in HTML.
Two-way Interaction

HTML can allow you to interact with the document, for example you might want to ask it to add sliders or knobs to adjust a design or allow you to tweak different options in the algorithm to see what happens. You can also ask it to let you copy these changes into a prompt to paste back into Claude Code.

Read more about my playgrounds post to see examples of this two way interaction: x.com/trq212/status/2017024445244924382
Data Ingestion
Why use Claude Code to make HTML files instead of ClaudeAI or Claude Design for example? One of the biggest reasons is all the context Claude Code can ingest.

For example, when writing this article, I asked Claude Code to read through my code folder and find all the HTML files I’ve generated, group and categorize them and then make an HTML file with all diagrams representing each type. The diagrams you see in this article are a direct result of that.
Besides the file system, Claude Code can find additional context using your MCPs (like Slack, Linear, etc.), your web browser (with Claude in Chrome), your git history, etc.
It’s Joyful
Making HTML documents with Claude is just more fun and makes me feel more involved and invested in the creation, and that by itself is enough.
How to Get Started
I’m a little bit afraid that people will read this article and turn it into a /html skill or something. While there might be some value in that, I want to emphasize that you don’t need to do much to get Claude to do this. You can just ask it to “make a HTML file” or “make a HTML artifact”.
The trick is knowing what you want the artifact to do and how you might use it. You may over time make a skill, but for now I’d suggest just prompting from scratch to get a hang of how to use it in different cases.
Use Cases
To make this more concrete, I’ve made many different HTML files for different use cases… continue on X ↗

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.