Claude Opus 4.7 • Hacker News Board

Re: Claude Opus 4.7

#441

Post by [deleted] » Thu, Apr 16, 2026, 5:19 PM UTC

batshit_beaver wrote: post #175

endymion-light wrote: post #16

I'm not sure how much I trust Anthropic recently. This coming right after a noticeable downgrade just makes me think Opus 4.7 is going to be the same Opus i was experiencing a few months ago rather than actual performance boost. Anthropic need to build back some trust and communicate throtelling/reasoning caps more clearly.

What I want to know is why my bedrock-backed Claude gets dumber along with commercial users. Surely they're not touching the bedrock model itself. Only thing I can think of is that updates to the harness are the main cause of performance degradation.

[deleted]

Re: Claude Opus 4.7

#442

Post by MasterScrat » Thu, Apr 16, 2026, 5:19 PM UTC

DrammBA wrote: post #384

puppystench wrote: post #364

Earlier quoted context omitted.

Does this mean Claude no longer outputs the full raw reasoning, only summaries? At one point, exposing the LLM's full CoT was considered a core safety tenet.

Anthropic always summarizes the reasoning output to prevent some distillation attacks

and so does OpenAI

Re: Claude Opus 4.7

#443

Post by bustah » Thu, Apr 16, 2026, 5:22 PM UTC

[flagged]

Re: Claude Opus 4.7

#444

Post by dheera » Thu, Apr 16, 2026, 5:22 PM UTC

lukan wrote: post #335

simonw wrote: post #203

I'm finding the "adaptive thinking" thing very confusing, especially having written code against the previous thinking budget / thinking effort / etc modes: https://platform.claude.com/docs/en/build-with-claude/adapti... Also notable: 4.7 now defaults to NOT including a human-readable reasoning token summary in the output, you have to add "display": "summarized" to get that: https://platform.claude.com/docs/en/build-…

"Also notable: 4.7 now defaults to NOT including a human-readable reasoning token summary in the output, you have to add "display": "summarized" to get that" I did not follow all of this, but wasn't there something about, that those reasoning tokens did not represent internal reasoning, but rather a rough approximation that can be rather misleading, what the model actual does?

Although it's more likely they are protecting secret sauce in this case, I'm wondering if there is an alternate explanation that LLMs reason better when NOT trying to reason with natural language output tokens but rather implement reasoning further upstream in the transformer.

Re: Claude Opus 4.7

#445

Post by DrammBA » Thu, Apr 16, 2026, 5:22 PM UTC

gpm wrote: post #354

Interestingly github-copilot is charging 2.5x as much for opus 4.7 prompts as they charged for opus 4.6 prompts (7.5x instead of 3x). And they're calling this "promotional pricing" which sounds a lot like they're planning to go even higher. Note they charge per-prompt and not per-token so this might in part be an expectation of more tokens per prompt. https://github.blog/changelog/2026-04-16-claude-opus-4-7-is-...

> Opus 4.7 will replace Opus 4.5 and Opus 4.6

Promotional pricing that will probably be 9x when promotion ends, and soon to be the only Opus option on github, that's insane

Re: Claude Opus 4.7

#446

Post by fzaninotto » Thu, Apr 16, 2026, 5:22 PM UTC

Just before the end is this one-liner:

> the same input can map to more tokens—roughly 1.0–1.35× depending on the content type

Does this mean that we get a 35% price increase for a 5% efficiency gain? I'm not sure that's worth it.

Re: Claude Opus 4.7

#447

Post by oefrha » Thu, Apr 16, 2026, 5:23 PM UTC

bayesnet wrote: post #276

This is a CC harness thing than a model thing but the "new" thinking messages ('hmm...', 'this one needs a moment...') are extraordinarily irritating. They're both entirely uninformative and strictly worse than a spinner. On my workflows CC often spends up to an hour thinking (which is fine if the result is good) and seeing these messages does not build confidence.

It wouldn't be so irritating if thinking didn't start to take a lot longer for tasks of similar complexity (or maybe it's taking longer to even start to think behind the scenes due to queueing).

Re: Claude Opus 4.7

#448

Post by MintPaw » Thu, Apr 16, 2026, 5:23 PM UTC

bayesnet wrote: post #276

This is a CC harness thing than a model thing but the "new" thinking messages ('hmm...', 'this one needs a moment...') are extraordinarily irritating. They're both entirely uninformative and strictly worse than a spinner. On my workflows CC often spends up to an hour thinking (which is fine if the result is good) and seeing these messages does not build confidence.

Sounds really minor, but was actually a big contributor to me canceling and switching. The VS Code extension has a morphing spinner thing that rapidly switches between these little catch phrases. It drives me crazy, and I end up covering it up with my right click menu so I can read the actual thinking tokens without that attention vampire distracting me.

And of course they recently turned off all third party harness support for the subscription, so you're just forced to watch it and any other stuff they randomly decide to add, or pay thousands of dollars.

Re: Claude Opus 4.7

#449

Post by fzaninotto » Thu, Apr 16, 2026, 5:24 PM UTC

cupofjoakim wrote: post #20

> Opus 4.7 uses an updated tokenizer that improves how the model processes text. The tradeoff is that the same input can map to more tokens—roughly 1.0–1.35× depending on the content type. caveman[0] is becoming more relevant by the day. I already enjoy reading its output more than vanilla so suits me well. [0] https://github.com/JuliusBrussee/caveman/tree/main

To reduce token count on command outputs you can also use RTK [0]

[0]: https://github.com/rtk-ai/rtk

Re: Claude Opus 4.7

#450

Post by JustFinishedBSG » Thu, Apr 16, 2026, 5:25 PM UTC

cupofjoakim wrote: post #20

> Opus 4.7 uses an updated tokenizer that improves how the model processes text. The tradeoff is that the same input can map to more tokens—roughly 1.0–1.35× depending on the content type. caveman[0] is becoming more relevant by the day. I already enjoy reading its output more than vanilla so suits me well. [0] https://github.com/JuliusBrussee/caveman/tree/main

Interesting, it doesn't seem intuitive at all to me.

My (wrong?) understanding was that there was a positive correlation between how "good" a tokenizer is in terms of compression and the downstream model performance. Guess not.