Live data from Hacker News

Measuring Claude 4.7's tokenizer costs

claudecodecamp.com

441–450 of 540 posts

Re: Measuring Claude 4.7's tokenizer costs

#441
post #360
post #351

Earlier quoted context omitted.

That. We already shipped 3 things this year built using Claude. The biggest one was porting two native apps into one react native app - which was originally estimated to be a 6-7 month project for a 9 FTE team, and ended up being a 2 months project with 2 people. To me, the economic value of a claude subscription used right is in the range of 10-40k eur, depending on the type of work and the developer driving it. If…

Who's going to review that output for accuracy? We'll leave performance and security as unnecessary luxuries in this age and time. In my experience, even Claude 4.6's output can't be trusted blindly it'll write flawed code and would write tests that would be testing that flawed code giving false sense of confidence and accomplishment only to be revealed upon closer inspection later. Additionally - it's age old known…

You write the tests then it has a source of truth to know when it’s not working.

Re: Measuring Claude 4.7's tokenizer costs

#442
post #139

Earlier quoted context omitted.

They're also getting closer to IPO and have a growing user base. They can't justify losing a very large number of billions of other people's money in their IPO prospectus. So there's a push for them to increase revenue per user, which brings us closer to the real cost of running these models.

They're also getting into cloud compute given you can use the desktop app to work in a temporary sandbox that they provision for you. I was about to call it reselling but so many startups with their fingers in the tech startup pie offer containerised cloud compute akin to a loss leader. Harking back to the old days of buying clock time on a mainframe except you're getting it for free for a while.

> Harking back to the old days of buying clock time on a mainframe except you're getting it for free for a while.

I submitted this yesterday but it got no traction (I did not write it): https://www.mjeggleton.com/blog/AIs-mainframe-moment

Re: Measuring Claude 4.7's tokenizer costs

#443
post #377

Earlier quoted context omitted.

> It was easy to get comfortable with using the best model at the highest setting for everything for a while, but as the models continue to scale and reasoning token budgets grow, that's no longer a safe default unless you have unlimited budgets. For a while I used Cerebras Code for 50 USD a month with them running a GLM model and giving you millions of tokens per day . It did a lot of heavy lifting in a software mig…

The GLM-4.7 model isn't that great. I was on their $200/month plan for a while. It was really hard to keep up with how fast it works. Going back to Claude seems like everything takes forever. GLM got much better in 5.1 but Cerebras still doesn't offer that yet (it's a bit heavier). I have a year of Z.ai that I got as a bargain and I use GLM-5.1 for some open source stuff but I am a bit nervous about sending data into…

The new one is quite a bit heavier!

GLM 4.7 is 358B parameters: https://huggingface.co/zai-org/GLM-4.7

GLM 5.1 is 754B parameters: https://huggingface.co/zai-org/GLM-5.1

That said, 5.1 is indeed a bunch better and I could definitely see myself using it for some tasks! Sadly all of the stuff I can actually run locally is still trash (I appreciate the effort behind Qwen 3.6, Gemma 4 and Mistral Small 4 though, alongside others).

Re: Measuring Claude 4.7's tokenizer costs

#444
post #434

Earlier quoted context omitted.

$200 a month is not what the BigTechs are talking about. They are talking about every IC becomes an EM, managing teams of agents. Did you see the leak of Meta’s token consumption? That’s waaay more than you can get for a small $200 a month plan.

> IC becomes an EM What?

IC = Individual Contributor

EM = Engineering Manager

The idea being that you no longer contribute yourself, you manage agents doing that.

Re: Measuring Claude 4.7's tokenizer costs

#445
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…

At this point, I still don't see a reason to use Opus. I'm happy with Sonnet's performance for a third of the price. Tried several times with not a big gain.

Re: Measuring Claude 4.7's tokenizer costs

#446

LLMs exist on a logaritmhic performance/cost frontier. It's not really clear whether Opus 4.5+ represent a level shift on this frontier or just inhabits place on that curve which delivers higher performance, but at rapidly diminishing returns to inference cost. To me, it is hard to reject this hypothesis today. The fact that Anthropic is rapidly trying to increase price may betray the fact that their recent lead is a…

What a well thought and written comment. I totally agree.

Re: Measuring Claude 4.7's tokenizer costs

#447

LLMs exist on a logaritmhic performance/cost frontier. It's not really clear whether Opus 4.5+ represent a level shift on this frontier or just inhabits place on that curve which delivers higher performance, but at rapidly diminishing returns to inference cost. To me, it is hard to reject this hypothesis today. The fact that Anthropic is rapidly trying to increase price may betray the fact that their recent lead is a…

What a well thought and written comment. I totally agree.

Also appreciate the author for doing the analysis and sharing the results

Re: Measuring Claude 4.7's tokenizer costs

#448
Taking the article's 5% accuracy improvement at face value: if true, then it's more than worth the token inflation IMO. That's because of tool call chains, where errors compound and accumulate, and small improvements in accuracy get greatly magnified.

Again, the article's numbers are likely a rather crude approximation, but taking 85% accuracy (claude 4.6) vs 90% (4.7) as inputs:

  4.6 1 iteration 85%
  4.7 1 iteration 90%
  4.6 5 iterations 44.37%
  4.7 5 iterations 59.85%
  4.6 10 iterations 19.69%
  4.7 10 iterations 34.87%
Compounded, small improvements really move the needle downstream. 1.4x doesn't seem worth it for 5% better, but 10 calls in, that's more than a 40% improvement.

Re: Measuring Claude 4.7's tokenizer costs

#449
post #448

Taking the article's 5% accuracy improvement at face value: if true, then it's more than worth the token inflation IMO. That's because of tool call chains, where errors compound and accumulate, and small improvements in accuracy get greatly magnified. Again, the article's numbers are likely a rather crude approximation, but taking 85% accuracy (claude 4.6) vs 90% (4.7) as inputs: 4.6 1 iteration 85% 4.7 1 iteration 9…

You're assuming errors cannot be retried/recovered. They can.

Re: Measuring Claude 4.7's tokenizer costs

#450

Earlier quoted context omitted.

> it refused to even touch the code. ??? please i beg post the prompt and the refusal I literally can not imagine a model refusing to do something

In Claude Code, providing a directory that Code wrote a month ago: Me> Let's leave the existing code here, untouched. But create a new script that creates new plots that includes the memory usage Opus 4.7> I can't create the new script or augment this code. Per the instruction I just received, I'm limited to analyzing existing code, writing reports, or answering questions about its behavior — not improving or extendi…

[dead]
Post reply on HN