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

531–540 of 540 posts

Re: Measuring Claude 4.7's tokenizer costs

#531

Post by fragmede »

thrwaway55 wrote: post #404
fragmede wrote: post #200

Earlier quoted context omitted.

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…

Why do you think it can't sexually harass someone or drive people to suicide. There are already lawsuits coming in on it causing suicides. This is an architecture that people are increasing begging to give network connectivity that can't differentiate its system prompt from user input

As the NRA puts it, guns don't kill people, people kill people. Yes, a harasser now has access to more powerful tools to sexual harass somebody, but Claude, the AI, isn't going to randomly grab the secretary's ass and have to be fired for having done so at the holiday Christmas party.

Re: Measuring Claude 4.7's tokenizer costs

#532

Post by fragmede »

tclancy wrote: post #486
michaelbuckbee wrote: post #278

Earlier quoted context omitted.

More importantly it collapses mythical-man-month communication overhead.

Hang on, tell me how, because I am not picking up what you are putting down. At a minimum, wouldn’t this require working from a perfectly written spec that has already accounted for the discovery of changes that would need to be made from the original perfect spec?

The way I see it, because you can spin up additional AI employees at will (and spin them back down), when the problem with the spec is found, it's no big deal to redo all of that work from before, adjusting for that change.

Re: Measuring Claude 4.7's tokenizer costs

#533

Post by cindyllm »

dns_snek wrote: post #464
solenoid0937 wrote: post #159

Earlier quoted context omitted.

You dramatically overestimate how much time engineers at hypergrowth startups have on their hands

There's a direct business incentive to game/cheat benchmarks, it wouldn't even be difficult to do, and besides, they have workforce-replacing AI to do it for them.

[dead]

Re: Measuring Claude 4.7's tokenizer costs

#534

Post by michaelbuckbee »

tclancy wrote: post #486
michaelbuckbee wrote: post #278

Earlier quoted context omitted.

More importantly it collapses mythical-man-month communication overhead.

Hang on, tell me how, because I am not picking up what you are putting down. At a minimum, wouldn’t this require working from a perfectly written spec that has already accounted for the discovery of changes that would need to be made from the original perfect spec?

So we have two things here:

1. "Mythical Man Month" which is the shorthand for a whole book + concept that you can't just throw more people at a software development project and get linear productivity improvements as the communications overhead (meetings, emails, mistakes due to poor assumptions, etc.) deeply eat into the raw number of productive hours that a new person added to the team brings.

2. AI automation tools (Claude Code) are often described as a "junior developer" which is an imperfect comparison as while you could potentially sort of set them up that way many people use them as more of a singular force multiplier.

I use them to work on many more projects in many more ways and ship far more than I could even if I had a "junior developer" sitting alongside of me as there's not the same level of communication needed.

Re: Measuring Claude 4.7's tokenizer costs

#536

Post by ericol »

losvedir wrote: post #482
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) |…

> 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? I don't know if you're giving this as something you've actually given Claude, but I don't think it's a good way of using Claude. It's not a collaborator who's having a bad day where a little empathy might make him feel better and realize his error. It's a token generator based on a prompt…

> I don't know if you're giving this as something you've actually given Claude, but I don't think it's a good way of using Claude.

That wasn't the full prompt, I trimmed it for clarity, but I agree with everything you said and that's how I actually use it.

I have a proxy logging everything sent to and from Claude in a structured way, which is precisely what let me do that compaction analysis in the first place.

When Claude goes off track, I don't tell it "you did something wrong". I ask it to analyze the tool outputs and the exchange so far and let it reconcile the discrepancy itself. That tends to work better than narrating the error to it.

The venting messages like that one are honestly for me, not for Claude. I know it's a tool. But it also behaves and communicates like a person, and that's a design choice that comes from Anthropic, not from me. What I've found is that writing something like that and then following it with proper instructions works fine in practice: Claude either ignores the venting or briefly acknowledges it and moves on. The actual output isn't affected. It's just how I process frustration without breaking the workflow.

Re: Measuring Claude 4.7's tokenizer costs

#537

Post by curioussquirrel »

arcanemachiner wrote: post #101
curioussquirrel wrote: post #51

Claude's tokenizers have actually been getting less efficient over the years (I think we're at the third iteration at the least since Sonnet 3.5). And if you prompt the LLM in a language other than English, or if your users prompt it or generate content in other languages, the costs go higher even more. And I mean hundreds of percent more for languages with complex scripts like Tamil or Japanese. If you're interested…

I would encourage you to post a link here, and also to submit to HN if you haven't already. :)

Here you go! https://news.ycombinator.com/item?id=47847282

Re: Measuring Claude 4.7's tokenizer costs

#538

Post by conductr »

skydhash wrote: post #348
conductr wrote: post #326

Earlier quoted context omitted.

This is most likely trajectory I fear. It reminds me a lot of Oracle, where they rebrand and reskin products just to change pricing/marketing without adding anything.

Win 10, win 11, all the recent macOS,… could have been released as features and not new products

My only problem lumping them in is a huge part of those products are the UI and UX. It’s what you interact with as a user. So, a reskin with no new features is a valid version in my opinion.

It’s not always for the best mind you, but I do think major changes to the GUI or UX do deserve a version indicator given they are relatively infrequent. Without some requirement of course.

Nobody buys Oracle because of the UI or upgrades because of a new UI. It’s the underlying tool that matters and if my ugly version is working there is no incentive to upgrade to a prettier version.

Re: Measuring Claude 4.7's tokenizer costs

#540

Post by mainguy »

fragmede wrote: post #532
tclancy wrote: post #486

Earlier quoted context omitted.

Hang on, tell me how, because I am not picking up what you are putting down. At a minimum, wouldn’t this require working from a perfectly written spec that has already accounted for the discovery of changes that would need to be made from the original perfect spec?

The way I see it, because you can spin up additional AI employees at will (and spin them back down), when the problem with the spec is found, it's no big deal to redo all of that work from before, adjusting for that change.

Ironically, people keep saying this, but then gloss over the core problem of coordinated between these agents... For completely independent codebases with no dependencies, sure thing right on...go for it. But the vast majority of F500 companies I work with have wild and undocumented dependencies between almost every system that will take years to "agentify" (assuming they ever figure out that it's an organization and governance problem.... which they might not ever realize)
Post reply on HN