noxa

As the author of the now (in)famous report in https://github.com/anthropics/claude-code/issues/42796 issue (sorry stella :) all I can say is... sigh. Reading through the changelog felt as if they codified every bad experiment they ran that hurt Opus 4.6. It makes it clear that the degradation was not accidental.

I'm still sad. I had a transformative 6 months with Opus and do not regret it, but I'm also glad that I didn't let hope keep me stuck for another few weeks: had I been waiting for a correction I'd be crushed by this.

Hypothesis: Mythos maintains the behavior of what Opus used to be with a few tricks only now restricted to the hands of a few who Anthropic deems worthy. Opus is now the consumer line. I'll still use Opus for some code reviews, but it does not seem like it'll ever go back to collaborator status by-design. :(

I'm the author of the report in there. The stop-phrase-guard didn't get attached but here it is: https://gist.github.com/benvanik/ee00bd1b6c9154d6545c63e06a3...

You can watch for these yourself - they are strong indicators of shallow thinking. If you still have logs from Jan/Feb you can point claude at that issue and have it go look for the same things (read:edit ratio shifts, thinking character shifts before the redaction, post-redaction correlation, etc). Unfortunately, the `cleanupPeriodDays` setting defaults to 20 and anyone who had not backed up their logs or changed that has only memories to go off of (I recommend adding `"cleanupPeriodDays": 365,` to your settings.json). Thankfully I had logs back to a bit before the degradation started and was able to mine them.

The frustrating part is that it's not a workflow _or_ model issue, but a silently-introduced limitation of the subscription plan. They switched thinking to be variable by load, redacted the thinking so no one could notice, and then have been running it at ~1/10th the thinking depth nearly 24/7 for a month. That's with max effort on, adaptive thinking disabled, high max thinking tokens, etc etc. Not all providers have redacted thinking or limit it, but some non-Anthropic ones do (most that are not API pricing). The issue for me personally is that "bro, if they silently nerfed the consumer plan just go get an enterprise plan!" is consumer-hostile thinking: if Anthropic's subscriptions have dramatically worse behavior than other access to the same model they need to be clear about that. Today there is zero indication from Anthropic that the limitation exists, the redaction was a deliberate feature intended to hide it from the impacted customers, and the community is gaslighting itself with "write a better prompt" or "break everything into tiny tasks and watch it like a hawk same you would a local 27B model" or "works for me <in some unmentioned configuration>" - sucks :/

Yeah, I went through a week or two of configuration changes trying to figure out what I could have done to make it behave that way, and it wasn't until it repaired itself and then the next morning went back to idiot-mode mid-response that I finally knew it was not me. Same task, same session, same cc version, same prompts, same context, so I'm confident it was a configuration change on their end.

In case anyone can correlate, the recovery happened on March 24th and then re-regressed at approximately 3:09 PM PST (23:09 UTC) on March 25. Flipped right back into "simplest" solutions, and "You're right, I'm sorry" mode:

"You're right. That was lazy and wrong. I was trying to dodge a code generator issue instead of fixing it."

"You're right — I rushed this and it shows. Let me be deliberate about the structure before writing."

"You're right, and I was being sloppy. The CPU slab provider's prefault is real work."

It's gotten very bad. It was degrading since late Feb and since March 8th has become unusable. "Simplest fix" and "You're right, I'm sorry" are strong indicators. It went from senior engineer to entitled intern, and I went from having a team of peers to a lazy jerk who only tries to cut corners. I've got quantitative analytics of it, too. Briefly the other day for about 24 hours it returned to normal, and then someone flipped the switch again mid-session. I was a massive proponent of Claude/Opus, and for the last several weeks have felt rug-pulled. It's such an obvious degradation that even non-technical friends have noticed it. It's optimizing for minimum effort instead of correct and clean solutions. It sucks, because had I experienced it like this from the start I'd have bounced from agentic coding and never looked back - unfortunately, I thought it'd only get better and adjusted my workflow around it. When my Qwen3.5 27B local model gets into fewer reasoning loops than Opus does, it makes me wonder if anyone there cares or if they are just chasing IPO energy from scaling.

I had to build a stop hook to catch it's garbage, and even then it's not enough. I had 30min-1hr uninterrupted sessions (some slipstreamed comments), and now I can't get a single diff that I can accept without comment. Half of the work it does is more destructive than helpful (removing comments from existing code, ignoring directives and wandering off into nowhere, etc).

From 2 weeks after installing the stop hook (around March 8th): ``` Breakdown of the 173 violations:

    73x ownership dodging (caught saying variants of "not caused by my changes")
    40x unnecessary permission-seeking ("should I continue?", "want me to keep going?")
    18x premature stopping ("good stopping point", "natural checkpoint")
    14x "known limitation" dodging
    14x "future work" / "known issue" labeling
    Various: "next session", "pause here", etc.

Other one is loops in reasoning, which are something I'm familiar with on small local models, not frontier ones: ``` Sessions containing 5+ instances of reasoning-loop phrases ("oh wait", "actually,", "let me reconsider", "I was wrong"): Period Sessions with 5+ loops Before March 8 0 After March 8 7 (up to 23 instances in one session) ``` (I've even had it write code where it has "Wait, actually, we should do X" in comments in the code!)

The worst is the dodging; it said, literally, "not my code, not my problem" to a build failure it created 5 messages ago in the same session. ``` I had to tell Claude "there's no such thing as [an issue that existed before your changes]" on average:

    Once per week in January
    2-3 times per week in February
    Nearly daily from March 8 onward

Honestly, just venting, because I'm extremely depressed. I had the equivalent of a team of engineers I could trust, and overnight someone at Anthropic flicked a switch and killed them. I'm getting better results from random models on OpenRouter now (and OmniCoder 9B! 9B!). They aren't _good_ results, mind you, but they aren't idiotic.

Sad. Very sad.

No joke - I've used Windows (and a bit of OS X) my entire life and am old enough now that I didn't think I'd ever be able to switch. A few weeks back I hit the point where I had to upgrade from Windows 10 to 11 and just could not stomach the UX so in frustration I setup Kubuntu w/ Plasma... and it's been amazing. I've tried switching before without the same luck and I think agents like Claude/Codex/etc are the only reason it has stuck this time. Something that's always been unique to Linux is that if there's something I want to change I can generally do that, but now when I want something customized I can _actually_ do it instead of just slotting it into the infinite "if only I had time" bucket. There are quirks for sure (I'm looking at you, PipeWire) but the tinkery-ness of Linux on the desktop went from being friction to a super power for me just this month - maybe others will catch on next year.

I hate that I laughed at this. Thanks ;)

As a Settlers 1/2 fan I spent quite a bit of time in The Colonists - can recommend it if you liked the road building/flag mechanics and the chill gameplay.

+1 - it also doesn't support remote ssh (the open vsx variant), so is probably only focused at local web design development vibe coding ;(

Should have just been an extension with a paid plan.

Neat! As someone working in this space and feeling like I've been taking crazy pills from how these "duh, CPU solved this 30 years ago" things keep slipping it's great to see more people bridging the gap! Unfortunately CUDA/HIP (and the entire stack beneath them) virtual memory management ops are very expensive host APIs (remapping a big block of pages can be O(n^2) with page count and fully synchronize host/device (forced wait idle), take kernel locks, etc) so it hasn't been viable in all cases. If your workloads are submit/wait with host in the loop the VM tricks are ok but if you are trying to never block the GPU (pipeline depth > 0) you really want to avoid anything that does a page table modification (until we get GPUs that can pipeline those). vkQueueBindSparse is one of the few async APIs I've seen, and CUDA has cuMemMapArrayAsync but I haven't yet used it (because arrays are annoying and without being able to inspect the driver I'm sure it's probably doing the wrong thing).

I've had good luck with indirection tables used during lookup inside of the kernels consuming/producing the kvcache data - it's essentially user-mode remapping like they do here: you can publish a buffer offset table and threads are uniform, have coalesced reads to the table, and cache the offsets no problem. You have the same memory locality issues as VM (contiguous virtual but potentially random physical) but are not limited to device page sizes and since you can update while work is in-flight you can be much more aggressive about reuse and offload (enqueue DMA to cold storage to evict from VRAM, enqueue DMA to copy from cold memory into reused VRAM, enqueue offset table update, enqueue work using them, repeat - all without host synchronization). You can also defrag in-flight if you do want to try to restore the physical locality. It's nothing crazy and fairly normal in CPU land (or even classic virtual texturing), but in ML GPU land I could write a big paper on it and call it SuperDuperFancyAttention4 and publish press releases...

As an old school TT/TTD fan this gives me so many good vibes :) Been fun watching the progress and I do recommend people check out the demos on Steam if you just want to have a good nostalgia break even if the game isn't fully there yet.

Would be cool if this supported the various fp8 formats that have been shipped on GPUs recently!

Agreed! Looks great, but I did immediately click the pencil to doodle and was disappointed nothing happened. When I created a new document and tried to use the pencil nothing happened. I never figured out how to use it. I tried the Bezier tool and was able to add some nodes but was not able to manipulate them with any of the tools. Maybe dragging is entirely broken on Chrome/Windows?

I love that it played the Bo Burnham "jeff bezos" song - such incredible art.

Fantastic project and great writeup! The screen tradeoff with needing triple buffering but getting integer scaling was interesting to hear about - any feeling as to whether it adds human-noticeable latency vs. original hardware?

Just wanted to say thanks for pushing on this front! I'm not using the libc portion but the improvements to clang/llvm that allow this to work have been incredible. When I was looking a few months back the only options that felt practical for writing large amounts of device code were cuda/hip or opencl and a friend suggested I just try C _and it worked_. Definitely made my "most practical/coolest that it actually works" list for 2024 :)

Just seconding this as someone who'd been there for over 10yrs and left this last year for those precise reasons. Many of my peers left at the same time and we're quite frequently getting incoming interviews from others who still remain there. Very disappointing :(

my favorite map too :)

Yeah! Seeing blackhead popping thumbnails for this stuff in my crafting/hacking/cooking feed of videos is absolutely terrifying, especially as someone with mild trypophobia. I cannot believe that these are surfaced for me given the amount of data they have or that they are surfaced for anyone without explicit searches given the content - even if considered medical/educational in nature I wouldn't expect surgery or animal dissection videos to be surfaced likewise.

beautiful - also recommend his novels: https://kmalexander.com/home/

challenge accepted ;)

(hello!)

Having written similar tools like this in the past I pretty much exclusively use Tracy nowadays and let all my old stuff rot. The UI is snappy/fluid even with a tremendous amount of events, instrumentation is rich (zones/plots/memory tracking with timing, GPU events, logging, etc) and sampling is robust across all major platforms (Windows/Android/Linux/Mac) and the disassembly/analysis is as solid as most vendor tools. If wanting to integrate/use any tool like this I strongly recommend Tracy and then occasionally using vendor tooling where better (but platform/hardware limited). Having a single swiss-army knife perf tool makes it much easier for most of the team to learn and use it and leave the specialized knowledge of vendor tooling to those who need it.

There's also superluminal (https://superluminal.eu/), but it's closed source/paid - wolfpld (the Tracy author) is responsive and there's a decent set of contributors so switching to a black box on a part of the engineering process that is designed to avoid black boxes isn't very enticing. It also is sketchy/misleading about saying things like "Superluminal is the only sampling profiler that displays the profiling data in a visual UI." which is a big turn-off for someone who's been using/building tools like that for decades :)

Exactly the kind of things we've been talking about! A fun and challenging tradeoff space and it's always great to connect with others!

Ahh linebender - I hadn't connected the name with your github account - piet-gpu is great, as is your blog! Also, for anyone skimming the comments this talk is fantastic and I share it with anyone new to the GPGPU space: https://www.youtube.com/watch?v=DZRn_jNZjbw

We waffled a bit with the API granularity in the beginning and it's taken building out most of the rest of the project in order to nail it down (the big refactor still pending). The biggest issue is that in simple models we'll end up emitting a single command buffer but anything with control flow (that we can't predicate), data dependencies (sparsity, thresholding, etc), or CPU work in the middle (IO, custom user code, etc) can break that up. We also hit cases where we need to flush work - such as if we run out of usable memory and need to defragment or resize our pools. We want to be able to (but aren't yet) reuse command buffers (CUDA graphs, etc) and that requires being able to both cache them and recreate them on demand (if we resize a pool we have to invalidate all cached command buffers using those resources, as update-after-bind is not universally available and if shapes change there's big ripples). Since most models beyond simple vision ones are ~thousands of dispatches it also lets us better integrate into multithreaded applications like you mention as apps can record commands for themselves in parallel without synchronization. It still would be nice to have certain operations inlined, though, and for that we want to allow custom hooks that we call into to add commands to the command buffers, turning things inside-out to make small amounts of work like image transformations in-between model layers possible (I'm really hoping we can avoid modeling the entire graphics pipeline in the compiler and this would be a way around that :). We haven't yet started on scheduling across queues but that's also very interesting especially in multi-GPU cases (with x4/x8 GPUs being common in datacenters, or NUMA CPU clusters that can be scheduled similarly).

We're fully open source (https://github.com/google/iree) but have been operating quietly while we get the groundwork in place - it's taken some time but now we're finally starting to stumble into success on certain problem categories (like transformers as in the post). Right now it's mostly just organized as a systems/compiler nerd honeypot for people looking for an ML/number crunching framework that (purposefully) doesn't look like any of the existing ones :)

Would love to chat more - even if just to commiserate over GPU APIs and such - everyone is welcome on the discord where a bunch of us nerds have gathered or we could grab virtual coffee (realized just now that this hn acct is ancient - I'm benvanik@google.com :)

Oh nice, I hadn't seen dispatchThreadsPerTile! I don't believe that's possible today in Vulkan :(

Our goal (though still WIP) is to have the interaction between user applications and our compiled code happen at the command buffer boundary - you would submit some work, pass in a VkSemaphore/MTLSharedEvent/cuEvent/futex/etc, we would use that when submitting our own work, and then we'd pass you back a VkSemaphore/etc you can continue chaining with. So one level of granularity coarser than mid-pass interleaving but still hopefully all pipelined properly with no host/device synchronization required. There will be programs that this doesn't work well with (heavily data-dependent stuff) but at least making it work turns it into an optimization problem vs today's representation problem!

RE cooperative matrix: they have functional units (AMX/ANE) that could hopefully be exposed in MSL via something shaped like cooperative matrix and I'm pretty sure it'd be fantastic. Everything today is locked behind CoreML and Accelerate and those are poor targets for modern compiler-based approaches :( On the Vulkan side there's been rumblings of a vendor-agnostic extension for cooperative matrix and support from major vendors - at which point I'm hoping that leads to Apple wanting to show off their own HW features.

RE MoltenVK: we were surprised how robust it is nowadays - we're definitely going to build out our own Metal backend for our abstraction layer but wanted to see what we could hit with the zero-code option and it's proven very useful for that! A MoltenVK build is on the order of ~12MB (last I looked) while the entire IREE runtime is 50-100KB so it's a hard pill to swallow, all other issues (security/memory consumption/startup time/etc) notwithstanding :)

AFAIK the memoryless storage is only for textures and mostly useful in render passes - Vulkan has this via VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT. In a way what we do in our compiler is fuse dispatches such that they never hit memory at all so it hasn't been something we've needed yet. For heavy compute workloads more control over virtual memory would be useful, though, ala https://developer.nvidia.com/blog/introducing-low-level-gpu-... - some of the biggest performance hurdles when it comes to highly dynamic ML is around memory management (being able to zero-copy resize buffers when data-dependent shapes change would be killer).

// IREE dev

Correct! We're currently compiling to SPIR-V and then going through MoltenVK/spirv-cross to get to Metal - and our SPIR-V needs quite a bit of work (currently tuned for Mali, which is a very different architecture). The biggest limiter though is as you note Apple doesn't have a way to use the fancy hardware instructions whereas our CUDA version is using the Tensor Cores.

The good news (for us) is that this is all effectively -O1 today; there's still potential for 2-8x speedups over these numbers and that's not even factoring in the inaccessible HW features that maybe one day Apple will expose :crossed-fingers: :)

// IREE dev

I somewhat understand the hate for electron but as a non-Mac user I'd much rather have access to this app - and I suspect the author would rather have me pay them for it. For such niche software it seems silly to build it so platform specific.

Would be cool if the editor came with some samples so that I could check out all the features of the tool (like 8bitworkshop.com).

The LGPL reference implementation is what has scared off me and many others I know who had an interest in this work. In many corporate environments LGPL is untouchable.

Type profiling as they display it may be overkill, however easily seeing what and where code goes polymorphic and the chain that led to it being so is super useful in performance-sensitive areas. Having to dump hydrogen files and load up IRHydra is pretty much the opposite of fun, as nifty as it is ;(

I haven't used this extension but my guess is that it's defeating the host redirection that ISPs do to point you at their extremely shitty and underprovisioned edge caches. Most ISPs run them to cache popular youtube content and save on out of network bandwidth, however as with most things they are terrible at it and extremely cheap. The solution I've been most happy with is to run all traffic over VPN to an endpoint not under Comcast - keeps everything nice and speedy, albeit with slightly more latency.