unsafe code is likely being used as in unsafe rust, which is different from exploit code

certainly the wording seems to leave the door open for potentially compromised code as in supply-chain attack credential stealer or prompt injection data exfiltration, but sprites are not marketed as sandboxes for malware detonation

neither of the observations gp made is dependent upon the definition of machine, nor is it dependent on the inclusion of the examples you brought up in that definition.

the "largest real-world demonstration of Claude's capabilities" is sitting in local repos, built with the daily quota leftovers from corpo accounts

unfortunately i did not add a note at the time

for supporting evidence, see first chart here: https://www.anthropic.com/news/claude-fable-5-mythos-5

i disagree, but it seems clear, from how you put it, that there's no point explaining the why

https://xcancel.com/ClaudeDevs/status/2064949876463645026

let me try that style

  1. it's not *just vanity* if it feeds into *rtk*'s pitch. it's the hook, it's meant to convince users, *rtk* will reduce token waste.
  2. OP's article is not spreading fear, uncertainty, or doubt. at best it disputes *rtk*'s claims that it is effective in reducing token waste, and it does so directly with the question: "Where Are the Accuracy Benchmarks?"
  3. a) *beep* - you are disqualified for failing to identify the *burden of proof* obligation lies with *rtk*, not OP; b) OP made no claims, except for the ones you conveniently dismiss — the github issues. furthermore the "reason[s] to believe that the thousands of devs using rtk are silently tanking their performance without noticing" was already answered. you missed it because you couldn't see past the joy of having your pull-request recently merged.
  4. really, you were so disturbed by the article, you couldn't even ignore the *one* non-technical point, in an article *you choose* to interpret as being technical — all of it being your own fault. nevermind how relevant it is as a signal for the effectiveness of such technics.
  5. is it inherent? are we doomed to live with broken tool outputs? note, the issue, here, is not that *rtk* will fail when output changes, *that* is inherent to *rtk*'s current implementation — as i understand it, but that "it will fail quietly, feeding corrupted or partial text to your agent".

you were so close to getting it here:

> instead of reporting that SOMEONE SHOULD MEASURE THIS, you could, you know, measure it yourself

but hey, thanks for getting me to take another look at rtk & co., i am now further convinced these are just the flavor of the month tricks for speed running context rot