3 ms·

I expect the next Anthropic release to finally reduce the prevalence of Claudish

• sscaryterry 12d ago
  Based on?
  • 7734128 12d ago
    It's pretty much the biggest complaint of Claude compared to its competitors, so they really should adress it .
  • fatata123 12d ago
    Based on not being an idiot. Simple observation is enough.
• moojacob 12d ago
  If they fix Claudish, they've earned me back as a max customer! Fable 5.1 is not there quite there yet. They need to get that Sonnet 3.5 magic back.
  • rfgplk 12d ago
    Same. The issue with Anthropics models is that (speaking regarding code generation) they REFUSE any kind of comment override instructions. I've tried everything and no matter what, after a few turns, they resort to generating the same overtly verbose junk. Bun's codebase is littered with them See // `HANDLE` is an opaque kernel handle (kernel32 validates and returns 0/FALSE // on a non-console handle); every out-param is `&mut T` to a `#[repr(C)]` POD, // ABI-identical to the Win32 `LP*` pointer (thin non-null). The reference type // encodes the only pointer-validity precondition, so `safe fn` discharges the // link-time proof. (`bun_windows_sys::kernel32` declares these with `*mut`; // redeclared locally so the legacy-conhost cursor path below is plain calls.) or // Progress's terminal handle is the canonical `output::File` (vtable-backed // stderr/File from `OutputSinkVTable`). The duplicate `ProgressTerminalVTable` // from B-0 round 1 is removed; tty/ansi/winsize route through the new // `OutputSinkVTable` slots so `bun_core` stays T0 (no `bun_sys` dep). from src/bun_core/Progress.rs