RussianCow

I said "most companies considering paying Anthropic", which is not the same as "most companies". I also don't agree that "nobody" is doing this; I have lots of anecdata suggesting otherwise. Maybe the majority of companies are using the easy option of Copilot or Gemini like you said, but it's nowhere near 99%.

It's not that weird. Most companies considering paying Anthropic are probably not considering Chinese models as alternatives. Many don't even realize they exist.

I said this in another comment, but Artificial Analysis has the cost per task of Haiku on max roughly equal to that of Sol on medium, and the latter is significantly more intelligent. (And I'd wager that Sol probably finishes tasks more quickly, even with Haiku inference being faster.) So Haiku really only makes sense on lower reasoning levels, and only if you care about intelligence and speed more than you do about cost effectiveness (where Luna currently dominates). And that's without even bringing Chinese models into the mix.

Except for the new MiMo V2.6 models, which appear to give some of the best value right now, at least on paper. (I haven't tried them so I can't speak from experience.)

The cost per task from Artificial Analysis is roughly 3x higher at every reasoning effort level for Haiku than Luna. Sol 6.1 on medium has the same cost per task as Haiku with significantly higher intelligence. According to those numbers (which you should take with a grain of salt), from a pure cost vs intelligence standpoint, you're better off using Luna for economics and Sol for intelligence.

With that said, the real reason to use Haiku is that it's faster than all of these models. OpenRouter is showing an average so far of 93 tokens/sec, and AA got at least 137 in each of their benchmarks. So it might be valuable for speed at lower thinking levels. (At higher thinking levels, it's likely going to take longer to produce results than Sol on low/medium.)

https://artificialanalysis.ai/models/releases/comparisons/cl...

Could you provide more details about your LLM + Beets setup? I've been thinking of doing something similar and figured Beets could help me organize the random piles of MP3s I have scattered around my drives, but I don't want to manually correct the ambiguities from incorrect tagging.

That number sounds about right, if a little low. According to OpenRouter, the weighted average input cost (which includes cache discounts) of GLM 5.3 is $0.2337 and the output cost is $3.291 per million tokens. If we assume 80% of the tokens are inputs, the cost of 450M tokens should be right around $300, which is the correct order of magnitude. And it depends highly on the provider(s) that the author is using, the ratio of inputs to outputs, etc.

It really makes you see how heavily subsidized the subscriptions are.

Edit: Fixed my math. Edit 2: I was looking at the wrong model on OR. Either way, the math is within the correct ballpark.

Not OP, but I've used both quite a bit and I think GLM 5.3 (non-flash) is a vastly better model. The flash variant is good for general workhorse agents, but it doesn't seem to reason holistically about code and over-engineers solutions to each specific problem it solves. But if you use GLM 5.3 to write a detailed plan with little to no ambiguity, GLM 5.3 Flash executes it just fine for a fraction of the price.

Interesting, I have roughly the opposite experience regarding speed: DeepSeek V4.1 Flash gets stuff done way more quickly for me than GLM 5.3 Flash. (I was getting 300+ tokens/sec with DS vs ~100 with GLM in my testing.) I agree that GLM 5.3 Flash is a slightly better model, but for me at least, it's not a huge difference, and I'd rather have DeepSeek's speed.

Every dev I've worked with hates Jira and yet it's by far the dominant project management system for software companies. Software devs don't have as much sway as you think at most companies. (I realize that the cost of switching from Jira is higher than the cost of switching LLM providers, but I think the point still applies. I've seen this same behavior with dev tools as well.)

> I thought openrouter just routes you to the same provider for the rest of the session, so that you keep hitting the same cache. Is that not the case?

Not in my experience. I need to explicitly set my preferred provider(s) for each model, otherwise it bounces me around even within a single session.

> You don't need SOTA. You need a model that can accomplish your task.

I completely agree about SOTA, but it's a big leap from "you don't need Fable" to "you can get everything done with local Qwen". As always, it depends. Most LLM users are better off with a subscription (or even API pricing) because they won't use AI heavily enough for the hardware to pay off. Then there's the power users who benefit from larger models (software devs, for example). You can argue that there's a middle ground that would do just fine with local models, but I think this group is vanishingly small.

> The optimal move is to retain the minimal access to SOTA models on the $20 plan, and for anything your local model fails at, use SOTA as the backup for either planning or debugging.

Optimal in what way? If I'm having to run tasks twice because the local model effed it up the first time and I'm resorting to my SOTA "backup", that's a waste of my time and far from optimal.

> it sounds like a fumble by OAI.

The vast majority of their revenue comes from large businesses buying for their teams, which are almost certainly not going to juggle lower tiers of different subscriptions to save a few bucks.

People keep saying this but it's just patently not true, or at least not apples-to-apples. You can't seriously compare Qwen 3.8 27B to Fable or Astra. Even if local models get better, so will the frontier, and you'll always be at a disadvantage.

Unless you're talking about buying enough hardware to run something like GLM 5.3, in which case the math just doesn't pencil out—the break even point is several years, and you're stuck with hardware that will be outdated well before then.

There are plenty of good reasons to use local models, but none of them are financial, at least for the vast majority of users.

I'm a software engineer and I'm in a similar boat. The models have definitely gotten better, but all the latest frontier models have been within the same order of magnitude of usefulness for many months now. Opus 4.5 was a huge boon in productivity, and I certainly write less code by hand than I did when it came out, but I can't say that my workflow has changed drastically for many months. Every model still takes some amount of babysitting to ensure it's doing the right thing, and they all make silly mistakes sometimes.

It appears, at least from a quick look, to be noticeably faster than Opus. If true, and you don't need xhigh/max reasoning for your use case (like a well-defined set of code changes), Sonnet might get the job done much more quickly.

With that said, at that point, I'd probably use something like DeepSeek V4.1 Flash, which is way faster and significantly cheaper, and probably not noticeably dumber for most use cases.

You're right, I should have said "in the US". But it is the second biggest car market in the world, so it's not like we're irrelevant in the discussion.

Like what?

Seems like a chicken-and-egg problem. Part of the reason consumers don't want EVs is because there are limited options that are any good.

I don't mean to be super negative, but I read through this all the way and still have no idea what it does or how it works. I think the problem statement needs to be outlined much better, and concrete examples of turns with/without your solution would be helpful to illustrate the difference.

Depends on how many times you need to iterate to get the result you want. If you need to run the fast model 5 times to get the results you need, compared to 1-2 times for a smarter but slower model, you've just eroded any advantage that the speed gave you.

So, as always: it depends on the use case.

But there are lots of use cases where a relatively "dumb" model is good enough.

Unfortunately, the lack of an input cache discount makes it prohibitively expensive for most use cases that aren't one-shot prompts.

The point is the speed.

> It is, but isn’t it all warranty in your scenario?

There are numerous recent stories of companies refusing to make good on their warranties and instead offering customers a refund for the original price paid. One example: https://www.tomshardware.com/pc-components/hdds/toshiba-refu...

Because the end goal is to ban non-US AI companies from being able to do business in the US.

For caching, only if you don't specify your preferred providers and let OpenRouter route each request itself. I have stuff like this in my OpenCode config for each model I use and I regularly get ~90-95% cache hit rates.

    "order": ["relace", "coreweave", "novita", "baseten", "together"],
    "allow_fallbacks": false

It still won't be quite as high as you'd get by just using DeepSeek because occasionally a request will fail and you'll get routed to a backup provider with nothing cached, but it's close enough not to matter in most instances.

But I can't argue with the lower off-peak pricing when using DeepSeek directly. The downside is they train their models on your input, which might be a deal-breaker for many users (as it is for me).

Honestly, I know several devs who do chores around the house or even play video games while AI does the bulk of the heavy lifting. If nobody cares or even realizes, does it matter? (To be clear, they all work remotely.)

Which doesn't matter if they're still not profitable.

I don't see any kind of input cache discount listed on your pricing page. Do you offer that, or is all input priced the same?