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

I cancelled Claude: Token issues, declining quality, and poor support

nickyreinert.de

Post reply on HN
Print view View original

251–260 of 604 posts

Re: I cancelled Claude: Token issues, declining quality, and poor support

#251

Post by Aurornis »

elAhmo wrote: post #242
Aurornis wrote: post #232

Earlier quoted context omitted.

Writing detailed specs and then giving them to an AI is not the optimal way to work with AI. That's vibecoding with an extra documentation step. Also, Sonnet is not the model you'd want to use if you want to minimize cleanup. Use the best available model at the time if you want to attempt this, but even those won't vibecode everything perfectly for you. This is the reality of AI, but at least try to use the right mod…

Funny hearing you’re saying only GPT 5.5 (and Opus) can do this, having in mind that it came out last night.

To be clear, I'm not saying that they can do this.

I'm saying that if you're trying to have AI write code for you and you want to do as little cleanup as possible, you have to use the best model available.

Re: I cancelled Claude: Token issues, declining quality, and poor support

#252

Post by mmonaghan »

petterroea wrote: post #53

Looking at Anthropic's new products I think they understand they don't really have a cutting edge other than the brand. I tried Kimi 2.6 and it's almost comparable to Opus. Anthropic lost the ball. I hope this is a sign the we are moving towards a future where model usage is a commodity with heavy competition on price/performance

Kimi nowhere close to opus on extended use but definitely highly competitive with sonnet. I will probably end up using kimi for personal stuff when I find some time to get it running or get a non-anthropic/openai harness set up on my personal machine.

Re: I cancelled Claude: Token issues, declining quality, and poor support

#253

Post by wg0 »

scuderiaseb wrote: post #228
wg0 wrote: post #202

I write detailed specs. Multifile with example code. In markdown. Then hand over to Claude Sonnet. With hard requirements listed, I found out that the generated code missed requirements, had duplicate code or even unnecessary code wrangling data (mapping objects into new objects of narrower types when won't be needed) along with tests that fake and work around to pass. So turns out that I'm not writing code but I'm r…

I must be doing something very different from everyone else, but I write what I want and how I want it and Opus 4.7 plans it for me, then I carefully review. Often times I need to validate and check things, sometimes I’ve revised the plan multiple times. Then implementation which I still use Opus for because I get a warning that my current model holds the cache so Sonnet shouldn’t implement. And honestly, I’m mostly…

>Then implementation which I still use Opus for because I get a warning that my current model holds the cache so Sonnet shouldn’t implement.

This is based on the premise that given detailed plan, the model will exactly produce the same thing because the model is deterministic in nature which is NOT the case. These models are NOT deterministic no matter how detailed plan you feed it in. If you doubt, give the model same plan twice and see something different churned out each time.

> And honestly, I’m mostly within my Pro subscription, granted I also have ChatGPT Plus but I’ve mostly only used that as the chat/quick reference model. But yeah takes some time to read and understand everything, a lot of the time I make manual edits too.

I do not know how you can do it on a Pro plan with Claude Opus 4.7 which is 7.5x more in terms of limit consumption and any small to medium size codebase would easily consume your limits in just the planning phase up to 50% in a single prompt on a Pro plan (the $20/month one that they are planning to eliminate)

Re: I cancelled Claude: Token issues, declining quality, and poor support

#254

Post by deckar01 »

couchdb_ouchdb wrote: post #130
wilbur_whateley wrote: post #2

Claude with Sonnet medium effort just used 100% of my session limit, some extra dollars, thought for 53 minutes, and said: API Error: Claude's response exceeded the 32000 output token maximum. To configure this behavior, set the CLAUDE_CODE_MAX_OUTPUT_TOKENS environment variable.

I don't think i'd let it think more than 5 minutes without killing the process.

They changed it do all of the changes in a virtual cloud environment, then dump the final result at the end of the response. Before it would stream changes, so if it made a minimal fix, then decided to go off on a tangent you could stop it quickly. Now you have to wait 5+ minutes to get a single line of code out of it just to find out it also refactored everything and burned a stack of tokens. No amount of prompting seems to force it to make incremental changes locally.

Re: I cancelled Claude: Token issues, declining quality, and poor support

#255

Post by _puk »

scuderiaseb wrote: post #228
wg0 wrote: post #202

I write detailed specs. Multifile with example code. In markdown. Then hand over to Claude Sonnet. With hard requirements listed, I found out that the generated code missed requirements, had duplicate code or even unnecessary code wrangling data (mapping objects into new objects of narrower types when won't be needed) along with tests that fake and work around to pass. So turns out that I'm not writing code but I'm r…

I must be doing something very different from everyone else, but I write what I want and how I want it and Opus 4.7 plans it for me, then I carefully review. Often times I need to validate and check things, sometimes I’ve revised the plan multiple times. Then implementation which I still use Opus for because I get a warning that my current model holds the cache so Sonnet shouldn’t implement. And honestly, I’m mostly…

Rather than vibe, write your thoughts and get the model to challenge you / flesh it out is my preferred approach.

Get it to write a context capsule of everything we've discussed.

Chuck that in another model and chat around it, flesh out the missing context from the capsule. Do that a couple of times.

Now I have an artifact I can use to one-shot a hell of a lot of things.

This is amazing for 0-1.

For brown field development, add in a step to verify against the current code base, capture the gotchas and bounds, and again I've got something an agent has a damn good chance of one-shotting.

Re: I cancelled Claude: Token issues, declining quality, and poor support

#256

Post by Aurornis »

munk-a wrote: post #247
Aurornis wrote: post #232

Earlier quoted context omitted.

Writing detailed specs and then giving them to an AI is not the optimal way to work with AI. That's vibecoding with an extra documentation step. Also, Sonnet is not the model you'd want to use if you want to minimize cleanup. Use the best available model at the time if you want to attempt this, but even those won't vibecode everything perfectly for you. This is the reality of AI, but at least try to use the right mod…

> Stop trying to use it as all-or-nothing. You can still make the decisions, call the shots, write code where AI doesn't help and then use AI to speed up parts where it does help. You're assuming that finding the places where AI needs help isn't already a larger task than just writing it yourself. AI can be helpful in development in very limited scenarios but the main thrust of the comment above yours is that it take…

> You're assuming that finding the places where AI needs help isn't already a larger task than just writing it yourself.

Not assuming anything, I'm well versed in how to do this.

Anyone who defers to having AI write massive blocks of code they don't understand is going to run into this.

You have to understand what you want and guide the AI to write it.

The AI types faster than me. I can have the idea and understand and then tell the LLM to rearrange the code or do the boring work faster than I can type it.

Re: I cancelled Claude: Token issues, declining quality, and poor support

#257

Post by Maxatar »

sidrag22 wrote: post #220
raincole wrote: post #183

Earlier quoted context omitted.

> the day when LLM-assisted coding is commoditized Like yesterday? LLM-assisted coding is $100/mo. It looks very commoditized when most houses in developed world pay more for electricity than that. My definition of LLM-assisted coding is that you fully understand every change and every single line of the code. Otherwise it's vibe coding. And I believe if one is honest to this principle, it's very hard to deplete the…

> fully understand every change and every single line of the code. im probably just not being charitable enough to what you mean, but thats an absurd bar that almost nobody conforms to even if its fully handwritten. nothing would get done if they did. But again, my emphasis is on that im probably just not being charitable to what you mean.

You're most likely being pedantic, like when someone says they understand every single line of this code:

    x = 0
    for i in range(1, 10):
      x += i
    print(x)
They don't mean they understand silicon substrate of the microprocessor executing microcode or the CMOS sense amplifiers reading the SRAM cells caching the loop variable.

They just mean they can more or less follow along with what the code is doing. You don't need to be very charitable in order to understand what he genuinely meant, and understanding code that one writes is how many (but not all) professional software developers who didn't just copy and paste stuff from Stackoverflow used to carry out their work.

Re: I cancelled Claude: Token issues, declining quality, and poor support

#258

Post by Aurornis »

rafram wrote: post #249
Aurornis wrote: post #232

Earlier quoted context omitted.

Writing detailed specs and then giving them to an AI is not the optimal way to work with AI. That's vibecoding with an extra documentation step. Also, Sonnet is not the model you'd want to use if you want to minimize cleanup. Use the best available model at the time if you want to attempt this, but even those won't vibecode everything perfectly for you. This is the reality of AI, but at least try to use the right mod…

> Opus or GPT-5.5 are the only ways to even attempt this. It’s pretty funny to claim that a model released 22 hours ago is the bare minimum requirement for AI-assisted programming. Of course the newest models are best at writing code, but GPT-* and Claude have written pretty decent systems for six months or so, and they’ve been good at individual snippets/edits for years.

> It’s pretty funny to claim that a model released 22 hours ago is the bare minimum requirement for AI-assisted programming.

Not what I said.

The OP was trying to write specs and have an AI turn it into an app, then getting frustrated with the amount of cleanup.

If you want the AI to write code for you and minimize your cleanup work, you have to use the latest models available.

They won't be perfect, but they're going to produce better results than using second-tier models.

Re: I cancelled Claude: Token issues, declining quality, and poor support

#259

Post by nozzlegear »

whattheheckheck wrote: post #117
aleqs wrote: post #61

Earlier quoted context omitted.

Indeed, I feel like we are in the early computer equivalent phase of AI, where giant expensive hardware is still required for frontier models. In 5 years I bet there will be fully open models we'll be able to run on a few $1000 of consumer hardware with equivalent performance to opus 4.7/4.6.

You'll never have the power of what they have though. Cloud capital is insane. So you can run 1 agent locally on $1k to $3k hardware They can run a fleet of thousands

But does one individual need a fleet of thousands of agents?

Re: I cancelled Claude: Token issues, declining quality, and poor support

#260

Post by zozbot234 »

SwellJoe wrote: post #176
zozbot234 wrote: post #129

Earlier quoted context omitted.

$10K should be enough to pay for a 512GB RAM machine which in combination with partial SSD offload for the remaining memory requirements should be able to run SOTA models like DS4-Pro or Kimi 2.6 at workable speed. It depends whether MoE weights have enough locality over time that the SSD offload part is ultimately a minor factor. (If you are willing to let the machine work mostly overnight/unattended, with only inci…

You can't put "SSD offload" and "workable speed" in the same sentence.

As a typical example DeepSeek v4-pro has 59B active params at mostly FP4 size, so it needs to "find" around 30GB worth of params in RAM per inferred token. On a 512GB total RAM machine, most of those params will actually be cached in RAM (model size on disk is around 862GB), so assuming for the sake of argument that MoE expert selection is completely random and unpredictable, around 15GB in total have to be fetched from storage per token. If MoE selection is not completely random and there's enough locality, that figure actually improves quite a bit and inference becomes quite workable.
Post reply on HN