Live data from Hacker News

Claude Opus 4.6

anthropic.com

441–450 of 1001 posts

Re: Claude Opus 4.6

#441

I think two things are getting conflated in this discussion. First: marginal inference cost vs total business profitability. It’s very plausible (and increasingly likely) that OpenAI/Anthropic are profitable on a per-token marginal basis, especially given how cheap equivalent open-weight inference has become. Third-party providers are effectively price-discovering the floor for inference. Second: model lifecycle econ…

Dario said this in a podcast somewhere. The models themselves have so far been profitable if you look at their lifetime costs and revenue. Annual profitability just isn't a very good lens for AI companies because costs all land in one year and the revenue all comes in the next. Prolific AI haters like Ed Zitron make this mistake all the time.

Do you have a specific reference? I'm curious to see hard data and models.... I think this makes sense, but I haven't figured out how to see the numbers or think about it.

Re: Claude Opus 4.6

#442
post #363

Earlier quoted context omitted.

> A year or more ago, I read that both Anthropic and OpenAI were losing money on every single request even for their paid subscribers, and I don't know if that has changed with more efficient hardware/software improvements/caching. This is obviously not true, you can use real data and common sense. Just look up a similar sized open weights model on openrouter and compare the prices. You'll note the similar sized mode…

> This is obviously not true, you can use real data and common sense. It isn't "common sense" at all. You're comparing several companies losing money, to one another, and suggesting that they're obviously making money because one is under-cutting another more aggressively. LLM/AI ventures are all currently under-water with massive VC or similar money flowing in, they also all need training data from users, so it is v…

Doing some math in my head, buying the GPUs at retail price, it would take probably around half a year to make the money back, probably more depending how expensive electricity is in the area you're serving from. So I don't know where this "losing money" rhetoric is coming from. It's probably harder to source the actual GPUs than making money off them.

Re: Claude Opus 4.6

#443

Earlier quoted context omitted.

Oh, is that what the issue is? I've seen the "flicker" thing as a meme, but as someone who uses Claude Code I've never noticed. I use ghostty mostly, so maybe it's not an issue with ghostty? Or maybe I just haven't noticed it.

Yes it's people using bad tools on underpowered machines as far as I have seen

Happens with Konsole sometimes on an 8th gen i7. This cpu can run many instances of intellij just fine, but somehow this TUI manages to be slow sometimes. Codex is fine, so no good argument exists really.

Re: Claude Opus 4.6

#445

Earlier quoted context omitted.

Absolutely. A technically correct bike is very hard to draw in SVG without going overboard in details

Its not. There are thousands of examples on the internet but good SVG sites do have monetary blocks. https://www.freepik.com/free-photos-vectors/bicycle-svg

Several of those have incorrect frames:

https://www.freepik.com/free-vector/cyclist_23714264.htm

https://www.freepik.com/premium-vector/bicycle-icon-black-li...

Or missing/broken pedals:

https://www.freepik.com/premium-vector/bicycle-silhouette-ic...

https://www.freepik.com/premium-vector/bicycle-silhouette-ve...

http://freepik.com/premium-vector/bicycle-silhouette-vector-...

Re: Claude Opus 4.6

#446

Earlier quoted context omitted.

The 1M context is not available via subscription - only via API usage

Well this is extremely disappointing to say the least.

They want the value of your labor and competency to be 1:1 correlated to the quality and quantity of tokens you can afford (or be loaned)??

Its a weapon who's target is the working class. How does no one realize this yet?

Don't give them money, code it yourself, you might be surprised how much quality work you can get done!

Re: Claude Opus 4.6

#447
post #40

The bicycle frame is a bit wonky but the pelican itself is great: https://gist.github.com/simonw/a6806ce41b4c721e240a4548ecdbe...

Do you find that word choices like "generate" (as opposed to "create", "author", "write" etc.) influence the model's success?

Also, is it bad that I almost immediately noticed that both of the pelican's legs are on the same side of the bicycle, but I had to look up an image on Wikipedia to confirm that they shouldn't have long necks?

Also, have you tried iterating prompts on this test to see if you can get more realistic results? (How much does it help to make them look up reference images first?)

Re: Claude Opus 4.6

#448
post #308

Earlier quoted context omitted.

It says "subscription users do not have access to Opus 4.6 1M context at launch" so they are probably planning to roll it out to subscription users too.

Man I hope so - the context limit is hit really quickly in many of my use cases - and a compaction event inevitably means another round of corrections and fixes to the current task. Though I'm wary about that being a magic bullet fix - already it can be pretty "selective" in what it actually seems to take into account documentation wise as the existing 200k context fills.

lmao what are you building that actually justify needing 1mm tokens on a task? People are spending all this money to do magic tricks on themselves.

Re: Claude Opus 4.6

#449

Earlier quoted context omitted.

> Claude now automatically records and recalls memories as it works Neat: https://code.claude.com/docs/en/memory I guess it's kind of like Google Antigravity's "Knowledge" artifacts?

If it works anything like the memories on Copilot (which have been around for quite a while), you need to be pretty explicit about it being a permanent preference for it to be stored as a memory. For example, "Don't use emoji in your response" would only be relevant for the current chat session, whereas this is more sticky: "I never want to see emojis from you, you sub-par excuse for a roided-out spreadsheet"

It's a lot more iffy than that IME.

It's very happy to throw a lot into the memory, even if it doesn't make sense.

Re: Claude Opus 4.6

#450
post #379

Earlier quoted context omitted.

We don't vary our model quality with time of day or load (beyond negligible non-determinism). It's the same weights all day long with no quantization or other gimmicks. They can get slower under heavy load, though. (I'm from OpenAI.)

Can you be more specific than this? does it vary in time from launch of a model to the next few months, beyond tinkering and optimization?

Yeah, happy to be more specific. No intention of making any technically true but misleading statements.

The following are true:

- In our API, we don't change model weights or model behavior over time (e.g., by time of day, or weeks/months after release)

- Tiny caveats include: there is a bit of non-determinism in batched non-associative math that can vary by batch / hardware, bugs or API downtime can obviously change behavior, heavy load can slow down speeds, and this of course doesn't apply to the 'unpinned' models that are clearly supposed to change over time (e.g., xxx-latest). But we don't do any quantization or routing gimmicks that would change model weights.

- In ChatGPT and Codex CLI, model behavior can change over time (e.g., we might change a tool, update a system prompt, tweak default thinking time, run an A/B test, or ship other updates); we try to be transparent with our changelogs (listed below) but to be honest not every small change gets logged here. But even here we're not doing any gimmicks to cut quality by time of day or intentionally dumb down models after launch. Model behavior can change though, as can the product / prompt / harness.

ChatGPT release notes: https://help.openai.com/en/articles/6825453-chatgpt-release-...

Codex changelog: https://developers.openai.com/codex/changelog/

Codex CLI commit history: https://github.com/openai/codex/commits/main/

Post reply on HN