Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Measuring Claude 4.7's tokenizer costs

claudecodecamp.com

Post reply on HN
Print view View original

281–290 of 540 posts

Re: Measuring Claude 4.7's tokenizer costs

#281

Post by lbreakjai »

fragmede wrote: post #200
louiereederson wrote: post #38

Earlier quoted context omitted.

I meant reference Toby Ord's work here. I think his framing of the performance/cost frontier hasn't gotten enough attention https://www.tobyord.com/writing/hourly-costs-for-ai-agents

That post doesn't address the human factor of cost, and I don't mean that in a good way. Even if AI costs more than a human, it's tireless, doesn't need holidays, is never going to have to go to HR for sexual harassment issues, won't show up hungover or need an advance to pay for a dying relative's surgery. It can be turned on and off with the flip of a switch. Hire 30 today, fire 25 of them next week. Spin another 5…

The cost to hire a human is highly predictable. The cost of AI isn't. I, as a human, need food and shelter, which puts a ceiling to my bargaining power. I can't withdraw my labour indefinitely.

The power dynamics are also vastly against me. I represent a fraction of my employer's labour, but my employer represents 100% of my income.

That dynamic is totally inverted with AI. You are a rounding error on their revenue sheet, they have a monopoly on your work throughput. How do you budget an workforce that could turn 20% more expensive overnight?

Re: Measuring Claude 4.7's tokenizer costs

#283

Post by _puk »

solenoid0937 wrote: post #239
Someone1234 wrote: post #113

Earlier quoted context omitted.

Yep, and I just made a recommendation that was essentially "never enable Opus 4.7" to my org as a direct result. We have Opus 4.6 (3x) and Opus 4.5 (3x) enabled currently. They are worth it for planning . At 7.5x for 4.7, heck no. It isn't even clear it is an upgrade over Opus 4.6.

I don't know how you guys are not seeing 4.7 as an upgrade, it just does so much more, so much better. I guess lower complexity tasks are saturated though.

Anecdotally, been leaning on 4.6 heavily, and today 4.7 hallucinated on some agentic research it was doing. Not seen it do that before.

When pushed it did the 'ol "whoopsie, silly me"; turned out the hallucination had been flagged by the agent and ignored by Opus.

Makes it hard to trust it, which sucks as it's a heavy part of my workflow.

Re: Measuring Claude 4.7's tokenizer costs

#284

Post by Bolwin »

snek_case wrote: post #32
_pdp_ wrote: post #29

IMHO there is a point where incremental model quality will hit diminishing returns. It is like comparing an 8K display to a 16K display because at normal viewing distance, the difference is imperceptible, but 16K comes at significant premium. The same applies to intelligence. Sure, some users might register a meaningful bump, but if 99% can't tell the difference in their day-to-day work, does it matter? A 20-30% cost…

It probably depends what you're using the models for. If you use them for web search, summarizing web pages, I can imagine there's a plateau and we're probably already hitting it. For coding though, there is kind of no limit to the complexity of software. The more invariants and potential interactions the model can be aware of, the better presumably. It can handle larger codebases. Probably past the point where human…

> summarizing web pages

For summarizing creative writing, I've found Opus and Gemini 3 pro are still only okay and actively bad once it gets over 15K tokens or so.

A lot of long context and attention improvements have been focused on Needle in a Haystack type scenarios, which is the opposite of what summarization needs.

Re: Measuring Claude 4.7's tokenizer costs

#285

Post by tornikeo »

Good lord. Reading all these comments makes me feel so much better for dumping anthropic the first time their opus started becoming dumber (circa Month ago). It feels like most people in this thread are somehow bound to Claude, even though it is alread fully enshittfied.

Re: Measuring Claude 4.7's tokenizer costs

#286

Post by apelapan »

epistasis wrote: post #257

Anybody else having problem getting Opus 4.7 to write code? I had it pick up a month-old project, some small one off scripts that I want to modify, and it refused to even touch the code. So far it costs a lot less, because I'm not going to be using it.

On the contrary, I threw a multi-threading optimization task on it, that 4.5 and 4.6 have been pretty useless at handling. 4.7 bested my hand-tuned solution by almost 2x on first attempt.

This was what I thought was my best moat as a senior dev. No other model has been able to come close to the throughput I could achieve on my own before. Might be a fluke of course, and they've picked up a few patterns in training that applies to this particular problem and doesn't generalize. We'll see.

Re: Measuring Claude 4.7's tokenizer costs

#288

Post by alphabettsy »

whalesalad wrote: post #271
ericol wrote: post #266

I did some work yesterday with Opus and found it amazing. Today we are almost on non-speaking terms. I'm asking it to do some simple stuff and he's making incredible stupid mistakes: This is the third time that I have to ask you to remove the issue that was there for more than 20 hours. What is going on here? and at the same time the compacting is firing like crazy. (What adds ~4 minute delays every 1 - 15 minutes) |…

I am having a shit experience lately. Opus 4.7, max effort. > You're right, that was a shit explanation. Let me go look at what V1 MTBL actually is before I try again. > Got it — I read the V1 code this time instead of guessing. Turns out my first take was wrong in an important way. Let me redo this in English. :facepalm:

The docs suggest not using max effort in most cases to avoid overthinking :shrug:

Re: Measuring Claude 4.7's tokenizer costs

#289

Post by smt88 »

al_borland wrote: post #274
whalesalad wrote: post #271

Earlier quoted context omitted.

I am having a shit experience lately. Opus 4.7, max effort. > You're right, that was a shit explanation. Let me go look at what V1 MTBL actually is before I try again. > Got it — I read the V1 code this time instead of guessing. Turns out my first take was wrong in an important way. Let me redo this in English. :facepalm:

This seems like the experience I've had with every model I've tried over the last several years. It seems like an inherent limitation of the technology, despite the hyperbolic claims of those financially invested in all of this paying off.

Opus 4.6 pre-nerf was incredible, almost magical. It changed my understanding of how good models could be. But that's the only model that ever made me feel that way.

Re: Measuring Claude 4.7's tokenizer costs

#290

Post by UncleOxidant »

_fizz_buzz_ wrote: post #272
Aurornis wrote: post #160

Earlier quoted context omitted.

I've also been using the Qwen3.5-27B and the new Qwen3.6 locally, both at Q6. I don't agree that they're as good as pre-Opus Claude. I really like how much they can do on my local hardware, but we have a long way to go before we reach parity with even the pre-Opus Claude in my opinion.

What hardware do you use? I want to experiment with running models locally.

Not who you asked, but I've got a Framework desktop (strix halo) with 128GB RAM. In linux up to about 112GB can be allocated towards the GPU. I can run Qwen3.5-122B (4-bit quant) quite easily on this box. I find qwen3-coder-next (80b param, MOE) runs quite well at about 36tok/sec. Qwen3.5-27b is a bit slower at about ~24tok/sec but that's a dense model.
Post reply on HN