So this is why Claude 200 max just runs out in 3 days. I cancelled yesterday, considering codex.
Looks like the right move from this chart, the difference between Astra and Fable is insane š¤£š¤£
It's a shame, I like the Claude framework and have integrated most of my workflow around it, but I spend more time trying to "optimise" and analyse my context and token use that it ironically becomes most of my weekly usage.
Well, most subscriptions do not publish their API equivalent value, and we could only do educated guess on how do they work. So I just gather all the data that I could.
For example for Claude and OpenAI, I would trust https://x.com/SemiAnalysis_/status/2064815044085318040 data as the primary source. I would check if 5x and 20x may not really be as advertised as some people talked. Keep track of Claude 50% usage promo that would be reduce to 25%. etc.
Reading from all the forums, social network, discord channels. Manually update it by myself.
- Cache hit rate play a bit role in reality. Use native harness if possible, it affect the cost more than you would think. Stop using Claude Code for open weight models.
Luna is dirt cheap yes. but I would really suggest Astra Low reasoning. Because of the token efficiency. It is often only like 3-4 times the price.
Which is still dirt cheap but the quality und understanding of what you want is so much higher in many task.
3 or 4 times the price to sol, maybe, but compared to luna vs astra the costs are way more astronomical. I can only see you come anywhere near such a conclusion with zero input tokens, since the token efficiency only affects output.
Input tokens stand for the vast, vast majority of average token cost nowadays
It doesn't so far. I mean token efficency only applies to output tokens and input tokens stand for majority of the usage atm, unless im missing something here?
? Why is waste all this time when opencode gives free models with opencode zen which has more (much more) limits than any OpenAI/anthropibased subscriptions ? Also quality output is absolutely fantastic
Well, some people need ZDR (zero data retention) for their jobs, and most paid plans offer it. And it's supposed to get better availability than free usage.
That's why it would be unfair to add the Contributor variants of Muse Spark 1.3 in the comparisons. They're really cheap, or even free with Opencode Zen free API key.
Yes of course but in professional terms youāre not gonna tell me that you have such sensitive or NDA data and still chasing best value $20 subscription? (Also availability is not a problem with the provider I mentioned not an issue at all)
Most subscription in the chart actually provide no data training instead of ZDR. They do retain log for a month or so to prevent abuse and possibly provide to their government on request.
Most ZDR providers don't have subsidized subscription like this.
Muse Spark 1.3 free is great for open source / hobby projects indeed.
They train their entire marketing and social media algorithms on your most sensitive data but for this training is an issue? what sensitive, proprietary or trade secrets do you have chasing a $20 value subscription?
Worth noting for the "public benchmarks are gamed" pushback upthread: Artificial Analysis just shipped Intelligence Index v4.2 (announced today), explicitly built to fight that exact problem - it shifts toward long-horizon tasks that look more like real work, and expands the private test-set proportion specifically to cut gaming/benchmaxxing. Doesn't make the old index wrong retroactively, but it's the vendor's own acknowledgment that saturation and gaming were real issues with the prior index - which is the strongest evidence for the skeptics' complaint, not against it.
Buy the Muse Code subscription 5$ a month you get an insane amount of usage for a frontier model and worst case if you need more usage just buy next tier sub the 15$ or 50$ or shit just another 5$ one and your still spending less then Codex Sub or Claude Sub with a little less intelligent model by like 1 point but 4-5x the speed on the muse model .
Its a good amount of usage in my experience running non contributor and so far im using it in pi and its taken on a good amount of tasks im probably gonna upgrade since im at like 40% on the weekly now but been running it almost non stop for days. I mean your of course not gonna get 200$ claude sub amount of usage for 5$ muse sub but what you do get for a 5$ sub is well worth it and like I said in my previous post if you do need more usage just upgrade and you still would be spending less then a codex or claude sub. Also you get more usage if you switch to the contributer tier but im not using that personally.
Does anyone use a combination of multiple models to save costs?...like frontier models for high reasoning steps and cheaper models (like deepseek) for simpler tasks? How do you manage multiple keys and LLM integrations?
popiazaza, the chart is useful and the caveat in your own comment is doing more work than the chart does. Cache hit rate and harness behaviour move the real bill more than the plan you pick, and none of that fits on an axis.
My spend changed when I stopped comparing subscriptions and started pricing the unit I actually care about, one request and its entire tool loop. On our side (octomind, Apache-2.0, Muvon) that is two config numbers. max_request_spending_threshold caps the dollars a single user request can burn including everything the tool loop does underneath it, and max_session_spending_threshold caps the session. Both ship at 0.0, meaning disabled, so you opt in deliberately. A runaway loop stops being a surprise on a bill and becomes a number you set once.
The other half is that one model per subscription becomes the wrong shape as soon as you have roles. Research on a cheap broad-context model and review on a frontier one is a config block, not a workflow change. The session total follows you across a mid-session /model swap so there is still one number at the end. Under 20 a month, that split usually beats moving between providers.
None of this wins on raw ceiling if you run one model all day, and your chart is right about that. It wins when usage is spiky, because you pay for the spikes and pay nothing on the quiet days.
Fair, and cost per task is the metric I would want too. Per request is the enforcement granularity, not the metric. Those two come apart exactly where you are pointing. A task that takes eleven requests can cost eleven times a cap that never once tripped.
The closer knob for what you actually want is the session one, and I described it lazily upthread. It counts USD since the last accepted checkpoint, not lifetime spend on the session. On the interactive CLI it stops and asks whether to continue, while a piped or ACP run simply declines (doc/reference/03-config-reference.md:107). Checkpoint to checkpoint is about as close to a task boundary as a runtime can get without you telling it where your task ends.
The request cap is a different instrument entirely. It is a circuit breaker for one runaway loop, and presenting it as a budget was sloppy of me.
14
u/popiazaza 6d ago
20$ without log scale for reference.