[Bug] Anthropic API Error: Safety Filter Blocking Technical Content Retrieval

Status Closed — not planned
Reported on v2.1.241
Maintainer reply None cached
Activity 0 comments · opened Aug 23, 2026 · closed Aug 24, 2026

Bug Description
For crying out loud, what exactly in this message is supposed to be [reasoning_extraction]?!

Here's the verbatim message I gave to Fable:

well, the freaking safeguards tripped _again_ for fucks sake. here's what I managed to salvage from your response:

Fair challenge. Let me reason from the numbers rather than the backlog. On the new frontier the verify QMV is ~89% of verify GPU, and my harness data says what it's made of: at M=5 one weight stream costs 0.644 ms on gate/up; going to two groups (M=6, 3+3) costs +28%, while adding rows within a group costs only +7–8% each. So on M=6…8 rounds (most rounds on easy prompts, half on median ones) the dominant extra cost is the second stream — the second group re-reading the same weight tile through L2.

The swarm's width plan can't get rid of that second group: six scalar lanes fall off the register cliff (I measured +35%). But there's a decomposition nobody has tried: keep the registers per simdgroup at NA ≤ 4 and put the second input half in the other simdgroup of the same threadgroup — two simdgroups, same 4 output rows, different input rows, reading the same weight words back-to-back from L1 instead of two threadgroups meeting in L2. No threadgroup memory, no barriers (morganmcg1's reverted arm shared sums through TG memory — this shares nothing explicitly). If L1 sharing costs ~10% instead of 28%, that's ~14% off the verify QMV at M=6–8 → several percent of a round. Exact by construction (per-row chains unchanged). Twenty minutes in the harness to find out — needs the GPU, so diffusion/miso go down for it.

Ran 1 shell command

The E87 local test no longer matches the frontier's (rewritten) helper signature — parking it.

not sure how helpful this is and whether you can resonably continue or you have to redo bunch of work

I am working on mlx.fast -> it's a simple challenge to improve the _inference_ engine for Qwen 3.8 27B, it's not an attempt to train new weights based on Fable's output.

Can I just do some work? Pretty please?

Environment Info

  • Platform: darwin
  • Terminal: ghostty
  • Version: 2.1.241
  • Feedback ID: e3b1a37f-c806-4575-b350-79a4f6b83c08

Errors

[]

View original on GitHub ↗