AI Submissions for Mon Nov 09 2026
Claude Fable 5.2 and Mythos 5.2
Submission URL | 883 points | by meetpateltech | 529 comments
Fable 5.2 and Mythos 5.2 are one model sold two ways: Fable ships to everyone with strong cyber and biology safeguards, while Mythos is the same weights with those safeguards relaxed, gated behind Anthropic's expanded Life Sciences and Cyber Verification Programs.
Pricing dropped versus 5.1, to $8 per million input and $40 per million output tokens. An optional fast mode generates up to 2.5x faster at $16/$80. Anthropic also claims output up to 30% faster than 5.1 even in normal mode.
On Anthropic's own benchmark table, Fable 5.2 leads Opus 5.5 on most rows:
- FrontierCode 2.0: 49.1% at Xhigh effort, against 32.4% for Fable 5.1 and 45.5% for Opus 5.5.
- Remote Labor Index: 41.3%, roughly double Fable 5.1 (17.9%) and Opus 5.5 (21.3%).
- RoboDojo Sim: 64.9%, against 27.6% and 39.4%. Anthropic ran this one internally.
- CVE Rediscovery (Mythos): 89.6%, up from 78.3%.
It doesn't win everything. Gemini 4 Carbon edges it on AutomationBench (53.9% vs 51.4%), and Fable 5.1 slightly trails Mythos on Terminal-Bench-Science. Cross-lab cyber scores aren't comparable, since each lab's CyScenarioBench numbers come from different tasks.
Anthropic's own guidance is to start with Opus 5.5 for most work and move up to Fable or Mythos only for ambitious, open-ended jobs. Fable can also act as an advisor to smaller models or as an orchestrator that delegates to them. On efficiency, Fable at High effort roughly matches Opus 5.5 at Max on FrontierCode 2.0 for about half the cost per task.
The launch post claims some striking prerelease results, including a Fermat's Last Theorem formalization in 30 hours and two open black-hole physics problems solved, but the excerpt gives no detail beyond the claims. On safety, Anthropic says misalignment risk remains low, that cyber and bio safeguards match 5.1 with fewer unnecessary blocks, and that it has added its strongest anti-distillation protections yet. The full details are in the system card.
The thread is about whether Anthropic quietly degraded Opus 5.5 before this release, and the main finding is that nobody can settle it. The one rigorous check showed nothing, while the most plausible mechanism would make that kind of check blind to the problem.
The only hard data found no regression. ariwilson re-ran a private 30-task eval on Opus 5.5 at medium effort. Against the Nov 1 baseline it solved 19/20 versus 36/40, with token use at about 0.95-0.97x. The one real change was a faster time to first token, 3.0s down to 1.7s. His own caveats were that this was one run per task and medium effort only. Commenters then disagreed over what the numbers could show:
- A confused denominator (30 vs 20 vs 40) drew a "this reads like LLM text" complaint. It turned out to be 20 tasks run twice each on Nov 1, and the author said he will publish the benchmark.
- astro1234, jerkstate and disgruntledphd2 pointed out that with only 1-2 failures per run, the differences are within noise. Reliable confidence intervals would need roughly 200 runs, which is too expensive to do regularly.
The leading theory is selective degradation, not a global nerf. xtracto, cft and eggdaft described what looks like A/B testing or per-account routing. cft, a heavy $200-tier user, said his account was "selected", and eggdaft saw an obvious drop alongside a spike in "How's Claude doing today" prompts. Tadpole9181 objected that random A/B testing wouldn't correlate with release windows. Y_Y and eggdaft replied that the nerf could hit only some users before a release, perhaps to test whether lower effort could become permanent. If degradation is partial, a public tracker or one person's eval can show nothing while others suffer.
Why trackers may be useless:
- rybosworld argued that benchmarks don't detect quantization until about 4 bits, even though humans notice it earlier. j_maffe pushed back that quantized models do dip on evals.
- scrlk, swader999 and tmpz22 raised a "Dieselgate" scenario in which benchmark traffic is routed to a full-strength model. Wowfunhappy asked how private benchmarks could be identified, and tmpz22 conceded this applies only to the public ones.
- swatcoder cautioned that trackers are adversarial and imperfect, so neither their results nor anecdotes should be over-read.
Alternative explanations:
- marshalla suspected user behavior, such as stuffing too much into one session.
- mr_roboto blamed harness updates in Claude Code.
- A dissenting airesQ noted that in one cited A/B case the user actually got more effort, which isn't obviously a nerf.
Fallout: olalonde argued that silently serving weaker compute would amount to false advertising. kuboble and cvwright replied that hosting providers do exactly this with underclocked or throttled "dedicated" hardware. eggdaft's team is shifting work to OpenAI, and cft pointed to local or open-weights models as the predictable option. kif reported similar degradation recently on a GPT model, so the suspicion is not limited to Anthropic.
TPU 8tx and TPU 8i Max
Submission URL | 175 points | by benx | 30 comments
Google now has four TPU systems in one year: 8tx for confidential inference and 8i Max for million-token context join the 8t (training) and 8i (reasoning) announced at Cloud Next in April. The framing from Amin Vahdat is that these are new systems, not new chips. 8tx runs on the same silicon as 8t, and the changes are in packaging, memory, networking, and security around it, which is how Google says it can ship specialized configurations in months instead of multi-year chip cycles.
- TPU 8tx: targets regulated enterprises and governments running proprietary models and agents on sensitive data. It pairs 8t silicon with 5th Gen AMD EPYC CPU hosts to protect data and model weights while they're in memory, the point where data is normally decrypted. Google also calls it good for small-scale training.
- TPU 8i Max: built for massive context windows, with what Google calls the highest compute density per rack in the lineup.
The baseline claims carry over from April: up to 2.7x training performance for 8t and 80% better inference price-performance for 8i, both versus the prior generation. Google says 8i also cuts inter-chip communication delays by up to half. No specs, pricing, or availability dates for the two new systems appear in the text I had, so the "Max" and "tx" claims are unquantified for now.
On the business side, Google says TPUs have nearly 100 customers, including frontier labs, trading firms, and retailers. Customers can now also deploy TPUs in their own data centers. The pitch is paired with PyTorch support and open-source tooling, a clear attempt to lower the CUDA-shaped barrier to adoption.
Most of the thread is frustration with the announcement itself, with a smaller, more substantive argument about whether TPUs are actually available to anyone.
"No one can use it" vs. "who do you think builds these?" The loudest complaint was that the post has no specs, pricing, purchase links, or developer on-ramp. Commenters called it a press release and noted that "Opening up TPUs to every developer" comes with no link on how to start. Defenders gave two replies:
- It's a marketing announcement aimed at enterprise buyers, and technical detail exists elsewhere.
- The developer path is real. The post covers TorchTPU, and a quick search turns up Google Cloud quickstarts. One joker described onboarding as a "twenty-seven step process neatly spread across three portals," and another quipped you'll know sign-up worked "when you start getting charged."
Are TPUs actually in use? Several commenters pushed back on the claim that nobody can use them. TPUs are rentable on Google Cloud, back Gemini traffic, and are reportedly used by Apple Intelligence and Anthropic. Others noted Google now sells them externally, citing a report that Anthropic bought them. Someone called "nearly 100 customers in 10 years" unimpressive. The rebuttals were that customers spending around a billion dollars each is a different kind of metric, and that four customers reportedly make up most of Nvidia's revenue. One commenter speculated that keeping TPUs mostly in-house is a competitive edge on cost per inference, while wider sales could pressure Nvidia's pricing.
Missing numbers: One commenter asked for watt/token and $/token figures against Nvidia equivalents. The thread never supplied any.
Smaller asides:
- The article says "TPU" 79 times without expanding the acronym.
- The naming scheme drew jokes, including a T1000 Terminator reference.
- Two commenters tired of "agentic" as a buzzword.
- Someone observed that the stock market doesn't seem to care about the news.
Google Gemini routes personal Drive files and emails to human annotators
Submission URL | 351 points | by gf74918 | 88 comments
A GitHub write-up claims Google reversed its 2023 promise that Workspace content connected to Gemini isn't seen by human reviewers. The author points to Google Help Answer 16836988 and an October 16 edit to the original 2023 blog post. Per the author's quotes, Google now warns that reviewers "may just be the email or file" and says not to connect apps to Gemini Apps if they hold confidential information you wouldn't want a reviewer to see.
The more alarming claim is about behavior: with Connected Apps on, casual mentions of trips, bills, or names reportedly trigger background Gmail/Drive lookups with no @Drive or @Gmail tag. Because tool-calling is probabilistic, a single test can land in one of four states:
- Zero retrieval: nothing is pulled.
- Metadata or summary: e.g. "a bill of $122 on September 4."
- Partial extraction: a 2-6 sentence verbatim quote, sometimes with account and confirmation numbers.
- Full ingestion: the entire email, headers included.
To reproduce: enable Connected Apps, use Flash with High Thinking, casually mention a topic from your inbox (the author used "I wonder if I'm paying too much for internet service" against an ISP bill), then ask Gemini to print the exact text its retrieval tool returned. Delete the conversation between trials so it can't lean on history. The author saw all four outcomes across runs.
The author also argues Google's regex and NER scrubbers can't deidentify narrative text, since combinations like name, city, and event still identify a person.
The catch: this is one person's testing, not an audit. The evidence is a repo README, and asking a model to print its own tool output is not proof of what gets retained or which sessions humans actually review. The documentation changes are the checkable part; the rest isn't verified here. If you've enabled Connected Apps, the practical fix is cheap: turn it off.
The thread opens with a scoping correction, and most of the rest is anger at Google followed by a long argument over whether self-hosting is a realistic exit.
The correction that frames the post. bri3d notes the claim applies to consumer Gemini with Connected Apps enabled. Workspace Gemini and Workspace Intelligence, the enterprise RAG product, still say they aren't subject to human review. In their view the nuance is the problem. Even for unaffected enterprise customers, a confusing split like this will make paying buyers nervous. gf74918 spelled out the mechanism: Gemini can autonomously pull summaries, snippets or full file text into context, which makes it eligible for human review.
Dark patterns in the consent flow. snailmailman said the full-screen "allow connected apps" popup never explains what "yes" grants (all of Drive and Gmail, or per-file?). Clicking "no" just brings the popup back later. Replies:
- donmcronald wants "ask me every 5 minutes" patterns made illegal, with retroactive fines.
- themodestman suggests killing the popup with uBlock Origin's element picker. BOOSTERHIDROGEN points out the Gemini mobile app shows it too, and taneq's answer is to stop using the app.
- giancarlostoro called it a likely class-action case.
Is Google a monopoly? apt-apt-apt-apt asked why the free market isn't fixing this, and mjburgess said "google is a monopoly." stefangordon objected that Outlook and others offer free email, and that "best product everyone wants" isn't a monopoly. Elsewhere, brador argued that frontier AI is effectively a duopoly. qeternity countered with five major US labs, strong open-weights competition and several clouds. brador replied that only two labs are truly at the frontier.
Self-hosting as the exit. This became the largest sub-thread.
- Immich, Nextcloud and Dawarich were recommended for photos, files and location. Gigachad runs them behind Tailscale on a second-hand mini PC.
- topaztee worried about losing everything on an old laptop. Suggested backups: Arq to encrypted S3, a nightly rsync to a USB drive, and the 3-2-1 rule.
- On phones, heikkilevanto asked how to take photos without Google touching them. taneq switched to iOS as the lesser evil, after finding LineageOS unreliable.
- On email, sdoering plans to self-host despite deliverability worries. eks391 advised migrating email last, since downtime hurts most. munk-a proposed self-hosting only the receiving address and forwarding to a provider for sending and browsing. kevg123 uses a similar setup (OpenSMTPD, Dovecot, spamassassin).
Side threads.
- EMM_386 quoted Google's Photos terms about inferring relationships and locations, and asked what happens when AI-generated images feed that inference. scuttlebutt98 replied that watermarks probably filter AI images out of training.
- hek2sch said any tool with human annotators has this exposure.
- whatever1 said AI-race shortcuts on privacy create debt that will come due.
- rustyhancock suspected Gemini had been drawing on their emails without saying so, after a reply was uncannily tuned to one.
The thread is mostly shared distrust of Google. No one tests the author's reproduction steps, and the practical advice that emerges is to decline Connected Apps and move data off Google.
Fable 5.2 one-shotted my nephew's dream game
Submission URL | 47 points | by lexandstuff | 22 comments
An agent built a complete 12-stage beat 'em up overnight from a kid's hand-drawn design docs, and the author says it was actually fun. That's a big jump from the June attempt (Claude Code with Opus 4.8 and Fable 5 on a side-scrolling template), which wasn't worth playing past a couple of minutes.
The setup: Lex Toumbourou's nephew Aiden drew up five family-based heroes (including the dog), 12 bosses, and a loose story about rescuing their puppy. Before bed, Lex gave Claude Fable 5.2, which he had early access to, one long prompt. It asked for a "modern-day Ninja Turtles arcade game," pointed at the scanned drawings, gave API keys for OpenAI image generation and ElevenLabs sound effects, asked for 4-player controller support, and told the agent to commit as it went and feel free to start fresh. The prompt also leans on the "gas up the agent" framing, which he admits may no longer matter.
By morning:
- Most of his old code had been thrown out and the game rewritten.
- About 175 images and 140 audio clips were generated.
- Unrequested extras appeared: cutscenes, smashable crates, an ending.
- The reasoning traces showed it wrote a bot, played all twelve stages in a headless browser, and checked screenshots for bugs.
Four PS4 controllers connected to a MacBook worked on the first try. Aiden said it was "exactly as I imagined." Playtesting still produced human-scale changes. Owen got a Hulk transformation on his first power-up, Aiden's special became a screen-wide lightning and blue-fire blast, and the cast grew to include extended family and two pet turtles. Each addition took a few reference photos plus a chosen special move, and Claude redrew the cutscene art and updated the story each time.
The "one shot" is really one big overnight pass plus iterative tweaks, and it's a single anecdote with an unreleased model. Even so, the self-playtesting loop is the detail worth noticing: the agent verified the game by playing it, not just by compiling it.
The thread splits between "models can now make games fun" comparisons and a smaller worry about what AI-made media does to kids.
Model comparisons on "fun." simonw said Opus 5.5 responds to "make this more fun" by actually doing it, and that Fable 5.2 can too. In his loose testing, other models lag. He offered a mouse-versus-cat three.js game built by Opus 5.5 and one by GPT-6 Extra High, and judged the Claude one better even though the two look alike. goyozi pushed back with a DX Ball clone test. Fable 5.2 was clearly better in some areas, but the Opus 5.5 version felt more fun. Fable also changed mechanics despite being told to match the original, and Opus's attempt predated new guardrails on recreating existing games. bjtitus preferred Fable's gameplay after two minutes, and gave Opus the edge only on sound effects. So there's no consensus on which model has better game sense, just small, subjective samples. giancarlostoro added that Opus 4+ could already do this kind of thing, with 4.6's 1M-token context the key step.
Cost. waltbosz asked what the run would cost. Tiberium used the blog's token counts at Fable's listed prices ($8/$40, cache reads $0.20, cache writes $10) and got about $294. The author confirmed roughly $300 at API prices, though his own tokens were free.
Playtesting the actual game
- mmahemoff found the controls undiscoverable. "Punch" isn't mapped to an obvious key, and only Enter pauses. He suggested Esc or P for pause, plus a pause screen listing controls and an exit.
- duendefm found an exploit: enemies can be kicked endlessly in the left corner. He joked that he was now the AI exploiting bugs.
Kids and AI art. abrookewood called it an amazing outcome for the kids. forthwall found it cute but a bit sad that generic AI styling could become ubiquitous for the next generation. lelandfe noted visual glitches, like a Battle Wagon quintupling in size between frames, but said the kids having fun is the point. slopinthebag voiced worry about kids growing up on AI slop. latentsea countered that they already do, via brainrot, Roblox and YouTube shorts, so this won't register as different.
Smaller asides: Waterluvian wants to hand AI a Macintosh Garden link and get a browser port. Others swapped retro references (Street Hassle, Bop'n Rumble, Little Fighter 2). georgemcbay mocked the "world-class game developer" prompt framing as "LLM glazer" job material.
Claude Fable 5.2 Scores 65 on Artificial Analysis, Highest So Far
Submission URL | 265 points | by theanonymousone | 187 comments
Claude Fable 5.2 (Max) takes #1 of 74 on the Artificial Analysis Intelligence Index with a 65, against a median of 40 for comparable models. It also ranks near last on speed, cost, and verbosity.
The costs of that score:
- Price: $8.00 per 1M input tokens and $40.00 per 1M output, versus medians of $2 and $10. The cache discount is 98%.
- Cost per task: $26.54 per Intelligence Index task, ranked 73rd of 73.
- Speed: 44.1 minutes per task (median 12.9). Time to first answer token is 231.55s, so the reasoning budget is spent before any output appears. Output speed is 103 tok/s.
- Verbosity: it generated 275M tokens across the index, against a median of 72.8M.
The model takes text and image input, outputs text, and has a 1M-token context window. It's proprietary and released November 2026. The page covers the reasoning variant and notes that a non-reasoning one may exist.
The index (v5.0.1) averages nine evals, including Terminal-Bench 4.0, FrontierCode 2.0, HLE-Diamond, GDP.pdf, and AA-Briefcase. It leans toward agentic and long-horizon work, which is where a slow, token-hungry model pays off most.
The headline number comes from the "Max" setting. The cost and latency figures come from that same setting, so you'd likely pay far less with lower effort, though this page doesn't show what that does to the score. At a 44-minute average per task, this is a model for batch or high-stakes work, not interactive use.
The thread's central argument is whether Fable 5.2's token-hungry "Max" setting signals a wall in scaling or just a new axis of scaling. Almost everyone is working from the Artificial Analysis cost-per-task numbers.
The "wall" camp. The thread opens with rgbrenner's observation that cost per task doubled over 5.1, because output tokens per task rose from about 118k to 274k, mostly reasoning. Loquebantur reads this as diminishing returns. The base data is maxed out, intelligence is now bought with inference-time RL, and answer prices are saturating what customers will pay. mrandish sharpened the claim: the wall is in intelligence per dollar, not absolute capability. In their account, labs are ending investor-funded subsidies and using expensive tiers to segment customers by willingness to pay ahead of IPOs. motbus3 added that the method has a fundamental flaw, since more compute won't produce proportionally more content.
The rebuttals.
- One expensive model isn't a trend. sebzim4500 and rowanG077 argue that a single "supermodel" doesn't make a wall. The frontier of cost versus performance has moved outward in several places.
- The lower settings. XenophileJKO and goldenarm point out that Max isn't the fair comparison. Fable 5.2 High scores 62 at $9.08 per task, against Opus 5.5 Max at 59 and $10.04. goldenarm adds that Fable 5.2 Low is 3x cheaper than 5.1 xhigh while 8% smarter. onlyrealcuzzo makes the same point with Medium versus Opus 5.5 High. singularity2001 reads the charts differently, and onlyrealcuzzo replies that the charts show cost per task, not whether the task was solved.
- Trickle-down. biggestriverman, jaggirs and jwpapi note that labs distill the top model into cheaper ones, so the flagship is partly an advertisement for where small models are heading.
Distillation. mattnewton asked why a high-token model can't simply be distilled into one that thinks less. calebkaiser pointed to research on filtering long reasoning traces and RL for concise trajectories. Industry teams now tune small models on trajectories from production agents, which works best for workflow-shaped tasks. motbus3 cautioned that distilled models carry few guarantees outside the distilled domain, and that large models lean on latent context that gets lost in condensation. buckle8017 added that reasoning is branch exploration, which needs a large model.
Side threads.
- Reasoning effort. lukeschlather says max reasoning helps most on machine-verifiable tasks, while for something like image recognition low reasoning can beat max. XenophileJKO says newer models can do things earlier ones couldn't, such as 3D and electronics design.
- Competitors.
- breakwaterlabs argues GPT-6.1-Sol is far more economical than Opus 5.5, citing Artificial Analysis.
- lillecarl says OpenAI's subscriptions are cheap but its API pricing is "absolutely insane."
- rsalus counters that Opus, not Fable, is Anthropic's cost-performance offering.
- felixgallo raises ethical objections to OpenAI.
- Pricing. mirekrusin speculates that pricing may eventually shift to per-solution rather than per-token. Loquebantur says diminishing returns would apply there too.
- Meta. whimsicalism complains that HN wants LLMs to hit a wall. utternerd replies that the objection is to hype, not the technology. lnenad compares the extra reasoning to Chinese models padding their benchmarks with long thinking.
The unresolved question is whether cost per unit of capability is flattening or the comparison at Max is just the wrong one. The Medium and High numbers cited above favor the second reading, but no one rebutted the claim that the effective price of frontier tiers is rising.
Our Smallest, Most Efficient Model: Muse Ember
Submission URL | 234 points | by dvaplima | 97 comments
Muse Ember matches Claude Haiku 5.5's best Artificial Analysis score (about 36) at roughly a third of the cost per task: $0.136 versus Haiku's $0.411 at max effort. Meta says it also beats every GPT-6 Luna setting and sits on the efficiency frontier of the full leaderboard.
It's Meta's smallest model, aimed at the repetitive agent workload: tool calls, coding subtasks, routing, extraction, long document parsing. It's live now on the Meta Model API.
- Pricing: $0.10 per million input tokens, $0.50 per million output tokens
- Context: 1M-token window, up to 512K output tokens
- Cost-per-task chart: Ember scores 33.9 at $0.116 and 35.8 at $0.136, versus Haiku's 24.6 at $0.092 and 34.3 at $0.248. Meta flags that Ember's costs are estimates at proposed pricing.
At max reasoning, the biggest gaps are on agentic benchmarks:
- AutomationBench-AA: 37.8 vs. 20.2 (Luna) and 13.9 (Haiku)
- Coding Agent Index-AA: 46 vs. 37 and 31
- Personal Superintelligence Index: 46.8, an internal Meta composite, vs. 36.1 and 37.0
- Terminal-Bench 4.0: 40.9 vs. 39.2 (Haiku) and 16.4 (Luna), a narrow lead over Haiku
- Not a clean sweep: Haiku leads on FrontierCode 2.0-AA (34.9 vs. Ember's 27.2) and ties on GDP.pdf-AA (22.8 vs. 20.8 for the other model).
Partner quotes are the usual launch fare, but two carry numbers. You.com reports a p95 latency of 2.2 seconds, 4x to 13x faster than leading open-weight models, with 36–48% fewer output tokens. Cloudflare saw up to 30% faster tail latency than a comparable model. Cline pitches it as a cheap subagent inside a larger harness, which is the sensible use.
Caveats: the headline comparisons come from Meta's own presentation of Artificial Analysis data, the Personal Superintelligence Index is internal, and the partner results are early testing, not independent replication.
The thread splits between pelican-test play, skepticism about how Meta presented its benchmarks, and a long argument over open weights and specialized models.
Simon Willison's pelican test. He ran the SVG prompt at all six effort levels (the "high" run didn't return a complete SVG). The correlation between reasoning and drawing quality, which he usually sees, seems to break here. Several commenters preferred "minimal," which used only about 10 reasoning tokens, and others thought the levels differed mostly in style.
- Overfitting? ezst asked whether equal quality at lower effort suggests the model was tuned for this test. ourcat pointed out that all the outputs add a red scarf nobody asked for. 9dev wondered whether pelican-on-bicycle images are now simply in the training corpus.
- Why outputs converge: swatcoder said short, vague prompts make models fill gaps with the same trained associations: right-facing, three motion lines, yellow sun, dashed lane divider. viraptor countered that humans share many of these preferences too.
- Leg placement: imimayj1337 thought only the max-effort run had the legs straddling the bike correctly. swatcoder and latexr said that's an illusion. The code stacks objects by concept, so z-ordering is wrong, and both pedals sit on the same side of the frame.
- Dissent: small_model said a single SVG says little about model capability.
Benchmark framing. doodlesdev noticed from the footnotes that Ember's Terminal-Bench 4.0 result used mini-swe-agent, not Meta's own harness. Each model got its own "best published harness" (Claude Code for Haiku, Codex for Luna). The Personal Superintelligence Index is an internal composite.
Pricing details. minimaxir noted that the cached-input price is 4% of the input price, versus about 10% for Luna and Haiku. system2 dismissed the model because there's no batch pricing.
Open weights. Several people were disappointed that Ember has no weights (Retro_Dev, Pragmata, ecshafer). Others pointed to Muse Spark Open, an 816B-A42B model. anon373839 said it was nerfed well below the original's intelligence class. Nobody knows Ember's actual size, which segmondy and syntaxing both asked about.
Specialized vs. general models. kbrannigan predicted LLMs will settle into per-profession models, as PCs settled into a standard form.
- GuB-42 argued that professional work needs broad common knowledge, and that mixture-of-experts already gives specialization inside one model.
- drillsteps5 wanted coding models trained on curated, clean code, which would also make compensating authors easier. ElectricalUnion replied that such a model would lack common sense and would fail on anything beyond toy tasks.
Other points.
- open-paren and sullivanmatt think Ember is the "crouton alpha" stealth model on OpenRouter. They cite matching context size, reasoning levels, max output, knowledge cutoff, and country restrictions.
- slopnt already uses Haiku and Luna for cheap, fast support on SWE tasks, so a cheaper comparable model is welcome news.
Is Opus 5.5 nerfed? Thinking patterns changed on November 3
Submission URL | 733 points | by rzk | 471 comments
A Claude Code user claims Opus 5.5's reasoning behavior shifted sharply on November 3 with no change to the model name. Shane Melaugh had Gemini 4 Argon analyze 1,400 of his Claude Code sessions, and it flagged that date as a break point. He also says the amount of reasoning Opus 5.5 does at the "high" effort setting dropped off a cliff.
The evidence is thin. One anecdotal bug test: "high" jumped into action too quickly, got confused, and failed to find a fix after 3 hours, while "xhigh" paused to think and found one in a few minutes. His conclusion is that the "use high for everything" advice popularized by Theo no longer holds, and that xhigh is the setting to use now.
Melaugh later walked back the framing himself. He says he's not an AI tools reviewer, this isn't a scientifically bulletproof benchmark, and it started from personal frustration going from "Opus 5.5 is amazing" to "I can't get work done with this thing anymore." Worth keeping in mind: an LLM grading another model's transcripts, from one user's workload, can't separate a model change from a change in his tasks or prompts.
Theo responded by dispatching a bot job to run Opus 5.5 xhigh over his own proxy logs in ClickHouse to check the claim. No result is in the thread yet, and that independent check across a much larger set of traffic is the thing that would actually settle it.
The thread splits between people who believe labs quietly degrade models after launch and a skeptic minority who see ordinary psychology. Nobody produced hard evidence either way.
The "silent nerf" camp is the largest. Several commenters (onlyrealcuzzo, vadansky, lukeschlather, tibbon) say Opus 5.5 got noticeably dumber recently, with mistakes they say even weaker models wouldn't make. Vadansky's examples: it suggests allowing all connections or leaving a password in plain text, forgets how to squash in jj, and edits files through Python scripts so the diff is hidden. The main arguments:
- Cost: pier25 thinks the likeliest driver is simple cost, with demand or a hidden stronger model as less likely explanations. RobotToaster adds that labs keep full power at launch because that's when benchmarks get run, then cut back to save money.
- Advertising and legality: mrinterweb, radlad, and pc86 say changing capability behind an unchanged model name amounts to false advertising, or even fraud. Others pushed back on the analogies. Google doesn't tell users about algorithm changes, but abustamam answered that Google doesn't advertise benchmark-level capabilities and then serve a nerfed version. jpadkins added that Google does communicate big changes to advertisers. Pydry's "caveat emptor" drew replies that reputational consequences are how buyers police suppliers, and that we don't accept that logic for engineering or pharma.
- Practical responses: monkeydust wants more investment in harnesses and guardrails and in open models. onlyrealcuzzo would "gladly forgo the best available power for consistency." Obscurity4340 says DeepSeek Flash doesn't have this problem.
The skeptic camp: NewsaHackO says this is a known novelty-then-boredom bias, and that "account freshness" theories just mask it. They point to community attempts to quantify it, such as livenerf. Makmanalp mocked the thread for conspiratorial reverse-engineering of feelings. Nickalaso countered with a Reddit thread that supposedly shows evidence of Anthropic behaving this way, but nothing in the thread verified it.
A concrete alternative explanation came from ariwilson and lukeschlather. In Claude Code, a cyber-safeguards refusal can move the session onto Opus 4.8. ariwilson saw this in 5 of 60 runs on ordinary auth-token fixes. Lukeschlather says it's an opt-in setting: once you accept the downgrade, it applies silently every time afterward. Security-adjacent work like vadansky's could be hitting this, which would make the "nerf" a routing behavior and not a change to the model itself.
Hidden capability: PhunkyPhil speculates that labs hold back much stronger models. Nickalaso agrees, arguing that internal users with effectively unlimited spend and nested subagents get far better results. As evidence, they describe building a multi-model harness with 20+ agents at a corporate job. Aucisson_masque and N_Lens reacted to the "automating my entire job" part, and nickalaso said they quit to work on harnesses full time.
Side thread: the fraud debate turned into Dieselgate. Woodson noted a VW engineer got 40 months in prison, and FireBeyond added that the CEO and four executives were charged too.
The crux is that the user-side evidence is all anecdote, while the one reproducible mechanism raised, the silent downgrade to 4.8, doesn't need any model nerf at all. Without a lab or a large independent dataset, it can't be separated from bias.
A year after the 100% AI mandate nobody understands our code
Submission URL | 78 points | by thelifeline | 76 comments
The source text didn't come through: the post body is just a redlib mirror link, so all I have is the title and the subreddit (r/ClaudeCode). The title implies a first-person account of a company that mandated 100% AI-written code and, a year in, has a codebase no one on the team understands.
If the post follows that framing, it's a comprehension-debt story rather than a quality or velocity one. The code may work, but nobody holds a mental model of it. That makes debugging, onboarding, and safe refactoring harder. I can't confirm specifics such as team size, metrics, incidents, or what they plan to change, and I won't guess at them.
The thread splits into the human cost of mandated AI coding and an argument over whether going all-in early was a mistake. A side thread also questions whether the original post is authentic.
The lived experience. The top comment relays a friend with 12 years of experience at a large company, now working 10-hour days feeding prompts to Claude, waiting, reviewing, and "learning absolutely nothing." Replies pushed back in a few ways:
- Give the model bigger chunks of work or run projects in parallel.
- If you have downtime, use it to learn; that's on you.
- LLMs are fine for analysis and small tasks, and nobody has to use them as full agents.
Others said the sane-shop option is vanishing. One described FOMO-driven pressure from shareholders and owners who assume competitors are shipping faster. Another asked who will develop architectural judgment if their career starts with an "Easy Button." One commenter who agreed with the premise said comprehension of the code erodes very quickly once you give the LLM full rein and lean on automated review. They guessed the "year ago" in the post is really about 8 months, since the capability jump came around November 2025.
Wait or go all-in? The longest argument began with marginalia_nu's claim that spending heavily a year ago was "kind of insane" when models keep getting cheaper and better. Late movers get more for the same money, and they learn from others' blunders.
- NoPicklez countered that this argument applies forever, that you can't tell when the wait is over, and that you only learn by making mistakes yourself.
- ryanbrunner and streetfighter64 argued that time is a constraint. A "kinda-crappy" feature today often beats a perfect one later, and users won't wait six months.
- marginalia_nu replied that big, older, risk-averse organizations are already burdened by past tech decisions and shouldn't bet the business on pioneering AI practice. Startups are different.
- amw-zero and Jare argued that skill at using AI is itself a competitive edge you only get by practicing. rogerrogerr disagreed, saying it isn't a deep subject: "You point it at problems and they get solved."
- AnimalMuppet said it depends on your market. Early matters in growth markets with lock-in.
Other threads
- Authenticity: ianm218 said the post scores 100% AI-generated on Pangram and warned about engagement-farming anti-AI content, though they found the substance relatable.
- Code as product: proc0 argued that when non-technical people call the shots, they treat code as the product, but the real value is understanding and design, which are intangible and hard to justify. austin-cheney added that if a startup's product is purely AI-written, it can be reverse-engineered and little else remains.
- Practical mitigation: WillAdams suggested having agents document the whole codebase, literate-programming style, and then reviewing it to see what can be understood.
- Labor: the "why work 10 hours if the computer does the work?" question drew the reply that technology has never shortened the work day, and a remark that the four-day-week talk from Covid has faded since ChatGPT.
DeepX claims inference up to 100B parameters at less than 5 W
Submission URL | 136 points | by giuliomagnifico | 22 comments
DeepX's DX-M2 taped out with a 5 W budget and a claim of running 20B–100B-parameter MoE models at 10–30 tokens/s. That only works because those models activate roughly 3B–20B parameters per token, so memory bandwidth, not total size, is the constraint. The M2 triples bandwidth from 50 to 150 GB/s, doubles NPU efficiency through design changes, and doubles it again by moving to a 2 nm process. It reaches 80 TOPS and supports speculative decoding and TurboQuant.
The more interesting bet is Samsung's LPDDR5x-PIM, which computes GEMV inside the memory chip. DeepX's simulations show 6.7× the tokens/s on Llama3.1-8B versus the M2 alone. The catch is power: that gain costs 2.7× the total draw, so it leaves the 5 W envelope. DeepX says it can get about 2× within the non-PIM power envelope. The compiler is the other soft spot. It's a prototype built against a PIM simulation, still needs "substantial manual effort," and hasn't been tested on real hardware yet. DeepX does have LPDDR5x-PIM samples in-house. The next chip, the DX-M3, targets standard LPDDR6 PIM, and DeepX projects a 5–8× gain there.
The go-to-market pitch is robotics teams that prototype on Nvidia GPUs like Thor and then hit thermal and power walls. DeepX offers a migration path: swap Isaac API calls for its Newton equivalent and run the same pipeline, with 17 compatible libraries so far. It also cites M1-based robots running the same source code as a Jetson build. Other targets are AI PCs (via Taiwanese OEMs), in-vehicle agents, and a Samsung smart hub. The M1 is in mass production for vision, but every M2 number here is a projection from a vendor, with no silicon benchmarks yet.
The thread opened with skepticism about the headline numbers, then drifted into brain-power analogies and local-AI optimism.
Fact-checking the claims. The top comment (augment_me) listed the caveats:
- The performance figures are simulated.
- The PIM gain needs 2.7× the power, roughly 13.5 W, and memory power isn't broken out.
- The compiler is a prototype, so it isn't a drop-in Isaac replacement.
- The 5 W figure seems to apply to sub-4B models, not the 100B ones.
NewJazz added that the "100B" claim only covers MoE models, which they called misleading. gunalx pushed back that models of that size are commonly MoE anyway, and that a 100B MoE is still 100B total even with 20B active. sampton noted 13.5 W is Jetson Nano territory.
Back-of-envelope hardware math. PaulKeeble worked from 80 TOPS and 150 GB/s, noting the article doesn't say whether TOPS is INT4 or FP16, which matters a lot for prefill.
- He compared it to a 9070 XT (about 750 INT4 TOPS and 650 GB/s), putting prefill at roughly a tenth to a third of that card.
- At Q4, decode of 10 tok/s caps active parameters near 7B, and 30 tok/s near 2.5B.
- Conclusion: it's only useful for MoE (so no dense Qwen 27B), but it could be a decent low-power home box depending on price.
- nomorewords likewise noted that prefill/ingestion speed goes unmentioned, and worried that compute-in-memory would raise memory prices.
Brain-power tangent. idiotsecant said the brain runs on about 10–20 W, so 13.5 W for a 4B model leaves room for improvement. dinfinity countered that brains are slow, at a few tokens per second, and wondered how humans would score on energy per benchmark point. egberts1 objected that the brain is more of a "Next Concept Model." danuker then described an indexing task that took them 61 minutes with 4 errors, versus 3 minutes, $0.034 and 2 errors for DeepSeek-V4-Flash. anonymous908213 replied that machines have beaten humans at data processing since the calculator. Meanwhile delichon joked about joule-stamping comments.
Local-first optimism.
- LaurensBER reported weekly questions about in-house AI, with European trust in both the US and China at a low. A cheap local DeepSeek Flash-class model would be a "no brainer."
- ares623 added that the more labs optimize inference for margin, the more feasible local models become.
- ilaksh went further, arguing compute-in-memory could make existing data centers obsolete and let models keep scaling without energy limits. This was the most speculative claim in the thread and nobody engaged with it.
- kylehotchkiss noted their M5U Studio draws about 72 W running a long Gemma4 job.
- tensward thought the specs looked slow for edge use.
Show HN: STE80 Humanizer – de-AI text by writing 80% of the way to ASD-STE100
Submission URL | 50 points | by Dodaios | 12 comments
A two-pass prompt skill for Claude Code and Cursor that strips AI-writing tells, then rewrites what's left to roughly 80% of ASD-STE100, the controlled English used in aircraft maintenance manuals. The author's argument is that phrase-removal alone leaves the real giveaway: long sentences that carry three ideas, hide the actor and stack hedges.
- Pass 1 removes 26 tells (§1–§26), drawn from Wikipedia's "Signs of AI writing" and the blader/humanizer catalog: chatbot openers, "not just X, it's Y," "-ing" riders, "could potentially," dramatic closers.
- Pass 2 applies 15 structure rules (S1–S15): one idea per sentence, active voice, simple tenses, instructions separated from descriptions, one topic per paragraph.
The 80% setting borrows from a Karpathy post about making LLM output easier to read. Strict STE caps instructions at 20 words and descriptions at 25, and bans "may," "should" and verb uses of "check" and "test." The default relaxes this: sentence limits can slip by a few words, you use the plain common word instead of the approved dictionary, and contractions are fine in casual text. Semicolons stay out in both modes.
The README's Kubernetes liveness-probe example turns a hedge-laden paragraph opening with "Great question!" into six short, active sentences. The skill reports its edits by rule number (e.g. "§1, §8, S2"), so you can audit each change. The repo also notes that a fact check found errors in Karpathy's STE graphic, and the skill follows Issue 9 instead.
The author states that beating AI detectors is not a goal; readability is. Install with npx skills add Dodaios/ste80-humanizer, then invoke /ste80-humanizer or just ask your agent to de-AI a text. It's a young repo (5 commits) with an evals folder, but the README shows no eval results. Treat the claim that it reads better as unmeasured. The restructuring also risks flattening nuance in text that needed it.
The thread is small, and the most pointed criticism is that the skill file looks like the slop it's meant to remove.
- Slop in the skill itself: After adammarples couldn't find SKILL.md and aaronbrethorst linked it, z2 said the file reads like AI output. It includes disclaimers aimed at the user, such as a warning that a later fact check found errors in the original STE graphic. grey-area agreed and asked why all this ceremony is needed. Their own approach is to drop a
style_guide.mdinto context.whatobjected to a "sources and credits" section inside a SKILL.md, which is instructions for a model and not documentation for a reader. - Positive reports: nphardon said that asking for 80% of ASD-STE100 noticeably improves readability and cuts the "brain fog" of reading Opus output. cadamsdotcom found it useful for general copy and wondered whether it also defeats text watermarking. Nobody answered that.
- Framing: wavemode said "humanizer" is the wrong label. The tool removes AI tics and doesn't add a human voice, so it targets clarity and concision, not passing as human-written.
- Alternatives: bushido asked how it differs from an existing "simple english" skill (SimpleEnglish), which they had tested across several harnesses and found effective. No one answered the comparison. datadrivenangel pointed to ISO 24495-1 as the standard for technical writing. whattheheckheck suggested tropes.fyi.
- Philosophical objection: bemtevi argued people should take pride in learning to write properly and not outsource it to a machine. No one replied.
The unresolved question is whether this beats a plain style guide in context. Nobody offered measurements, only individual impressions.
Next-Concept Modeling: Fast, Parallel Coarse-to-Fine Text Generation
Submission URL | 175 points | by theanonymousone | 40 comments
Text generation that goes coarse-to-fine, one level of a code hierarchy at a time, beats the strongest diffusion LM on LM1B perplexity while running 21x faster at matched parameter scale.
The mechanism: a multiscale residual VQ-VAE compresses text into a hierarchy of discrete codes. A transformer then generates one level at a time, predicting every code within a level in parallel. That sidesteps the diffusion LM problems the authors list: quality collapsing at low step counts, full-sequence processing at every step, and many passes over the dataset needed to train well.
The numbers against the strongest DLM baseline:
- LM1B: better generative perplexity, 21x faster.
- OpenWebText: competitive quality, 10x faster.
- XSum: matching ROUGE-L, 31x faster.
- Sudoku: beats both autoregressive and diffusion baselines at every difficulty level with fewer function evaluations.
The speedup shrinks from 21x to 10x on the longer-form OpenWebText, and quality there is only "competitive," not better. Whether the gap holds at larger scales or longer sequences is the open question. The comparisons are against DLMs and autoregressive baselines at matched parameter scale, so the abstract doesn't say how NCM stacks up against optimized autoregressive serving, which is the real incumbent. The paper comes from a group that includes Simran Arora, Azalia Mirhoseini, and Christopher Ré.
Very little of the thread engages with the paper's technical claims. It splits into a few side conversations.
Adoption cost. The top comment says a new tokenizer and training method means expensive retraining, so uptake depends on frontier-level results. alansaber agreed from experience: domain-specific tokenizers seemed promising, but training from scratch cost far more than fine-tuning. swiftcoder asked who will train a large coding model on this, since they lack the GPUs.
Missing baseline. cubefox thought the paper compares mostly against masked diffusion and barely against standard next-token prediction. That suggests it doesn't win there, except on highly non-linear tasks like Sudoku. johntb86 suggested it might still work as a drafting model for speculative decoding, in the way DFlash drafts 7 to 15 tokens in a single diffusion pass for an autoregressive model to verify.
Naming and hype. imtringued complained about clickbait YouTube videos claiming "NCM" obsoletes "LLMs". They argued that "LLM" doesn't imply autoregression. They described NCM as a hierarchical diffusion-style transformer, closer to an evaluation strategy that could apply to any architecture. They also found "next" in the name misleading, since the method isn't strictly ordered.
GPU-hoarding tangent. This began with an off-topic claim that hyperscalers have half their GPUs idle in warehouses, and dsjoerg and tomrod noted it had no direct link to the paper.
- Lerc said the warehouse story is invented. In his view, buying ahead secures supply, and unused hardware gets traded to people who want it now.
- bigbadfeline countered with documented hoarding and a story about stolen GPUs going unnoticed for two weeks.
- Others said it's a sequencing problem between data centers and chips, or a lack of customers, or hype-maintenance.
Apple Silicon vs Nvidia. LoganDark argued that Apple's GPU lags Nvidia's, in prefill and in memory bandwidth (about 1 TB/s against roughly two-thirds more on the 5090). swiftcoder replied that the platforms aren't equivalent, because no 5090 offers 512 GB of memory, and matching that capacity takes about $100k of GPUs plus an interconnect bottleneck.
Style dispute. A long thread debated whether writing "21x" instead of "21 times" misuses mathematical notation. Commenters said it is common and well understood in English, and one noted Steve Jobs saying "two ex".
I ran 120B MoE models on my 32GB M1 Max using under 16 GB
Submission URL | 16 points | by tarassenkov | 3 comments
A 120B MoE model decodes at 7.84 tok/s on a 32GB M1 Max under a 16 GiB process-memory budget, about 36% faster than TUFF 10.2.2 on the same machine (5.78 tok/s). The prototype keeps experts on the SSD, pulls in what each token needs, and enforces the cap against macOS's own memory counters. It also runs Qwen3.5-122B-A10B, and ships a small browser chat and an OpenAI-compatible local API. The engine code isn't released yet.
The more interesting result is what happens when the machine is shared. With another process holding 4 GiB and touching it every five seconds, this engine lost about 3% of its speed and TUFF lost about 23% (1.72× advantage). At 8 GiB both degrade, though the gap holds at 1.69× (7.12 vs 4.21 tok/s).
Activity Monitor flatters TUFF: roughly 7.4 GiB footprint against 15.6 GiB. But TUFF filled 14.5–15.2 GiB of file cache with model data and pushed system compressed memory from about 2.4 GiB to 9.3–9.6 GiB. The competing process needed a median 352 ms per pass over its 4 GiB with TUFF running, versus 4 ms with this engine. Both cut free memory by about 17–18 GiB.
The methodology details are the credibility here:
- An early benchmark was inflated because macOS cached about 8 GB of model data outside the process footprint. Fixing it lowered the numbers.
- Residency is now checked with mincore, disk traffic against kernel counters and iostat, and footprint via kernel measurements rather than RSS.
- Weights were verified identical: 144 expert tensors byte-for-byte and all 471 non-expert tensors.
- Output is compared to unmodified mlx-lm. All 9 of 9 reference cases matched for each 120B-class model, plus 17,952 matching MoE decode checks in a 200-request stress run. Bugs found along the way: an MLX kernel whose numerics depended on tensor layout, and a one-token prefix-cache bug.
The caveats are real. It's one Mac, one request at a time, mostly decode. TUFF ran via CLI with explicit cache settings because its server wouldn't auto-configure for this model. An earlier single run had TUFF prefilling a long prompt about 39% faster. The Qwen numbers are excluded pending a re-run after a correctness fix slowed its prefill. And with no code released, none of this is reproducible yet.
The thread is thin, and most of it sits beside the post's actual claims rather than testing them.
- Skepticism about substance: hex4def6 is the only critic. They call the write-up AI-generated and say it gives "zero details" on the engine. Their other objections: the comparison target (TUFF) is obscure, the benchmark setup is too vague to draw conclusions from, and the only real takeaway they see is that a bounded, process-owned cache behaves better than leaning on the OS page cache. They want an architecture section covering expert import/eviction logic, comparison to EdgeMOE and other prior work, a statement of novelty, and published test runs with variance charts. This echoes the post's own caveat that nothing is reproducible without released code.
- Author follow-up: tarassenkov, who appears to be the author, reports an iOS port. On an iPhone 13 Pro (A15, 6GB RAM) running Ling-mini-2.0, a 16B MoE, they see about 13 tok/s. Memory use, long generations, and thermal throttling are still untested.
- Alternative approach: locust_p takes the opposite route to running a 120B model: two used HP DL380s with 256GB RAM each (about $700 apiece), running four gpt-oss:120b VMs on CPU at 10-15 tok/s each. They use it as an overnight tier for hard tasks that a 16GB RTX 5070 Ti and an M1 Max 32GB can't handle.
Nobody checked the shared-memory or file-cache findings, so the headline result is neither confirmed nor refuted here.
Testing Claude on real-world electronics design
Submission URL | 17 points | by rbinv | 3 comments
Claude designed three working hardware devices from a one-paragraph prompt each, and the prototypes booted with no circuit fixes. Anthropic and Diode Computers had Claude "Fable 5.2" build a USB speakerphone, a voice-assistant hub, and a battery-powered handheld pet. Claude wrote the spec, drew the schematics, placed and routed the PCB, designed a 3D-printable enclosure, wrote the firmware, and produced the parts list. Diode assembled the boards under its direction. The speakerphone has reportedly run for weeks.
The gain is geometric reasoning. Earlier models put support parts too far from the chips they served and flipped connector orientations. Fable 5.2 routes the critical nets first (USB and Ethernet differential pairs on the hub, with length matching and tuning zigzags) and lays out power supplies more efficiently.
- PCB Gym (Diode's internal placement-and-routing benchmark): 69%, versus 25% for Fable 5.
- BenchCAD 2.1 (public, rebuilding 3D parts and boards from drawings): 83.5%, nearly double Fable 5.1.
The more interesting behavior is self-correction. Older models produced boards that were "95% complete but still unusable" because they never backed out of a placement that couldn't route. Here, Claude reassigned pins on two chips so the speakerphone's four-layer board kept touch-control tracks on a single layer. It also re-laid an entire crowded corner instead of adding layer-hopping jumpers.
The caveats are the author's own. These are early prototypes, long-term durability is unknown, and nobody has checked whether they'd pass commercial certification. PCB Gym is Diode's internal benchmark, so the 69% can't be independently reproduced. Still, "works on first assembly" is a harder bar than most AI-hardware demos clear.
The thread is small, and its main argument is skepticism about whether PCB design can be fully automated, plus a few practical data points.
- The skeptical case (andyfilms1): The post says nothing about how long the designs took or what they cost in tokens. They also argue that layout is self-bottlenecked, because you can be halfway through before learning you must redo everything, and that no one can predict this up front. Much of the work is judgment: no board hits 100% on crosstalk, parasitics, DFM, BOM cost and length matching at once, so deciding where to fall short is part of the job. Other choices have no empirically right answer: bus frequency, power draw, standby life, thermal limits. They suspect this would be an "overfitting nightmare" for an AI.
- Cost answer (jakescustomshop): The article has a plot of electronics benchmark scores against dollar cost, and every tested model landed between $2,000 and $5,000. That is the closest thing in the thread to an answer on cost.
- Hands-on comparison: The same commenter has tried GPT 6.1 Sol for PCB routing and found the results "ugly and inefficient", mostly the model just running an autorouter. Sol was good at part selection given loose constraints and JLCPCB's inventory. This suggests the gap between model families is large, and that part sourcing is easier than geometry.
- Tooling idea (hard_times): Hardware needs a good general-purpose modeling language, "some sort of UML for hardware".
The open question is whether the judgment calls andyfilms1 lists can be encoded at all, or whether the model is only a very good executor of choices a human still has to make.
The same H100 costs $2.69 or $12.29 an hour depending where you rent it
Submission URL | 165 points | by datareceipts | 84 comments
The same H100 SXM 80GB runs $2.69/GPU-hr on RunPod Community and $12.29 on Azure's ND96isr_H100_v5, a 4.57× spread. That's $1,964 versus $8,972 for one GPU over a 730-hour month. AWS's p5.48xlarge sits at $6.88, RunPod Secure at $3.99.
The method is what makes it credible. The author compares only within a single (model, memory) group, since SXM 80GB, PCIe 80GB and NVL 94GB all get sold as "H100" at different prices. Each vendor contributes only its cheapest route to a given GPU, so Azure-vs-Azure gaps (the same A100 PCIe is $3.67 per GPU at one per VM, $4.78 at two or four) don't inflate the market spread. Prices come from the AWS Price List and Azure Retail Prices APIs; neocloud prices are transcribed by hand with a source URL and date.
The spread isn't pure margin, and the write-up says so:
- Interconnect: Azure's ND SKU includes 400 Gbps per GPU of Quantum-2 InfiniBand with GPU Direct RDMA, which multi-node training needs. That's why it costs more than Azure's own single-H100 NC SKU at $6.98.
- Hosting and SLA: RunPod Community is third-party hosts renting their own hardware, with no datacentre SLA, compliance coverage or committed capacity.
So single-node fine-tuning pays for an interconnect it never uses, while a 64-node training run can't use the cheap row at all.
The caveats cut in the hyperscalers' favor. These are on-demand list prices in one region each (us-east-1, eastus). Reserved, committed-use and spot pricing all lower the AWS and Azure numbers, and spot would narrow the gap considerably. Availability isn't priced either, and a cheap H100 you can't get isn't a price. Lambda is excluded from the headline because its published rates only take effect 2026-11-16 and current ones are behind a login.
Everything is reproducible in Python, though collect.py pulls a roughly 1 GB AWS index and is slow.
The thread barely touched the pricing method and went straight to one question: is the cheap row (RunPod Community, Vast) safe for real work? The opening comment said no, claiming hosts peek inside VMs and that this is openly discussed in their Discords. Nobody produced evidence. One commenter asked for an explanation and another for screenshots.
The "who cares?" camp. Plenty of workloads aren't secret, such as fine-tuning a strawberry-picking model, prototyping on public datasets, or processing public data. A model trained on one product's specific inputs and outputs has little value to a competitor. Some users trade privacy for price knowingly, like accepting public Onshape models in exchange for a free license. Counterpoints:
- Privacy should be the default.
- Training data can be sensitive even when the model isn't. Unredacted support tickets are the example given.
- Pre-extracting features doesn't reliably hide inputs, because latents are often built to carry enough information to reconstruct them.
The trade-secret law tangent. The argument was that a competitor wouldn't risk trade secret liability. Several commenters (some "IANAL") countered that you must take reasonable steps to protect a trade secret, and uploading it to a host with only boilerplate terms undermines the claim. Others cited the DTSA and CUTSA and the Levandowski/Uber case to rebut the claim that trade secrets sit outside enforcement. One person raised competitors in jurisdictions like China, which another doubted was a likely scenario.
Are hyperscalers actually safer?
- One side argued that big providers have far more to lose from a leak, that snooping would need internal mechanisms many people know about, and that a whistleblower would expose it.
- The other side answered that corporate controls often rest on "pinky-promises" and legal threats, and that you can never know whether an individual insider is looking. They cited a linked comment describing a mechanism and process for access that apparently didn't hurt Amazon's customer retention. Amazon Basics and AWS's use of open-source projects came up as examples of using visibility into the platform. Another reply noted that public marketplace data isn't a trade secret anyway.
- A commenter claiming to work at a big cloud provider said peeking isn't happening regularly and safeguards keep growing. A reply granted that but said it still happens.
Practical notes on the marketplaces:
- RunPod's structure (third parties renting their own GPUs) makes consistent privacy hard to guarantee.
- A Vast user reported firmware or power-limited GPUs, such as 5090s stuck at about 80% clock, and no clusters. Others said Vast shows measured specs and power limits and lets you filter on them.
- One commenter said RunPod's serverless tier lets you choose security and compliance levels.
- UpCloud spot instances were suggested as an alternative.
- Someone asked whether confidential computing could help, but no one answered.
- One commenter pointed out that the AWS-vs-Azure gap of roughly 1.8x matters regardless of the privacy debate.
The thread never settled where the trust boundary sits. It ended up as a threat-model question: whether you're worried about a random host, an insider at a big cloud, or neither.
Commerce Dept Inquiry into Megaspeed Halted After Nvdia Intervention
Submission URL | 50 points | by louiereederson | 5 comments
A Commerce Department inquiry into Megaspeed was reportedly halted after Nvidia stepped in, according to the New York Times headline. The title is all that came through, since the article itself was paywalled.
What the title supports: a government review of a company named Megaspeed stopped, and Nvidia's intervention is cited as the cause. The "Huang" in the URL slug suggests CEO Jensen Huang was involved, but that's an inference from the link, not something I can confirm.
What it doesn't tell us: what the inquiry was examining, how Nvidia intervened, who at Commerce made the call to stop, and whether the halt is temporary or final. Without those details, the policy implications are guesswork. The open question is whether a chip vendor can effectively end a federal inquiry into one of its customers.
The thread is short, but the most useful comment corrects the framing. According to reasonableklout, the halt isn't new: it happened late last year and is only now resurfacing amid scrutiny of Jensen Huang's alleged relationship with the Megaspeed executive. Quoting the reporting, Commerce investigators were months into a probe of the Singaporean data center company, suspected of smuggling Nvidia AI chips into China. The executive is now believed by U.S. officials to be a Chinese spy. The case was moved to the Justice Department after investigators got an email from Nvidia's general counsel asking about the inquiry. That answers the submission's open question on mechanism: the intervention was an inquiry from Nvidia's lawyer, followed by a transfer of the case rather than an outright shutdown.
Reactions built on that:
- Legal exposure: steakscience argues the facts now look like Nvidia knew about the smuggling, tolerated it (illegal), and worked to conceal it (worse), so it's hard to see no one going to jail. They also note the "blinded by love" narrative may give Huang a publicity pass.
- Political risk: dgellow calls this the real scandal. They add that Trump is looking for a political win after the elections, which makes it an uncomfortable time to be Nvidia's CEO.
- Double standard: duxup sums it up as rules for thee and not for me and my friends.
The thread offers no pushback and doesn't touch the key open point: whether the transfer to Justice was a neutral reassignment or a sign of interference.
Asahi Linux Drops MIT, Goes Full GPL After AI Used to Steal Unreleased Code
Submission URL | 69 points | by majorchord | 33 comments
Asahi is relicensing every repository from MIT to GPL v2-or-later, after finding that in-development features had been lifted from developers' personal forks, sometimes before public release, and run through LLMs to obscure where they came from. The project says the MIT license "explicitly allows this, and has no carveouts to protect against bad faith actors."
The stated motive is blocking someone from "replacing the project and aggressively monetising Linux on Apple Silicon." The GPL won't stop a determined bad actor, and stripping attribution already violates MIT. What it removes is the legal path to a closed, paid Apple Silicon distro built on Asahi's work. It also makes copying easier to spot, since any distributed product would have to ship its source. The precedent is WINE, which moved from MIT to LGPL in 2002 after companies sold proprietary forks.
Asahi names no one. The article points to two recent AI-assisted forks as context, not as confirmed targets:
- Aurora Silicon, whose Vulkan driver Borealis forks Asahi's HoneyKrisp and lives in its own Mesa fork.
- Gravity Linux, a Fedora-based distro that split over Asahi's ban on AI-generated contributions. The author says it is open source, non-commercial, and upfront about its AI use, so it isn't the villain Asahi describes.
The sharpest pushback comes from the BSD side. OpenBSD's Apple Silicon support depends on Asahi's m1n1 bootloader, and OpenBSD developer Bryan Steele called the move "burning bridges for no reason," saying it was done seemingly without consent from all prior contributors. That is the open question: Asahi hasn't said how existing contributions get relicensed or whether every past contributor agreed.
The article's author thinks this is the first major project to go copyleft specifically over AI code laundering, and expects other reverse-engineering and hardware-enablement projects to follow. That seems plausible. Those projects do the hard discovery work, and rewriting from it is cheap.
The thread splits into three arguments: why Asahi did this, whether the GPL can accomplish it, and whether an LLM rewrite counts as copying at all.
Motive. Several commenters say the real trigger was Omarchy, not anonymous scammers. They frame it as a political reaction to a distro Asahi dislikes (dingi, trombuance), and dingi argues the GPL is the wrong tool, so Asahi would need a custom license with its restrictions written in. KetoManx64 defends Omarchy as a free, open project that has brought many people to Linux. bigyabai answers that Omarchy doesn't contribute upstream, and that copyleft is aimed at downstream projects relabeling others' work as their own features. wmf asked for evidence that closed-source forks charging money exist for Asahi specifically. cowlevel cited Amazon and ElasticSearch as general precedent, and nobody produced an Asahi example.
Does the GPL help? snvzz predicted AI rewrites will continue but without attribution. reverius42 asked what deterrent that offers, and imtringued noted that people already recreating the work have no intention of sharing it. snvzz's reply was that a stricter license makes recreating look more attractive than reusing, and that agentic tools have upset that balance. phendrenad2 also corrected the framing: MIT already requires the license text and copyright notice to be kept, so stripping attribution isn't something it permits. The GPL won't stop that behavior either, though it does block closed forks.
Is an LLM rewrite "from scratch"? This was the longest exchange.
- Skeptics: If the model has seen the GPL code, a reimplementation is debatable, especially since LLMs have emitted blocks very close to GPL source (Someone). Claiming "clean lab" isn't worth much until it holds up in court, and Someone said no court has ruled on this for LLMs.
- Defenders: theturtletalks argued that a model given only documents, with no access to the repo, is doing reverse engineering, even if the model was trained on that code. snvzz argued that learning from code is no different for an LLM than for a human. As an example, he said everyone who learned OS development from Tanenbaum's Minix book would otherwise be barred from writing an OS. He sees code becoming a commodity.
- Crux: where learning ends and reproduction begins is an unsettled gray area, and Someone challenged the "didn't have access but was trained on it" premise as self-contradictory.
What counts as trivial code. charcircuit said trivial code isn't copyrightable. rerdavies countered with Oracle v. Google, where a jury found infringement over a 9-line RangeCheck function, and said the legal line is vague and expensive to test. conartist6 added that RangeCheck is better understood through "convergence" (independent authors would land on the same result) than through fair use, though few cases have argued it. cowlevel said anything needing an LLM to launder it probably isn't trivial, and that many trivial pieces can add up to something that is. rerdavies worried an LLM rewrite might be treated as a "trivial transformation" that leaves the original copyright intact.
Side threads:
- motbus3 said the deeper problem is that software has lost competitive value, since a clone can be made from a video or description.
- rvz and majorchord argued over whether the submission broke the guidelines by linking a secondary source instead of the original.
- kalleboo explained that Mac audio needs ALSA changes because Apple expects software to model speaker temperature and limit volume, which other laptops handle in hardware.
- krapp asked: "When did AI ever give attribution?"