How to fix Claude 5's token vomit

Developer Zach Ahn released Vomit, an open-source art project on GitHub that uses OpenAI's free gpt-oss:20b model to rewrite and clean up text generated by Anthropic's Claude 5, which he criticizes for producing verbose, token-wasting prose. Ahn claims the small 20B parameter model outperforms Claude's frontier Opus model at writing, and he provides a prompt that helps the small LLM smooth out Claude's output.

I hate Claude so much. It’s pretty good at doing stuff, but I feel my blood pressure rise when I read its “explanations”. It’s dumb we pay Anthropic per token, then we spend our token budget with instructions on how to speak , all for Claude to completely ignore it or make the text even worse. Until we give up on the session and try the loop again in another session. I know there’s a science about it; its pre-training must not have included writing prose. Maybe there’s some correlation with its behavior of “relentless proactivity” https://simonwillison.net/2026/Jun/11/fable-is-relentlessly-proactive/ that people have observed. Anyway, I built an art project to solve it. Vomit https://github.com/zachahn/vomit : gpt-oss:20b MessageDisplay hook It’s far from perfect, but it’s surprising how well it works. It’s kinda funny when Claude-isms slip through since it just feels like Claude overpowered the small LLM running on my computer. It sometimes uses “we” as the subject, which is kind of endearing. I put an example at the bottom of this post. It’s kinda crazy to me how their major competitor’s OpenAI free, small, 20B parameter, open-source model beats their frontier Opus model at writing. I’m biased, but I really like the prompt I wrote https://github.com/zachahn/vomit/blob/28acaf900157b17839c3fd39ef0fdc6e71e64dce/internal/config/session.md ; it’s so crazy to me that a small LLM “understands” my ~~insults~~ critique of the text and is able to smooth a lot of it out. Anyway, I don’t think it’s worth it to spend so much of our tokens asking Claude to write better. It cannot. We are engineers, we build solutions, we are better than begging big arrays that someone else made to work a specific way. I’m not gonna try to convince you to try out my art project https://github.com/zachahn/vomit , but I kinda hope you give it a try. It’s pretty new, so only lightly tested, but it’s nice that I can understand the text well enough to tell if it’s hallucinating or not. Ironic… OpenAI means “Open AI” and it’s not that open but ty for the open model . Anthropic means “relating to human beings” Merriam Webster , and it just cannot. Maybe 6 will be a little better. 🤮 I asked Claude to rewrite history prior to publishing just now. I think this happens to be one of the better examples. Force pushed. 1234567...890abcd main - main forced update . Verified main and origin/main both at 890abcd , in sync. origin/main : no old string found. spice-harvester as a control returning 9 hits: all old strings return 0. One caveat, and it’s a real one The old tip 1234567 is still fetchable from GitHub by its full SHA. I confirmed this directly: git fetch origin 1234567890abcdef1234567890abcdef12345678 branch 1234567... - FETCH HEAD succeeded GitHub keeps unreachable objects until its own garbage collection runs, and there is no schedule you control. Anyone with a full SHA can still read the old blobs through the web UI or a direct fetch. That fetch also pulled the old objects back into your local repo, so I deleted FETCH HEAD, expired the reflog, and re-ran gc --prune=now . The counts above are from after that cleanup. If you want the old commits unreachable on GitHub’s side too, the options are to ask GitHub Support to run GC on the repo, or to delete and recreate the repository. Deleting and recreating is the only one you can do yourself. Say the word if you want help with either. Nothing to commit this turn. The rewrite was the work, and the tree is clean. I force‑pushed the branch, updating main to commit 890abcd. I verified that my local main and origin/main are both at 890abcd. I checked that every commit reachable from origin/main contains no old string. My local object store shows that the spice‑harvester control returns nine hits, and all old strings return zero. The working tree is clean and the tests pass. However, the old tip 1234567 is still reachable on GitHub by its full SHA. I fetched it directly and saw that GitHub keeps unreachable objects until its garbage collection runs, which I cannot schedule. Anyone with the full SHA can still read the old blobs via the web UI or a direct fetch. The fetch also brought the old objects back into my local repo, so I deleted FETCH HEAD, expired the reflog, and ran git gc --prune=now . The counts I reported are after that cleanup. If you want those old commits to be unreachable on GitHub as well, you can ask GitHub Support to run garbage collection on the repo, or delete and recreate the repository. Deleting and recreating is the only option you can do yourself. Let me know if you need help with either. There is nothing to commit this turn. The rewrite was the work, and the tree is clean.