Comment by sieve

5 hours ago

My OpenCode Go stats for the last 30d:

Cached Read: ~6,500M

Input: ~150M

Output: ~20M

Approx $40 worth of usage across DeepSeek V4 Flash + MuseSpark Contributor 1.3. And a bit of both the GLM models. This is covered in a $10 subscription.

If I were to use Luna's API pricing:

$0.02 x 6,500 = $130

$0.20 x 150 = $30

$1.20 x 20 = $24

So $184. And this is assuming smaller coding sessions (<272K) beyond which Luna pricing doubles.

--

Cost wise, these models are nice for small stuff. Translations etc. Any model that does not provide multiple Mtoks of cached reads per cent is not very useful to me for coding workflows.

This isn't right. You're comparing cost per token, but DeepSeek V4 Flash uses more tokens. Artificial Analysis found GPT 6 Luna to be significantly cheaper than DeepSeek: https://artificialanalysis.ai/models/comparisons?compare=dee...

  • I do not (generally) trust benchmarks. I only trust what a model does with MY code.

    Forget DS. I asked MiMo 2.6 yesterday to explain ML/LLMs to me succinctly and the pointed it at Karpathy's micrograd code. It produced a C implementation called `xor_mlp`, a tiny model that learnt how `xor` worked. I then asked it to produce a model that can play tictactoe without losing (mostly). It did. It supervised the training process and produced a compiled version with multiple switches. The pi-dev session is still running, so here are actual stats

    ↑45k ↓35k R1.0M CH99.4% $0.019 4.2%/1.0M (auto) - (opencode-go) mimo-v2.6-flash • high

    And here is Luna on the same workflow (I had to poke and prod a bit to get what I wanted):

    ↑141 ↓34k R1.0M W43k CH95.3% $0.072 4.2%/1.1M (auto) (opencode-go) gpt-5.6-luna • high

    I expect similar results from DS41F/MS13. Closer to MiMo costs than Luna.

    So the "significantly cheaper" thing may not really hold, more so when Luna has to actually read my codebase to do the stuff that I want rather than rely on world knowledge. The 8-10x cache read cost differential itself will kill the token budget.

  • Artificialanalysis benchmark is a combination of a several benchmarks which might or might not represent realistic coding:

    "Artificial Analysis Intelligence Index combines performance across 10 evaluations: AA-Briefcase v1.1, GDPval-AA v2.1, AutomationBench-AA, Terminal-Bench 4.0, SciCode, Humanity's Last Exam, GDP.pdf, CritPt, AA-Omniscience, and AA-LCR v1.1."

    Not saying it doesnt have any value but it's probably irrelevant if you use these AIs for a specific use case. Like for example Humanity Last Exam tests general knowledge, which is not very useful for coding.

    It's best to go to the specific coding benchmarks and compare there.

It’s not direct token to token pricing and everyone misses it. The cost is how much tokens to complete something multiplied by token pricing. I can have a model at .0001 per million tokens but it’s so inefficient that it takes 10B tokens to complete a task means it’s expensive.

  • I am not designing rockets. Most of my work is bog standard hobbyist stuff: compilers, vms, sandboxes, system tools of various kinds, SSGs, markup languages, plain text ledgers etc. Even Gemma/Qwen running locally can manage this.

    Frankly, I have no idea what people do with Opus/Fable etc. I don't think anything I do needs something that charges $50/M for output tokens.

    • Can confirm. I have been using DeepSeek since forever and it's so good I was able to write a compiler and native desktop applications with it. I use it as a coding assistant in my IDE so the results end up at the same quality I would write by hand.

      I recently started a job that only uses Claude models. Opus and Sonnet are so slow you have no choice but to do multiple tasks in parallel. You create a git worktree, set off an agent to do something, another worktree, set out an agent - then play video games for 20 minutes until they complete the task (poorly).

      You can't really do "guide coding" like you can with DeepSeek-style flash models because Claude is too slow.

      I think the idea with slow frontier models is to end up with "software factories", where you just write tickets and send them to a harness that delegates work to agents/subagents. Your job is to prompt and review (and eventually just prompt).

      Mathematically and assuming token prices/efficiency remains constant, the collective US AI industry needs to increase token usage by 15x before 2030 (3.5 years from now) to satisfy investors. With companies already implementing token limits, the only place from here is for frontier models to replace staff entirely to expand budgets for tokens. The only way to do that is to demonstrate the efficacy of software factories and headless agentic workflows.

      Objectively, I have set up a software factory and I do see the utility of it, though I did it with DeepSeek and prices are 1% that of frontier models - which doesn't bode well for investors looking for an eventual return.

      Heck, my old M1 MBP 32gb running Qwen 3.6 35b a3b sipping 10w when generating tokens is good enough for a lot of my guide-coding work - it's just a bit slow so I use DeepSeek instead. When hardware prices come down, I honestly wouldn't see a need to subscribe to any service, I'd just grow my own tokens at home.

      1 reply →

These are also the orders of magnitude of our production agents for our business (NOT coding). Cache reads are so heavy compared to anything else that it's the only price point that really matters, regular input and output are negligible.

I need aggressive cache read pricing with full prompt_cache_key support to have a model be financially viable for our workload. Right now Meta Muse 1.3 Contributor is the only one that makes sense--but we are starting Evals on the new MiMo 2.6 class to see how it holds up.

  • I have used MiMo 2.5 extensively. MuseSpark and DS4 Flash are MUCH smarter than that one. But MiMo follows instructions diligently. So it has been useful as the implementer of a spec designed by Claude/Kimi.

    One good thing about MiMo that I experience on OpenCode is the provider seems to cache tokens for much longer than MS13/DS4F. I have seen cache being hit for close to an hour after the last request. The corresponding timing for MS13/DS4F is in the 1-5 min range.

    I am trying out MiMo 2.6 Flash as well.

  • Last I heard, caches had like a 5 minute TTL... doesn't that mean if you get up and make a coffee (hand pour over of course), that you are back at full price?

    • I wish that was more programmable.

      You can pay for higher cache time, you can pay for NVMe KV cache for an hour that can just be reloaded, etc., at a lesser tier you can pay for the KV cache to be stored on a network store (I guess I'm unclear if that last tier would be cheaper than recomputation, not even 100% sure of the NVMe with direct GPU<->storage DMA) depending on your model settings.

How can you compare a subscription which is most likely being subsidized with consumption pricing?

  • I gave you the $40 option. Which is what it would cost if you used APIs on OpenRouter or elsewhere. Still beats Luna by 4-4.5x

How have you found Muse Spark 1.3? It doesn't get much mention, despite pretty good benchmarks. I've been using a bit at home and find it quite good, often finding mistakes made by Opus 5.

  • MS13 is pretty sharp and has been my workhorse for the past month. It follows my coding style and commit/clean workflows referenced in AGENTS.md perfectly but has the habit of doing things without conferring with me (the Gemini problem). So you need some kind of instruction for that.

    It starts failing around the 5-600K context mark, but you can have it generate a handover document and continue in the next session.

    I would not use it at sticker price, but the Contributor version is priced just about right.

How long can OpenCode bleed for?

  • Are they bleeding? Their multipliers seem to be reasonable. They are not offering $60 worth of usage for $10 on every model, only some. In the case of the expensive ones, it is only $15.

    Given how subscription models work (not every one uses every last $ of their plan), they should achieve breakeven soon enough I guess.