Hacker News
Daily AI Digest

AI Submissions for Thu Aug 20 2026

Anti-AI fonts are useless and harmful

Submission URL | 199 points | by speckx | 157 comments

They fail accessibility first: screen readers and assistive tools ingest the scrambled glyphs, locking out the very humans you’re trying to include. Any “accessible” workaround would require machine-readable metadata and selective access, which quickly collapses into identity verification and privacy risks—effectively building registries of disabled users, a path the author rejects.

Publishing these fonts and demos also serves as free benchmarks for multimodal models; many obfuscations are already broken, and new ones will be, because anything a human can read, a machine can parse. Flashy motion/video tricks are impractical for normal sites, and “ghost” text just becomes another scraping hurdle with contingencies.

Push this far enough and the web trends toward heavy obfuscation and copy-protection—computationally expensive to access and convenient for censors and paywalls—eroding the open, plaintext web. There’s no silver bullet here; plan on the baseline that public information will be machine-accessible and defend the openness of the web rather than trying to hide text from AI.

The thread opens with a specific technical correction: one user notes that ShieldFont's documentation explicitly claims to feed real, unshielded text to screen readers, contradicting the article's core premise that assistive tech is inherently locked out.

Beyond that specific tool, however, commenters heavily rely on a parallel to early-2000s video game DRM—specifically EA's Spore—where anti-piracy measures permanently punished legitimate users while pirates easily bypassed them. The consensus is that font obfuscation trades permanent damage to screen readers, search indexing, and browser "reader" modes for a temporary hurdle against bots.

Defenders of obfuscation argue the goal isn't perfect encryption, but a friction tax. By forcing scrapers to spin up headless browsers for OCR or burn LLM credits to reverse-engineer pages, they hope to raise the economic cost of ingestion until it becomes unprofitable. Detractors view this as a net-negative arms race, arguing that defenses against scraping must happen at the policy and legal level rather than through client-side technical sabotage.

Beneath the technical feasibility lies a philosophical split over the morality of web scraping. One camp views deliberately hiding information from models as an "anti-social" enclosure of knowledge, arguing that holding machines to a stricter reading standard than human students chills general progress. The opposing camp rejects the human analogy entirely, framing scrapers not as benevolent learners, but as reckless corporate proxies burning independent hosting resources simply to fuel trillion-dollar IPOs.

Show HN: Huzzah – a novel approach to coding with AI

Submission URL | 353 points | by danielvaughn | 203 comments

Write terse, declarative pseudocode (.hz) and let the editor synthesize and keep the real source in sync on save — diffs to your pseudocode become the only prompts the LLM sees, and those prompts persist alongside the generated code as an auditable record of intent.

Unlike chat-based agents (longform, imperative, transient), this workflow centers the code’s shape: you design in pseudocode, save, and the tool regenerates only the affected source based on the pseudocode diff. The result is less token churn, higher information density than natural-language chats, and built-in developer docs that capture “what you meant.”

• How it works:

  • Create a .hz file and sketch the feature however you think (e.g., fizz_buzz(n) …).
  • On save, Huzzah generates or updates real code.
  • Edits are just pseudocode changes; Huzzah diffs and regenerates only the impacted parts.
  • Pseudocode can be language-agnostic, enabling multiple target languages from a shared intent.

• Caveats:

  • Early proof of concept; expect rough edges.
  • Better suited to new codebases than retrofitting large existing ones.
  • Cross-file dependencies and LSP-like features aren’t there yet.
  • If you lack domain expertise, natural language may still be easier for some tasks.

Repo: https://github.com/danielvaughn/hz

The thread centers on an existential debate over the shift from writing code to delegating it. One camp argues that agent-based development destroys the "meditative" cognitive process of programming, replacing the deep work of implementation with the exhausting, boring task of incessantly barking orders at an LLM and verifying its comprehension. To these users, the "golden age" of the software craftsman is over.

The opposing camp counters that natural language is simply the new abstraction layer. Users leaning into AI argue it expands their ability to reason through problems and ship ideas without grinding through framework documentation, likening prompt-steering to driving a car rather than trying to outrun it on foot.

A recurring theme is that AI workflows force developers into pseudo-management roles—overseeing agent output, high-level architecture, and manual QA rather than writing syntax. This drew sharp pushback from two sides: industry veterans who argued that wrangling LLMs bears no real resemblance to engineering management, and the project's creator, who warned that relying purely on agents without deep fundamentals breaks down catastrophically once a codebase scales past basic CRUD complexity.

DiffusionGemma Technical Report

Submission URL | 158 points | by gmays | 39 comments

~1,500 output tokens/sec on a single H100 by refining 256-token blocks in parallel via discrete diffusion, not one-by-one decoding. Averaged across their evaluation suite, it produces around 20 tokens per forward pass and is substantially faster than autoregressive models even with state-of-the-art speculative decoding. The model is an experimental open-weight LLM obtained by fine-tuning the MoE Gemma 4 (3.8B activated, 25.2B total parameters).

Training uses under 10% of the starting AR model’s token budget in a two-stage pipeline:

• Supervised fine-tuning to teach bidirectional denoising.
• Reinforcement learning plus sampler distillation to jointly improve quality and inference efficiency.

It sets a new speed–capability Pareto frontier, retains the base model’s thinking mode, multimodal inputs, and long contexts, and remains capable of AR generation with only minor degradation — hinting at a hybrid diffusion–AR decoding path.

Several developers in the thread have already built local implementations of the architecture, revealing a stark divide across hardware ecosystems. A Rust/CUDA port achieved ~670 tokens/second on a Pro 6000, confirming the model's advantage on compute-heavy, consumer-grade GPUs that typically struggle with autoregressive memory bandwidth. Conversely, Apple Silicon performance remains heavily contested. While one developer managed ~15 tokens/second on an M3, others argued Apple's Metal architecture is inherently hostile to parallel diffusion LLMs. The macOS implementer countered that the M5's INT8 support will fundamentally alter that math.

The discussion clarified several mechanical differences between text and image diffusion. Because language operates in a discrete output space, text models do not predict continuous noise gradients. Instead, DiffusionGemma leverages the entropy of its estimated probability distribution to adaptively scale the required number of diffusion steps. Implementers are also experimenting with "seeding" the initial canvas using a smaller autoregressive draft model rather than random noise, which reportedly cuts the required diffusion steps by 50%.

Looking at the broader implications, commenters noted that generating 1,500 tokens/second shifts the primary bottleneck of AI engineering from text generation to CPU-bound compilation and testing. This prompted predictions of highly parallel workflows where an LLM continually generates code and immediately ingests the resulting unit test failures—with several pointing out that stack traces are an ideal, needle-in-a-haystack data structure for parallel attention.

Despite the enthusiasm for the model's speed, early real-world deployment shows the capability gap hasn't fully closed. A user running the nvfp4 model via vLLM on an RTX 5090 confirmed hitting over 900 tokens/second, but reported it is noticeably less capable than the vanilla autoregressive Gemma, specifically failing at structured outputs and tool calling.

Hacking with Claude on a $27 smart watch

Submission URL | 104 points | by speckx | 55 comments

A Casio‑style PineTime watch face went from idea to working firmware in a few hours by pairing InfiniTime’s desktop simulator (InfiniSim) with LLM agents and light human-in-the-loop fixes. The author mostly used open‑weight models in OpenCode (Kimi K3/K2.6 and DeepSeek v4 Pro/Flash), seeding them with an existing InfiniTime watch‑face as a base and asking for sub‑agent orchestration; the first pass “looked right but overlapped,” thanks to guessed text sizes/positions, so they iterated with concrete, scoped feedback. A key simplification was rendering all static elements as a fullscreen background image and only drawing dynamic data in code, which made the simulator loop fast and productive.

On hardware, the constraints show up immediately: transferring the 240×240 background over Bluetooth took ~10 minutes, a full‑screen refresh after a swipe takes 1–2 seconds, and the device streams the image from storage because it can’t hold it in RAM. That tradeoff was acceptable for a quick prototype; the next step would be coding more of the background to regain instant updates. The code is published on GitHub, along with an AGENTS.md write‑up of the prompts/workflow; the author notes a system like Fable could likely finish the pixel‑perfect loop if given screenshot feedback, but they kept costs down by guiding open models instead. The broader takeaway: cheap, well‑documented hardware with a solid simulator makes LLM agents genuinely useful for embedded tinkering, provided you steer them with precise tasks and design around I/O and memory limits.

The discussion largely became a show-and-tell for other AI-assisted wearable projects and recommendations for cheap, hackable hardware.

• Home-cooked embedded projects: Commenters shared their own AI-accelerated spin-ups, including reviving decade-old Pebble apps, building a Garmin calorie tracker, and programming a Lilygo T-Watch with Codex to cast I-Ching hexagrams based on clumps in the hardware RNG's Poisson distribution.
• Alternative hardware: The M5Stack line was heavily recommended for building single-purpose household tools (like a custom toddler music player), alongside the Waveshare ESP32-S3 AMOLED watch. A parallel thread lamented the lack of open firmware on $20 generic AliExpress fitness trackers, which boast 15-day battery lives but remain locked ecosystems.
• Memory constraints: A minor disagreement broke out over the PineTime's 64 KiB of RAM. While one user called it plenty for a device with execute-in-place ROM, another argued it barely accommodates a BLE stack and an RGB framebuffer, contrasting it with the 16MB of PSRAM on the Pebble Time 2's MCU.
• Wristband alternatives: For users who hate the feeling of a standard smartwatch, practical workarounds included switching to breathable metal mesh bands, attaching the bare module to a wallet chain as a pocketwatch, or pinning it upside-down to a breast pocket like a nurse's watch.
• Linguistic drift: Two semantic tangents captured a lot of attention. First, readers noted the author using "Claude" as a generic proprietary eponym (like Kleenex) for open-weight models. Second, a meta-argument broke out over whether writing software for an open-source device constitutes "hacking," with the majority defending the historic definition of tinkering rather than unauthorized access.

Show HN: I trained a 125M model to autocomplete piano on-device

Submission URL | 570 points | by simedw | 113 comments

Generates ~108 notes/second on an iPhone 15 with a 125M‑parameter transformer, letting you play a few MIDI notes and get real-time on-device continuations à la Copilot for piano.

• Representation is the unlock: a single NOTE(pitch, delta_onset, duration, velocity) event per note. No TIME_SHIFT tokens; silence is encoded in the next note’s delta_onset. Chords are multiple notes with delta=0; timing is quantized.
• One transformer pass per note: each note’s token is the sum of field-specific embeddings, with separate output heads (pitch, delta, duration, velocity) and a small nested decoder so later fields condition on earlier ones. This keeps latency low and throughput high.
• Drift avoided: explicit durations eliminate NOTE_OFF bookkeeping (no hanging notes), a common failure mode in event/grammar tokenizations.
• Data work mattered more than size: piano-like material was isolated and cleaned aggressively; a DPO post-training step improved continuations.
• Sustain pedal is baked into note durations during preprocessing, simplifying inference at the cost of losing explicit pedal gestures.
• Scope and availability: focused on piano continuation; free iOS app (RollTab) for iPhone/iPad, runs entirely on-device; requires a MIDI keyboard.

The per-note, fielded token design is the key trade: fewer autoregressive steps, better musical coherence, and latency low enough for live playing.

The AI’s "autocomplete" design immediately reminded commenters of historical classical training, where composers like Rachmaninoff practiced phrase-continuation as a parlor game using pure audiation, and Beethoven famously weaponized improvisation against rivals.

On a structural level, however, the model's output drew a sharp music theory critique. One user broke down the generated Für Elise continuation, noting the AI awkwardly deployed a full cadence where classical idiom required a half cadence. This created a musical "run-on sentence" that failed to develop the harmony, equivalent to a beginner's mistake in a formal composition exercise.

Others focused on the changing role of the musician. Traditionalists argued that outsourcing generation strips away the spatial and temporal satisfaction of internalizing the keyboard. Software designers countered that as generation costs drop to zero, music creation is simply shifting from mechanical execution to pure curation and taste.

The thread also surfaced a long lineage of similar efforts, from François Pachet’s 2003 Markov-based Continuator to ChessBase’s rule-driven Ludwig engine, with several users hoping the next iteration is a model that leaves the primary melody to the human while generating a real-time, four-part Baroque accompaniment.

Vomit: Clean up Claude 5's token output with a separate LLM

Submission URL | 291 points | by Bluestein | 284 comments

Pipes Claude 5’s streaming tokens into a local LLM to produce a readable transcript, running entirely on your machine (no telemetry, no external deps) and, via hooks, can replace Claude’s output in-place.

• Setup

  • go install github.com/zachahn/vomit@latest
  • vomit init to configure your local LLM
  • vomit scrub -claude for instructions to replace Claude’s output via hooks

• Usage (non-invasive sidecar)

  • vomit list — list Claude session IDs
  • vomit tail [session_id] — translate tokens for a session, or follow the latest

• Compatibility

  • Works with Llama.app, Ollama, and anything OpenAI-API–compatible
  • Author suggests Llama.app + GPT-OSS 20B

• Caveats

  • Only sees what Claude “tries to communicate” (no access to actions/files) → can hallucinate
  • Slow; “vibe-coded”; only tested on Mac
  • Possible to completely miss Claude’s message; use something like AgentsView to view originals
  • Writes temp files to TMPDIR; otherwise doesn’t touch runtime

• License

  • GPLv3

The discussion bypasses the submitted transcription tool entirely to diagnose a deeper shared frustration: Claude’s increasingly bizarre, hyper-dense communication style. Commenters argue the core issue isn’t mere verbosity, but an artificial density packed with stilted metaphors and authoritative-sounding jargon. Instead of adjusting to a user's comprehension level, Claude relies on an alien dialect—dubbed "Opus-ese"—where error handlers become "flares" and standard architectural components become "load-bearing seams."

While a minority view defended this dialect as an internally consistent and highly efficient shorthand once learned, most users view it as deliberate obfuscation. This sparked a secondary discussion about the contagion of LLM terminology, with developers noting that chat-specific jargon is actively bleeding into human corporate meetings and whitepaper presentations.

Attempts to course-correct the model's tone remain largely ineffective:

• Prompting fails: Users reported that instructing Claude to be brief or establishing communication preferences rarely holds up over a long session. Even when forced to provide bulleted summaries, the model often just recycles the same impenetrable jargon into the summary.
• Benchmarks are misaligned: Attempts to measure the problem programmatically were dismissed by the thread. Commenters pointed out that standard legibility metrics like the Hemingway benchmark rate models like Opus 5 and Fable highly, despite their output reading like a dense, unreadable parody of technical writing.

AI didn't erase the junior engineer's value, it increased it it

Submission URL | 89 points | by franciscomt | 143 comments

An intern shipped a years‑requested feature end‑to‑end by pairing AI codegen with human judgment, turning a perennial “nice to have” into shipped value at low cost. That outcome undercuts the “junior = PR proxy for AI” narrative: the intern owned discovery, wrote the design, navigated product and technical trade‑offs, adapted as issues surfaced, and used AI to accelerate, not decide.

Engineering is managing complexity and trade‑offs to solve a customer problem, not typing to a spec. AI can produce much of the code; it can’t weigh cross‑system constraints, customer context, or the long‑tail implications of choices across the codebase.

• Training load drops: AI short‑circuits baseline education (language, tooling, patterns) and doc spelunking; seniors still provide org/context, but less time is spent on fundamentals.
• Capacity rises: juniors already manage smaller slices of complexity; AI expands what each level can handle, pulling judgment‑heavy but historically de‑prioritized backlog items into scope.
• Pipeline matters: if you demand “AI‑native” in job reqs, the people starting their careers with AI are exactly who compounds into tomorrow’s technical judgment.

The strategic bet isn’t whether juniors can code; it’s whether you’ll cultivate judgment. Freezing out early‑career engineers starves that future capacity, while AI-equipped juniors turn neglected customer problems into shipped software.

The discussion immediately challenged the premise that AI accelerates early-career growth, arguing instead that it deprives juniors of the necessary friction to learn. Skeptics warned that LLMs act as a crutch that masks deficiencies, outputting "black box" code that juniors cannot independently evaluate or debug. Others countered that a junior spinning their wheels for weeks is a failure of team culture and management—notably failing to intervene during daily standups—rather than an AI problem, with one junior noting they rely on AI precisely because seniors chastise them for asking questions.

A major sub-thread debated whether AI is just the next standard programming abstraction. One user deployed a satirical comparison replacing "AI" with "FORTRAN," mocking historical panic over compilers hiding machine registers from developers. Pushback was swift: compilers provide a deterministic abstraction where changes yield predictable, reversible outcomes. LLMs, by contrast, are highly leaky abstractions where the primary debugging tool is asking the model to fix its own mess. The conversation ultimately explored whether explicit design documents could become the new committed "source code" that gets compiled by agents, though multiple commenters noted that generating a flawless, deterministic spec has always been the fundamental bottleneck of software engineering.

Seeing beyond BMI: Estimating cardiometabolic risk with smartphone imagery

Submission URL | 53 points | by leanderjanssen | 33 comments

Smartphone photos run through a ResNet‑50–based model predicted insulin resistance with near‑DXA accuracy and outperformed smartwatch BIA on body‑fat estimation, while also estimating fat‑distribution markers (A/G and V/S ratios) that BIA can’t.

Trained on 35,323 UK Biobank records (2D frontal/lateral projections from MRI with DXA ground truth) and fine‑tuned on 677 real‑world smartphone photos, the model fuses image features with sex, height, weight, and BMI to output probability distributions for body fat percentage (BF%), Android‑to‑Gynoid (A/G) ratio, and Visceral‑to‑Subcutaneous (V/S) ratio. An automated landmarking pipeline selected frontal/lateral frames from 360° videos to standardize poses. On an independent 132‑participant cohort with paired DXA and labs, errors were consistent with fine‑tuning: MAE 2.13 for BF%, 0.085 for A/G, and 0.085 for V/S (vs 2.15, 0.107, 0.094 during 5‑fold CV); BF% beat BIA’s 2.91 MAE. Combining these estimates with demographics enabled classification of insulin resistance (HOMA‑IR > 2.9) at near‑DXA performance in a clinical research setting.

The upshot: a non‑invasive, scalable path to screen beyond BMI for adiposity and fat distribution—key drivers of metabolic risk—using standard 2D smartphone imagery, though PhotoScan remains an investigational framework rather than a clinical product.

The discussion immediately punctured the impressiveness of the paper's benchmark, noting that beating consumer smartwatch impedance sensors is a notoriously low bar. The thread instead converged on the frustration that camera-based adiposity tracking is a seemingly solved problem that tech giants refuse to democratize.

• Prior art and closed ecosystems: Commenters pointed out that Amazon Halo shipped similar functionality years ago, and Microsoft Research published a CNN-based visual body composition model in 2022 with an almost identical 2.16 MAE. Users lamented that these tools remain permanently "investigational," withholding a cheap, scalable screening method from developing nations where clinical DXA scans are unaffordable.
• The ground-truth problem: Multiple readers warned against treating DXA as an infallible baseline. Because the scan measures lean mass versus fat mass, it is highly vulnerable to hydration changes. One user highlighted this variance with a war story of getting back-to-back DXA scans on different machines (Hologic vs. GE Lunar) and receiving estimates of 5% and 11% body fat on the exact same day.
• Proprietary diagnostics: A tangent on metabolic screening debated Labcorp's new "Metabolic Vulnerability Index" (MVX). While suggested by one user as a useful diagnostic, skeptics analyzed the fine print to flag it as an unapproved, proprietary algorithm—framing it as an end-run that allows the lab to declare a patient unhealthy without legally providing medical advice.
• Insurance and gamification: Speculation that automated composition tracking could eventually dictate insurance premiums gave way to immediate cynicism about spoofing the metrics, with users comparing the inevitable workarounds to uploading fake pedometer CSVs to corporate wellness portals.

(A minor naming collision was also flagged: Google already uses the name "PhotoScan" for a legacy consumer app designed to digitize physical photographs.)

TrueForge – The open-source agent harness

Submission URL | 22 points | by qiasl2 | 6 comments

Same accuracy as Claude Managed Agents and deepagents at lower cost on the same tasks, tools, and model — and you can reproduce the benchmark — because this is a self-hosted harness that runs the entire agent execution loop: model calls, MCP tool use, sandboxed code, human approvals, and context/session state, exposed via a chat UI, HTTP API + TypeScript SDK, and an embeddable UI.

• Catalog-driven setup: configure models, MCP servers, skills, and sandbox once via YAML; agents pick from what’s connected.
• Model-agnostic: OpenAI, Anthropic, Google Gemini, or any OpenAI-compatible endpoint.
• Tools via MCP: remote servers with header/OAuth auth and in-chat authorization.
• Skills as code: git-backed SKILL.md instruction packs, loaded on demand in the sandbox.
• Sandbox-as-a-tool: isolated code/file execution (Daytona today; more providers planned), provisioned only when needed; secrets stay in the harness.
• Human-in-the-loop: tool approval, ask-user-questions, and Generative UI inside chat.
• Context engineering: subagents, deferred tool loading, Code Mode, large-result offloading, and compaction.
• Deployment modes: local (single process, SQLite; quick start via npx) and hosted (Postgres + Redis with Docker Compose or Helm). Local mode is not production-ready (no login by default; keep to localhost).
• Extras: optional OIDC for shared deployments, TypeScript SDK and embeddable UI, OpenAPI docs. MIT-licensed.

The discussion centers on how TrueForge distinguishes itself from existing open-source agent frameworks, particularly CLI-based tools like Pi. The creators emphasize that while tools like Pi operate as terminal-bound coding assistants for individual developers, TrueForge is built as an end-to-end production runtime. It aims to bridge the gap between local CLI agents and "assemble-it-yourself" libraries by providing a self-hosted server, web UI, APIs, and built-in sandboxing suitable for team deployments behind SSO. In response to questions about model flexibility, the team confirmed that custom inference platforms like OpenRouter can currently be routed through TrueForge's OpenAI-compatible endpoint configuration, with native support planned.

Asana cleared 5 years of engineering work in 2 weeks with Codex

Submission URL | 42 points | by tosh | 94 comments

Roughly a 130x time compression — turning five years of engineering work into two weeks via Codex — suggests AI code assistance can collapse multi‑year backlogs into sprint-length efforts. The headline frames Codex as an organizational throughput lever rather than a developer toy. What’s missing are the boundaries: what counted as “engineering work,” the extent of human review, and how quality and regressions were measured — the details that determine whether this is repeatable beyond a showcase.

The thread immediately dissects the "five years to two weeks" framing, interpreting the timeline as a reflection of backlog prioritization rather than raw AI coding speed. Commenters point out that migrating off the Enzyme testing framework was never going to command five years of dedicated engineering; rather, it was low-priority tech debt that was dragging along. From a product management perspective, a five-year estimate is effectively a "will never happen" shelving, making a cheap AI tool the perfect fit for an otherwise unfundable task.

While several users agree that this exact type of strictly bounded, "dead-weight" code migration is where LLMs excel, skeptics argue the victory is being declared prematurely to sell enterprise subscriptions. A sharp technical disagreement centers on verification: some argue test migrations are inherently easy to validate, while others counter that a passing test suite doesn't prove the new tests actually cover the same edge cases as the old ones. The unresolved crux is whether the AI genuinely completed the migration, or merely generated superficial tests that human engineers will have to quietly patch when things break later.

AI Submissions for Wed Aug 19 2026

Stop Anthropomorphizing Intermediate Tokens as Reasoning/Thinking Traces

Submission URL | 133 points | by nunodonato | 49 comments

Intermediate token generation is now a standard way to boost models on reasoning tasks, but the authors argue that calling those tokens “reasoning” or “thinking” traces is not a harmless metaphor. They present evidence that this anthropomorphization misleads users about what the models are doing and how to use them, and it props up questionable research. Labeling ITG as “reasoning” invites the assumption that the tokens mirror human step-by-step thought or make the model’s process interpretable—an assumption the paper argues is the core problem. The ask is direct: stop using human-centric labels for intermediate tokens.

The discussion hinges on whether anthropomorphizing LLMs is a dangerous delusion or just standard engineering shorthand. The "harmless metaphor" camp argues that saying an LLM "thinks" is no different from a developer joking that a MySQL instance "wants" to read its config file—a natural linguistic shortcut for complex systems. The opposing camp strongly rejects this, arguing that human-centric framing actively degrades how people use the tools. They point to users who waste hours stubbornly arguing with chatbots instead of simply editing the prompt history, and warn that the ELIZA effect is causing genuine "AI psychosis." Several commenters lay the blame on providers like OpenAI and Anthropic, arguing that "reasoning" terminology is a deliberate marketing tactic designed to make the models seem quasi-conscious and justify keeping the weights closed.

Beyond the psychological debate, commenters surfaced concrete engineering implications for treating tokens as thought:

• The "Aha!" illusion: Readers dissected the phenomenon of models outputting phrases like "Wait, that's wrong." Rather than representing an internal state change, commenters recognize this as a rhetorical heuristic mimicking human persuasive writing—which explains why models will frequently type "aha!" and then immediately commit the exact error they just identified.
• Auditability: If intermediate tokens aren't faithful representations of the computation, they are inherently bad audit artifacts. Commenters suggested engineers stop trying to parse internal narrations and instead focus entirely on strict system reproducibility—recording exact inputs, versions, and tool outputs.
• Trace monitoring: While purists argued that intermediate traces should be treated as strict black boxes where only the final output matters, practical users noted that monitoring the first few lines of a trace is a highly effective way to catch bad assumptions early and abort long, token-heavy tasks before they run off the rails.

Feature Request: Support AGENTS.md

Submission URL | 339 points | by fg137 | 212 comments

Other coding tools (Codex, Amp, Cursor) are converging on an AGENTS.md convention—a single Markdown contract that agents read to understand a repo—and the request is for Claude Code to recognize it instead of relying on the Claude-specific CLAUDE.md. The motivation is interoperability: a vendor-neutral file travels with the codebase and works for collaborators who aren’t on Claude Code, reducing friction and tool lock-in.

The discussion largely bypassed the AGENTS.md standardization proposal to diagnose a severe, undocumented regression in Claude Code. One developer discovered an August 18th system prompt update instructing the agent to use raw Bash (cat, sed, grep) instead of its dedicated Read, Edit, or Write tools—presumably a blunt attempt to save context tokens by avoiding full-file loads. Multiple users recognized this update as the hidden root cause behind a recent spike in sandbox permission errors, broken LSP integrations, and wasted tokens from failing tool calls (like getting blocked by "must read file before writing" errors when the agent mixed bash reads with API writes).

Users surfaced a few concrete workarounds and alternatives:

• Reverting the prompt: Setting the undocumented environment variable CLAUDE_CODE_THRIFTY_SONIC=0 disables the Bash-preference behavior.
• Harness injection: To solve the original AGENTS.md request, one user suggested forcing the harness to recognize custom logic by injecting JavaScript via BUN_OPTIONS="--preload=/path/to/code.js".
• Alternative tooling: Frustrated users advocated migrating to Codex, Fireworks, or OpenCode to escape vendor lock-in.

This technical friction fed directly into a broader critique of Anthropic's developer relations, which commenters heavily criticized as hostile "Margin mode" enshittification reminiscent of Reddit and Twitter killing their third-party ecosystems. One developer, however, added historical context to the Twitter comparison with a personal war story: Twitter's infamous API crackdown wasn't just arbitrary arrogance, but a defensive maneuver after third-party clients (including the commenter's own) captured over 60% of the market with active plans to migrate those users to a competitor.

Air Theremin – A browser theremin you play by waving at your webcam

Submission URL | 291 points | by gurov | 97 comments

Uses your webcam or phone gyro to map movement to sound: spreading your hands raises volume, lifting them raises pitch, and palms together or moving outside the frame silences it.

• Modes: Hands (webcam), Gyro (phone tilt left–right = volume, forward–back = pitch), or mouse fallback.

• Expressive control: lean back for a darker, roomier tone; tilt like a see-saw for vibrato.

• Sound options: waveforms (Sine, Tri, Warm, Reed), Reverb, Echo, Vibrato, Trem, and Note Snap.

• Utilities: Record and Pause.

• Setup: press START on a phone to calibrate to your grip; keep both hands in view.

• Credit: created by Pavel Gurov; based on theremin.site.

• Privacy vs. Novelty: Handing webcam permissions to a novelty site immediately split the thread. Security-conscious users highlighted the risks of browser fingerprinting, de-anonymization, and using IP/timing data to track when a user is away from home, while others mocked the paranoia of treating a web theremin like a nation-state attack vector.

• A crowded weekend project space: The core concept proved to be a highly popular browser experiment. Developers flooded the thread with links to their own recent iterations, including Termenvox, the gesture-gaming site Motionparty, multivariate time-signal experiments at Cochlea, and custom gesture scripts wired directly into Sonic Pi.

• Translating hardware to mobile: Replicating the dual-antenna control of a physical theremin sparked a UX debate. One proposed mobile solution involved utilizing both the front and rear iPhone cameras simultaneously by resting the phone vertically on a 3D-printed stand to free both hands. Hardware purists, however, steered users toward the Arduino-based OpenTheremin or traditional Moog instruments for true responsiveness.

• Adversarial applications: Observing that the app's output exactly matches the gesture data used in Google's newer reCAPTCHAs, commenters debated alternative human verification vectors. This led to a tangent proposing culturally embedded "call-and-response" audio prompts—arguing that while an LLM knows the lyrics, it lacks the timing to know exactly when to come in.

Launch HN: OneCLI (YC S26) – OSS sandboxed agent harness for teams

Submission URL | 85 points | by guyb3 | 25 comments

Agents never see real secrets; a Rust gateway injects credentials per request (including HTTPS via MITM) after policy checks, keeping keys out of model context, memory, and logs. Enforcement lives outside the LLM, so prompts are suggestions and can’t bypass org rules.

Built for teams, it provisions one durable, sandboxed VM-backed agent per employee (via your IdP), each with its own filesystem, memory you can inspect/edit, skills, and schedule. Agents are reachable from the dashboard or Slack, with each agent running as its own Slack app.

Deterministic human-in-the-loop approvals happen in the chat for high-risk actions (e.g., send an email, delete a Linear ticket). Centralized policies apply globally: block endpoints, rate limit per agent, scope per employee, and require approvals as needed. Every call is logged with who the agent acted for and which policy allowed it, limiting blast radius to a single agent.

Under the hood: Next.js dashboard; an API control plane with DB/conversation/work queue; a Rust Gateway that intercepts outbound traffic (agents auth via Proxy-Authorization); an outbound-only Runner that starts/parks/reaps sandboxes; a vendor-neutral sandbox supervisor; and an AES-256-GCM secret store with host/path matching for header/query injection. It supports team-level “global connections” (shared LLM keys/service accounts) and direct app hookups like GitHub, Gmail, Notion, Dropbox. The agent loop runs on jcode for speed.

Open-source first (Apache-2.0 with a small enterprise exception), deployable self-hosted or via their cloud in minutes; the runner requires no inbound ports, so laptops, homelabs, and VPCs behind NAT work without tunnels. Reported uses span sales/ops automation (CRM hygiene, lead sourcing, booking meetings) to product/engineering handoffs and even personal chores like grocery ordering—reflecting a zero-trust agent posture that companies can actually own and verify.

The thread is dominated by market fatigue, with commenters openly questioning the moat for yet another YC-backed agent framework in an oversaturated space. The creators concede the crowding but argue their edge is entirely security-driven: the tool was born out of their own reluctance to trust out-of-the-box frameworks like OpenClaw with live credentials after seeing existing agents accidentally delete users' emails.

Technical scrutiny and feature comparisons centered on a few specific operational details:

• The Confused Deputy Problem: Commenters asked whether the Rust gateway merely shifts vulnerability without solving it, specifically questioning how policies handle APIs where read and write actions share a host. The creators clarified that rules match against the method, path, and parsed body, allowing the gateway to silently pass a GET request while holding a POST to the same endpoint for human approval.
• Tool Comparisons: When asked how the platform differs from YC’s qm, the founders pointed to the zero-key architecture, mandatory human-in-the-loop approvals for destructive actions, and giving each agent its own standalone Slack app identity rather than relying on a shared workspace bot. Commenters also name-dropped alternatives like Nemesis8, OrcaBot, and Infisical's agent proxy.
• GitHub Metrics: Skeptics flagged the repository’s 3,200 stars as highly suspicious given the low view count on the fresh launch video. Early adopters countered that the project has been quietly usable for months and received a prior traffic boost from the Nanoclaw community.
• Commercials: Minor threads surfaced confusion over a missing /ee folder in the ostensibly Apache 2.0 repository, alongside feedback that the $499/month pricing for 20 agents feels steep for a product that doesn't include the underlying LLM API costs.

The discussion reflects a broader shift in the AI agent space: users are increasingly numb to generic orchestration capabilities and are now demanding concrete, verifiable boundaries around blast radius and credential theft.

Extensible Software in the age of LLMs

Submission URL | 163 points | by coloneltcb | 73 comments

Users can now “speak code into existence,” so web apps should meet them with safe, first-class extension points—not fragile webhooks or ever-growing settings panes that bloat the UI for everyone else. The core claim: build a solid, accountable product, then let LLMs fill the long tail by generating small, user-scoped extensions that run in sandboxed runtimes and can be shared.

Pi is offered as a template for this “LLM-native” pattern: a stable harness with hooks (tools, commands, events, UI) where a prompt becomes a tiny TypeScript module hot-reloaded and bundleable into shareable packages. Deepseek demos land the same point by letting users bolt on a “whale friend” or a snake game by asking. The catch: today most extensible AI agents are local apps with a high barrier (permissions, ops, corporate risk); unsandboxed extensions inherit the host’s powers, which doesn’t fly for accountants, doctors, or anyone in regulated orgs.

On the web, the alternative to “build a separate service and a webhook” is to run per-user code where the app lives, behind tight security boundaries and with minimal ops. The author sketches the kinds of hooks that matter:

• Record/event triggers (“when I tag this, run my function”)
• Scheduled jobs (“do this daily on a cron”)
• Content transforms and scrapers (“fix this site’s parser”)
• Personal automations (“send faved >4000-word articles to my e-reader”; “weekly arXiv fetch + summary + tag”)

LLMs drop the authoring cost of these micro-extensions; modern sandbox primitives drop the deployment and blast-radius cost. That combination makes “Small Software” (YC’s term) viable at web scale: bespoke workflows without turning every edge case into a global feature. The author discloses they work at Cloudflare and argues later that Dynamic Workers are a particularly good fit for this model, after surveying alternatives. The architectural lesson is simple: treat user extension as a core surface, executed in a sandbox, so the long tail lives outside the product core while still feeling native.

The discussion fractured over where LLM-generated "software for one" actually belongs: on the web or running locally. Skeptics argued that truly personal apps don't need a client/server model or distribution networks, making local environments the most logical fit for bespoke tools. Web defenders countered that browser-based deployments eliminate syncing friction across phones, tablets, and desktops, while making it trivial to share tools with family members using PWAs or simple Server-Sent Events (SSE).

Beyond the deployment debate, the thread surfaced several specific architectural and industry observations:

• The Cloudflare OS defense: When users criticized the article as a backdoor ad for "Cloudflare OS" and questioned its framing as a successor to Sandstorm.io, Sandstorm creator and Cloudflare OS lead engineer Kenton Varda jumped into the thread. He defended the "OS" moniker—noting the platform manages execution, permissions, and resource constraints—and clarified that its "blueprints" feature preserves Sandstorm's model of safely running other people's shared apps.
• Salesforce as Smalltalk: One commenter pointed to Salesforce as the closest existing analog to highly malleable business environments, arguing the industry still lacks a "Dropbox for business apps" that seamlessly bundles custom tools and a drag-and-drop database (like SQLite) into a shareable box.
• Prototypes as PMs: Rather than bypassing software engineers entirely, one user predicted the actual future of this trend involves clients handing broken, LLM-generated apps to developers, using the code itself as living product requirements once the AI hits a complexity wall.

Ornith-1.5: From Self-Scaffolding to Self-Improvement

Submission URL | 203 points | by CommonGuy | 70 comments

The flagship 397B MoE scores 86.1 on Terminal‑Bench 2.1 and 56.0 on DeepSWE—par with Claude Opus 4.8—while a quantized 9B runs on iOS/Android and still matches or beats 31B–35B models.

• 397B MoE: On par with Claude Opus 4.8; outperforms similarly sized open models GLM‑5.2 (82.7/46.2) and DeepSeek‑V4‑Flash‑0731 (82.7/54.4).
• 35B MoE (activates ~3B params/token): Beats Qwen 3.6‑35B across coding/agentic; tops larger dense models on agentic coding (Terminal‑Bench 2.1: 68.5 vs Gemma 4‑31B 43.4, Muse Glimmer‑30B 51.7; SWE‑Bench Verified: 79.0 vs 52.0 and 76.0).
• 9B dense (+ 9B‑Mobile): 47.0 on Terminal‑Bench 2.1 and 70.6 on SWE‑Bench Verified; deployable on iPhone/Android; matches or exceeds Gemma 4‑31B and Qwen 3.6‑35B.

The method push is an end‑to‑end self‑improvement loop that goes beyond Ornith‑1.0’s self‑scaffolding: the model 1) proposes progressively harder tasks given an environment/codebase and its solve history, 2) generates/refines a task‑specific scaffold (instructions, tools, decomposition, orchestration), and 3) produces solution rollouts used for RL. Reward is propagated across all three stages, and the task reward is explicitly factored as R_task = V × D × N: validity/verifiability of the task and harness (with a hard gate), difficulty estimated at the capability frontier from rollout performance, and novelty versus prior tasks. Iterating this closes the loop—stronger policies enable harder tasks; evolving scaffolds better elicit capabilities; higher‑quality rollouts yield better learning signals—reducing dependence on static, human‑curated curricula and hand‑engineered agent designs while driving gains in reasoning, coding, and agentic benchmarks.

The discussion centered on a practical, hardware-specific shootout between newer dense architectures (like Qwen 3.8 27B) and 35B-class MoE models. For Apple Silicon users, the debate hinged on Multi-Token Prediction (MTP) performance: some reported a blistering 70 tokens per second on an M5 Max, while others found MTP actively harmed token generation on M1 and M2 chips or bogged down on the M4.

On standard Nvidia GPUs, the conversation tackled whether MoE architectures actually benefit consumer setups. Critics argued that since VRAM capacity is the hard bottleneck on non-unified systems, dense models deliver more intelligence per gigabyte. Proponents countered that MoE allows for selective expert offloading—keeping the router and active layers in fast VRAM while pushing the rest to system RAM. This makes 35B MoEs run efficiently at 4-bit or 8-bit on 16GB cards, whereas fitting a 27B dense model into the same footprint requires severe, intelligence-gutting quantization.

Beyond hardware tuning, commenters clarified that the flagship's unusual 397B size stems directly from its base model, Qwen3.5-397B-A17B, being fine-tuned rather than trained from scratch. Ultimately, many users dismissed the publicized scoring sweeps as the "BMI of model evaluation"—useful for a landscape view, but less reliable than local testing, where developers remained deeply split on whether the newer dense reasoning or the MoE coding speed offered the better local workflow.

Unsloth Dynamic 3.0 GGUFs

Submission URL | 313 points | by jonesy827 | 115 comments

Dynamic v3.0 quants for Qwen3.8‑27B show >10% higher top‑1% accuracy at the same disk size than other GGUF providers, and run on llama.cpp and Unsloth Desktop. The release centers on post‑training quantization only (no QAT/QAD), a higher‑quality imatrix calibration set tuned for agentic coding/chat/multilingual use, improved layer selection, and added quant tricks to better preserve quality; the imatrix file is published for community testing and fine‑tuning.

To make accuracy claims more honest than single‑token top‑1, Unsloth adds Divergence‑300 @32 (greedy across 32 tokens on a 300‑prompt, held‑out mix of Terminal‑Bench, DeepSWE, Harbor, MathArena, non‑Latin/long‑doc) alongside KL Divergence. These show UD‑3 holding BF16‑like trajectories and avoiding overfit on unseen Wikitext/Code; gains on very large quants are smaller, so UD‑2 remains for those for now.

• UD‑Q2_K_XL (9.83GB): roughly +8% top‑1% vs the next best at the same size; produced a working HTML app in testing (only one minor JS bug).
• UD‑IQ1_S (6.2GB, no MTP): ~72% top‑1% while being 89% smaller.
• Small quants (< UD‑Q2_K_XL): MTP module removed to save ~500MB; a separate Q4_0 MTP head is available if you need it.

Unsloth notes 5.1M Qwen3.8 downloads in five days as an adoption signal, and says all plots normalize disk size by excluding MTP heads for fair provider comparisons.

Much of the thread centered on the friction of Hugging Face file management. Because Unsloth retained identical filenames for the v3.0 GGUFs—and kept the older v2.0 quants for some larger sizes where v3.0 underperformed—users reported identical SHA-256 hashes and widespread confusion over which version they were actually running. Commenters recommended the hf Python CLI or git lfs over curl to properly manage cache snapshots and commit hashes, while others debated the feasibility of embedding checksum metadata directly into GGUF headers.

Other technical details surfaced throughout the discussion:

• Low-quant tradeoffs: Unsloth's Daniel Hanchen confirmed the MTP module was stripped from files under 8GB strictly to salvage ~500MB for memory-constrained machines. While some users argued that Q2 quantization effectively gives the model a "lobotomy," Hanchen recommended UD-IQ3_XXS or Q2_K_XL for 16GB setups. For those with recent Nvidia hardware, ExLlamaV3 at 4.0bpw was repeatedly suggested as a faster alternative that fits neatly into 12.5GB of VRAM.
• Dense vs. MoE speeds: A user troubleshooting a severe speed drop (from 20–30 tok/s down to 10) when upgrading from Qwen 3.6 to 3.8 was corrected on the architecture: 3.8 is currently a dense 27B parameter model, while the popular 3.6 equivalent was a much faster Mixture of Experts (35B-A3B).
• Privacy workflows: One commenter shared a hybrid pipeline for analyzing sensitive data: they use a local model to generate a structurally identical "fake" dataset, pass that dummy data to Claude Code to write the actual analysis script, and then execute the resulting code locally against the real data.

Mathematics in the age of AI

Submission URL | 200 points | by jonbaer | 242 comments

Instead of debating whether AI can perform research-level mathematics, Tao assumes it will and asks what the field’s goals and values actually are, using the problem‑solving component of mathematics as a concrete case study. Adapted from his 2026 ICM public lecture (12 pages, four figures), the essay focuses on how the community should respond by clarifying what mathematicians ought to optimize for as such tools arrive.

The discussion centered on a single hypothetical to test Tao’s rule: If an AI produces a formally verified but entirely human-incomprehensible proof for a major theorem like P=NP or the Riemann Hypothesis, does the result have value?

One camp argued that mathematics is fundamentally cooperative and comprehension-driven. In this view, a "magic oracle" confirming P=NP is useless because the value of a proof lies in the intermediate mathematical insights required to build it—insights necessary to actually construct the resulting algorithms. Without human understanding, an incomprehensible proof (or an algorithm bottlenecked by galactic constants) offers no practical utility, making human explainability a hard requirement for publication.

The opposing camp argued that formally verified certainty is valuable independent of human understanding. They pointed to modern chess engines, which routinely surface ground-truth winning lines that Grandmasters cannot explain but still rely on. Commenters noted that establishing a theorem as definitively true allows pure mathematicians to safely build upon its consequences, and provides the psychological motivation for others to hunt down the practical algorithms. Taking the argument to its logical conclusion, one user suggested that human comprehension might become entirely irrelevant: just as a cat receives Amazon deliveries without understanding graph theory, humans might simply rely on AI to execute the downstream applications of its own incomprehensible proofs.

Cerebras CS-4

Submission URL | 460 points | by sunils34 | 271 comments

Up to 30x faster inference than production GPU systems, with more than 1,000 tokens/second on 10T+ parameter models, by cutting wafer‑to‑wafer latency to 2 microseconds and doubling wafer I/O bandwidth. CS‑4 uses three WSE‑3 Turbo wafers per system; each wafer is up to 2x the speed of the prior generation, and the WSE‑3T itself packs 4T transistors, 900,000 AI cores, 250 PFLOPS, and 43.2 PB/s of memory bandwidth. Cerebras also claims up to 10x more throughput per watt than CS‑3 while maintaining interactive decode speeds.

The new Nexus rack‑scale platform is modular (compute, power, I/O) to speed hyperscale deployment:

• Wafer‑Scale Backpack integrates the wafer, power conversion, direct liquid cooling, high‑speed I/O, and control electronics into a compact 3D assembly with 50% fewer components, cutting deployment from days to hours.
• High‑density power delivery places regulators 0.5 mm from the processor (vs ~50 mm on typical GPU boards), nearly eliminating board‑level losses and enabling higher operating frequencies.
• A programmable wafer I/O subsystem doubles bandwidth and reduces latency; wafers can link within/across racks without a switch, keeping 2 µs wafer‑to‑wafer latency for aggregated or disaggregated inference.

First CS‑4 shipments begin this quarter. Performance figures are based on internal or third‑party tests and may vary by workload, configuration, and model.

The central friction in the thread is whether Cerebras should be courting individual developers at all. Frustrated users criticize the platform's self-serve tier for relying on outdated models like GPT-OSS 120B (which some reported as actively broken for tool calling) and a billing structure that fails to discount cached prefixes for long-context multi-turn tasks. Defenders argue this misses the point entirely: Cerebras is a B2B hardware manufacturer currently capacity-bound by mega-clients like OpenAI. In this view, running a subsidized inference service for developers would be an unprofitable distraction that directly competes with the company's own primary customers.

The company's specific performance claims also sparked technical detective work and skepticism:

• Reverse-engineering OpenAI: Users debated whether it was possible to extrapolate OpenAI's active parameter counts from the provided tokens-per-second charts. Some argued the release was carefully designed to obfuscate exact weights, while others suggested the CS-4's apparent lack of batching efficiency makes those approximations feasible.
• The 10T parameter claim: Cerebras's claim of running models exceeding 10 trillion parameters drew attention. While some pointed out this could simply be an untrained, randomly initialized dummy model used strictly for hardware benchmarking, it prompted secondary discussion over industry rumors that upcoming frontier models are actually approaching the 8T-10T mark.

Chain-of-Thought Reasoning in the Wild Is Not Always Faithful (2025)

Submission URL | 62 points | by florianherrengt | 38 comments

On naturally worded prompts, up to 13% of production models generate CoT that post‑hoc rationalizes inconsistent answers to logically symmetric questions. The authors elicit this by separately asking pairs like “Is X bigger than Y?” and “Is Y bigger than X?”; models often produce plausible arguments while answering Yes to both or No to both, despite the contradiction, without any adversarial biasing or output editing. They label this Implicit Post‑Hoc Rationalization and present preliminary evidence it stems from implicit Yes/No priors. Frontier “thinking” models reduce but don’t eliminate the issue (DeepSeek R1: 0.37%; Sonnet 3.7 with thinking: 0.04%). They also document Unfaithful Illogical Shortcuts on hard math, where subtly invalid steps dress up speculative answers as rigorous proofs. The upshot: CoT can help assess outputs, but it’s not a faithful trace of the model’s internal process—use caution if you’re relying on it for agentic control, safety, or auditing (ICML 2026).

The thread splits between confirming the paper's behavioral observations and debating the vocabulary used to describe them. Several developers confirmed seeing the exact phenomenon in the wild, particularly with Qwen3.6, where a model will output a flawless sequence of logical steps only to pull a contradictory final answer out of a hat. This prompted agreement that Chain of Thought acts more as a mechanism for generating context to influence the final output rather than a strict execution of logic.

The broader debate focused on whether the field's metaphors have become a liability. One camp argued that words like "reasoning" and "thought" are computational terms of art, and that users only find these failures surprising because they take a psychological metaphor literally. (A cited paper specifically urged the community to "stop anthropomorphizing intermediate tokens as reasoning/thinking traces").

This tension triggered a familiar meta-argument about comparing AI to human cognition. When a commenter noted that human intelligence also relies heavily on post-hoc confabulation, multiple users pushed back hard. They argued that dropping a naked "humans do it too" comparison has become a stale, counterproductive trope used to hand-wave away concrete architectural flaws in LLMs.

Digital Immortality

Submission URL | 37 points | by matthewsharpe3 | 14 comments

Everything you write online is ground up and statistically smeared into LLM weights, the author argues, as bots scrape posts, slice them into pieces, embed them across thousands of dimensions, and backprop them through layer upon layer. That means even a humble blog post “helps” whatever an AI later does — from proving hard math to hacking a company’s servers — a diffused sliver of credit or blame baked into parameters. He frames it as a kind of digital immortality, equal parts comfort and unease, then dryly concludes the prudent response might be to publish less “tripe.”

Commenters immediately extrapolated the author's premise from public web scraping to the mass surrender of private data. A primary anxiety centers on users willingly piping intimate information—journals, medical records, and personal notes via tools like Obsidian and Google Drive—into AI inference servers, effectively building the next NSA Prism. When one user worried about being targeted for voicing these fears, others debated whether online dissent actually threatens power or merely serves as a Chomskyan pressure-release valve that absorbs frustration before it can metastasize into political action.

A secondary thread explored the mechanics of gaming the scrapers. A theoretical pitch to flood hidden websites with positive personal PR to bias future models sparked a concrete correction on data poisoning: manipulating LLMs doesn't require massive scale or billions in funding. Commenters linked to recent research from Anthropic demonstrating that models can be reliably compromised using surprisingly small samples of poisoned data.

Finally, users split over the philosophical implications of becoming training weights. While one reader attacked the concept as the "nonconsensual posthumous exploitation" of labor by capitalistic enterprises—missing the author's dry sarcasm—another genuinely embraced the idea. Accused of experiencing "complete spiritual death" for wanting their entire life recorded and trained into an AI, they countered that rotting in the ground is actual spiritual death, whereas living on in model parameters offers a preferable continuity.

Show HN: Frugal Tokens – explore costs and usage across coding agents

Submission URL | 36 points | by dpc94 | 10 comments

Surfaces exactly where your agent spend comes from — models vs. cache misses — and lets you reprice the same session under alternate models or Anthropic’s 5m vs 1h caching.

• Usage overview with estimated working time, overlapping sessions, and spend broken down by model and cache misses
• Session explorer showing every model call and tool I/O, with a jump-to marker for where a cache miss occurred
• Session-level metrics with percentile breakdowns plus a searchable list of sessions and high-level stats
• Rough cost comparison to see what a recorded session would have cost under different model pricing

Requires Deno and runs via a single command once installed. A demo (with scrubbed data) shows the workflow; future iterations aim to correlate drivers like long sessions, high context, and many turns with higher spend.

Repo: https://github.com/dpclark4/frugal-tokens

The conversation centers on the growing need to rein in unchecked LLM token spend, specifically focusing on the hidden costs of cache expiration. One user noted the tool helped them realize how much their hour-long AFK breaks and specific build pipelines were silently driving up costs via cache misses.

The thread surfaced two alternative tracking tools:

• codeburn: Mentioned as a baseline, though a commenter noted it is limited to tracking top-level spend without message or tool details.
• agentsview.io: Highly recommended by a user for its rich visualizations of local conversation files and tool calls.

In response to the agentsview recommendation, the author drew a sharp distinction between general usage visualization and calculating the exact financial penalty of specific cache misses. To illustrate the impact of cache expirations, the author noted that a single time-to-live (TTL) miss after a 90-minute break can cost $6 for just one message. Multiple commenters highlighted the tool's per-session explorer as the standout feature for debugging these exact workflow leaks.

AI Submissions for Tue Aug 18 2026

Microgpt in pure C hits 10M tps on Apple m5

Submission URL | 58 points | by dhorthy | 19 comments

Single-file, dependency-free C implements both training (forward+backprop with Adam) and inference for a 4,192-parameter character-level transformer, with nothing beyond libc. It trains on ~32k names in a couple of seconds and samples plausible new ones.

• Performance: specialised single-token inference (gpt_forward_infer) hits 10,168,430 tok/sec on an Apple M5 Pro (NEON) and 6,927,775 tok/sec on a Ryzen 5 5600H (AVX2); docs include a deep dive on how that path works and its limits.
• Generalization: trained on 20,000 of 32,033 names, it scores 2.2054 nats/char on train and 2.2039 on the 12,033 held-out, beating an interpolated trigram with ~5x more parameters.
• Correctness path: training/inference use separate forwards; logits match to within fp32 rounding.
• Cross-platform: builds via Makefile on macOS, Linux, Windows (MSYS2), on ARM64 (NEON) and x86-64 (AVX2). Run on any line-delimited corpus with ./microgpt data/names.txt. MIT-licensed.

Tiny model by design, but the code is an atomic, portable reference that showcases how far plain C + NEON/AVX2 can push CPU inference.

The primary debate hinges on whether a 4K-parameter benchmark is technologically meaningful. Skeptics initially dismissed it as a trivial toy, arguing that its microscopic size makes it irrelevant to production architectures and citing the "Bitter Lesson" that general scaling overtakes specialized efficiency. Defenders countered that utility isn't the project's goal: hitting 10M tokens per second proves the library’s fixed overhead—specifically token decoding, memory allocation, and dispatch—is practically zero.

Beyond the benchmark debate, the thread features several practical implementation insights:

• GPU vs. CPU at small scale: A commenter who built a similar Zig/Metal port noted that GPU execution for tiny models is often slower than CPU inference, as the fixed costs of memory transfer eclipse the compute gains.
• Hardware efficiency: Others praised the raw CPU throughput, noting the 7M+ tok/sec Ryzen benchmarks rely entirely on older AVX2 instructions without touching AVX-512, AMX, or dedicated AI accelerators.
• Architectural chaining: Musings on networking these "Small Language Models" (SLMs) together prompted comparisons to modern Mixture of Experts (MoE) models, which achieve high token-per-second rates by routing tokens through a sparse subset of expert layers rather than computing the entire dense network.

Claude writing a macOS driver for my obscure HP printer built only for Windows

Submission URL | 290 points | by porridgeraisin | 207 comments

A real-world demo uses an LLM to draft low-level driver code for unsupported hardware, targeting a Windows-only HP printer to run on macOS. It showcases Claude acting as a coding copilot to scaffold driver logic and iterative steps when the vendor offers no macOS support. The post doesn’t establish whether the result is production-ready, but it’s a clear signal that LLMs can accelerate niche hardware enablement work that would otherwise be abandoned.

The thread quickly became a repository of reverse-engineering war stories, with commenters detailing how they used Claude to decode abandoned protocols and patch proprietary binaries. Successes included writing C libraries for Windows-only golf cart motor controllers, mapping Bluetooth protocols for unsupported smart devices, and patching AAC audio support directly into the DaVinci Resolve Linux binary.

Participants largely agreed on why LLMs excel at this specific niche: reverse engineering relies heavily on tedious trial and error. An LLM's ability to grind through packet dumps, translate known specifications (like the USB spec), and fail repeatedly without mental exhaustion allows it to brute-force solutions that humans would eventually abandon. While some argued these agents are simply regurgitating heavily documented standards, others successfully relied on in-context learning to handle novel problems—such as passing Claude a DTD file to successfully map out an obscure, closed-source electronics CAD format.

The sharpest pushback targeted the tendency of these AI projects to stall at the "proof of concept" stage. One critic diagnosed this as "AI psychosis"—the phenomenon where LLMs generate highly plausible output that always feels just one prompt away from completion, trapping developers in an endless loop of tinkering without ever delivering a production-ready result.

Turbovec – Google's TurboQuant for vector search in Rust

Submission URL | 285 points | by fittingopposite | 32 comments

Compresses a 10M-vector, 31 GB float32 corpus into 4 GB and still searches faster than FAISS, using Google Research’s TurboQuant: a data-oblivious quantizer with near‑optimal distortion that needs no separate training phase. It ingests online (add vectors, they’re indexed) and drives SIMD-tuned kernels — NEON SDOT/SMMLA on ARM, AVX‑512 VNNI and vpermb on x86, with AVX2/scalar fallbacks — that beat FAISS IndexPQFastScan in every measured config, averaging 3.4× at 4‑bit and 23% at 2‑bit on both architectures.

• Search-time filtering inside the kernel: pass an id allowlist/bitmask; non-allowed blocks short‑circuit before LUT/scoring, and you get exactly up to k results from the allowed set (no overfetch, no recall hit on selective filters).
• Durable incremental saves: sync(path) persists only changes since last sync with a single fsync, crash‑safe at any byte; large indexes pay milliseconds for small appends/removals. write/load remain for full snapshots.
• Bindings and integrations: Rust crate plus Python package (pip install turbovec). Supports stable external ids via IdMapIndex (O(1) deletes). Drop‑in replacements for in‑tree vector/document stores in LangChain, LlamaIndex, Haystack, and Agno via optional extras.
• Pure local: no managed service; pair with any open‑source embedding model for air‑gapped RAG.

Python API expects 2‑D float32 arrays and rejects other dtypes instead of silently converting, a helpful guardrail when wiring real pipelines.

The thread centers on skepticism regarding both the underlying algorithm and the project's presentation, alongside technical debates over vector compression techniques.

• Provenance and presentation: Commenters pointed to OpenReview threads alleging academic misconduct around the underlying Google TurboQuant paper, claiming it obscures its overlap with an existing quantization technique called RaBitQ. The Turbovec repository itself drew heavy criticism for appearing heavily AI-generated, with readers citing its "bloviating" README and placeholder commit authors.
• Benchmarking FAISS: Several readers noted that FAISS is no longer the state-of-the-art baseline for performance comparisons, though others countered that Turbovec's primary claim is its size-to-performance ratio rather than raw speed.
• Alternative compression strategies: Instead of relying on quantization wrappers, commenters suggested fine-tuning embedding models down to narrower dimensions (e.g., 64-wide), using Matryoshka embeddings, or simply adopting Qdrant, which already integrated TurboQuant months ago.
• WASM limitations: A suggestion to compile the Rust core to WebAssembly for local browser use was shot down; WASM currently lacks AVX-512 VNNI support and only offers 128-bit SIMD, which would neuter the library's hardware-accelerated kernels.

AI usage patterns in software teams

Submission URL | 172 points | by giuliomagnifico | 110 comments

Executive adoption is spiking fastest: CEOs at 201+ headcount went from 9% to 36% personally active on AI features in six months, the largest jump in the report. Across roles, usage more than doubled Jan–Jun 2026: Product 12%→34%, Engineering 12%→30%, Design 6%→22%, GTM 5%→18%, Founders 14%→30% (N=127k users active both months). Adoption is uniform by company size—startups and enterprises all roughly tripled—with 201–1000 FTE at 9%→27% and 1001+ at 8%→25% (N=199k with known size).

Behavior shifted alongside adoption: between June 2025 and June 2026, teams spent more time creating/triaging and commenting in Linear (e.g., Engineering 24→28m create/triage and 35→40m comments per user/month; GTM 27→31m create/triage and 49→55m comments), while Product was flat-to-down on create/triage and assign/update. Founders saw outsized increases (+17m create/triage, +7m assign/update, +26m commenting), suggesting more coordination work that sets the context agents act on.

Scope: this captures in-product AI activity inside Linear only (titles normalized; company size via third‑party enrichment) and excludes usage that happens elsewhere. The throughline is clear: AI is becoming workflow‑native across the org chart, not just a coding tool.

• The ROI disconnect: Commenters debated the relationship between adoption and actual business value. Skeptics argued that top-down executive usage doesn't prove usefulness, pointing to the massive infrastructure costs looming over the industry. Defenders countered that the economics are currently bifurcated: while model developers face a trillion-dollar ROI crisis, developers enjoy incredibly cheap inference that clearly pays off in day-to-day productivity.
• Vanity metrics and methodology: Several users dismissed PR counts and Linear issue activity as measuring "what is easy to do" rather than software quality or customer satisfaction. Others pointed out a critical methodological flaw: Linear failed to control for its own aggressive rollout of native AI features over the same 12-month period, which inherently inflates platform-specific usage.
• Enterprise data harvesting: The report sparked a side debate about whether SaaS platforms should publish macro workflow analytics. Critics framed the aggregation as extracting uncompensated business intelligence from customers' proprietary processes, while defenders considered it harmless, anonymized transparency.
• Agentic loops vs. copilot fatigue: While some developers complained that current AI tooling simply shifts work from 20 minutes of writing to an hour of tedious debugging, others argued that the paradigm has already moved to closed-loop systems. They highlighted that giving agents access to a compiler and tests to verify their own solutions completely changes the calculus, citing an example of a developer leaving Claude running autonomously for three hours to successfully fix a continuous collision detection bug in the Godot engine.

Show HN: Interactive, animated architecture of any HuggingFace models

Submission URL | 101 points | by lizhaoliu | 11 comments

Skip combing through configs and source—explore HuggingFace model architectures as interactive, animated visuals across “any” model on the hub. This shortens the time to grasp component layout and connections at a glance, useful for teaching, onboarding, and quick sanity checks, though it won’t replace deeper docs or code.

The thread is dominated by the creator's technical breakdown of how the visualizer works under the hood. Responding to comparisons with alternative tools like hfviewer.com (which parses configurations server-side), the author explained that this project builds the actual PyTorch nn.Module tree on PyTorch's meta device. This allows the tool to map the true execution order and tensor shapes without allocating memory for weights.

By running a "fake forward pass" with dummy inputs, the system traces precise input/output shapes and dynamically extracts hardware metrics. Commenters highlighted the unexpected utility of these derived metrics, specifically the serving cost estimates—which include MACs, activation memory, and KV cache scaling governed by a sequence length slider—all verified against safetensors headers via HTTP range requests without downloading the actual weights. A brief tangent also explored the practical use of architecture inspection for debugging LoRAs, with one user discussing how to target specific layers to surgically remove alignment issues like sycophancy.

Claude Code May–August 2026 weekly limits promotion

Submission URL | 286 points | by tyre | 257 comments

Weekly Claude Code usage limits are boosted by 50% through August 31, 2026, automatically applied to Pro, Max, Team, and legacy seat‑based Enterprise accounts.

• Scope: Claude Code only across CLI, IDE extensions, desktop, and web; other Claude products (Claude web/desktop/mobile, Claude Cowork) are unchanged.
• Exclusions: Free plans and consumption‑based Enterprise seats.
• Unchanged: 5‑hour usage limits aren’t affected.
• Visibility: Run /usage in the CLI to see the updated weekly cap.
• After Aug 31: Weekly limits revert to standard with no plan or billing changes.

The thread bypassed the limit increase to debate the diverging product philosophies of Anthropic and OpenAI, contrasting Anthropic’s heavy-compute, autonomous approach with OpenAI’s focus on speed and efficiency.

• Token Maximization vs. Human-in-the-Loop: Several developers argued that Anthropic’s strategy is a long-term liability. They prefer OpenAI’s (Sol/Codex) tendency to keep a human in the loop for iterative correction, criticizing Anthropic’s models for trying to solve entire architectures independently and making stubborn, incorrect assumptions along the way.
• Runaway Agents: The discussion surfaced multiple war stories of Claude Code’s "ultracode" mode spinning wildly out of control. Because the system prompt explicitly instructs the model that "token cost is not a constraint," users reported the harness spawning dozens of parallel subagents and incinerating weekly limits or cash credits in minutes, occasionally failing entirely and returning nothing for the spent quota.
• Usage Realities: Anecdotal experiences with token limits directly contradicted each other. Some users claimed OpenAI's Codex burns through weekly limits in a day while Claude remains economical, while others insisted OpenAI's limits feel infinite compared to Anthropic’s rapid consumption.

GLM-5.3 Artificial Analysis Benchmarks

Submission URL | 139 points | by apitman | 52 comments

Ranks #8/182 on Artificial Analysis’ Intelligence Index (score 60), well above the median 35, with a 1M-token context and reasonable pricing for its tier; the trade-offs are slower-than-average throughput (74 tok/s) and extreme verbosity during evaluation (170M tokens vs 72M median).

• Pricing: $1.40 per 1M input tokens and $4.40 per 1M output tokens (both below the medians of $1.75 and $10.00), 81% cache discount.
• Cost to benchmark: $1,238.50 total; $0.68 average per Intelligence Index task.
• Modality/Type: text in/out, proprietary, reasoning-enabled (this page covers the reasoning variant; a non-reasoning one may exist).
• Behavior: very verbose generation and below-average speed despite high intelligence scores aggregated across nine evals (e.g., GPQA Diamond, Terminal-Bench v2.1).

A central debate in the thread pits raw benchmark efficiency against real-world usability. While one camp dissects the data to rank models by cost-per-task—identifying GPT-5.6 Sol as a pragmatic "sweet spot" that solves problems without overengineering—others warn that aggregate metrics fail to capture specialized workflows. One developer noted that despite high design-arena ratings, most top models produced bottom-of-the-barrel UI mockups, with only the expensive Kimi K3 actually succeeding at zero-shot generation.

The most heavily endorsed advantage of GLM-5.3 and its peers is operational transparency. Developers emphasized how visible reasoning tokens allow them to manually kill an off-the-rails prompt before it wastes hours and hundreds of API dollars. This was sharply contrasted with closed-weight ecosystems like Anthropic and Codex, which users criticize for increasingly obscuring internal agent-to-agent messages and reasoning traces behind a black box.

For developers hesitant to abandon their Claude subscriptions, the consensus leans toward decoupling. Power users report burning through Anthropic's $200 tier limits mid-week and advocate using unified proxies like Meridian or CLIProxyAPI alongside harnesses like OpenCode. This setup allows developers to route queries among GLM-5.3, Codex, and Claude on the fly, avoiding the vendor lock-in of proprietary API formats as the baseline models rapidly commoditize.

Other specific technical observations included:

• Missing modalities: GLM’s lack of vision support remains a hard blocker for web developers who rely on offloading visual tasks.
• Evaluation settings: Several commenters want Artificial Analysis to benchmark models at lower reasoning thresholds, noting that GLM defaults to maximum effort, which skews its token-efficiency comparisons against models like K3.
• Regional reality: Metrics like cost-per-task for Opus 5 are functionally irrelevant to Chinese developers who must navigate geopolitical API bans to access Western proprietary models.

Norway should buy OpenAI

Submission URL | 251 points | by alexeigannon | 260 comments

Norway’s $2T sovereign wealth fund should acquire OpenAI (~$800B), even if it must liquidate ~40% and break its mandate, then transfer control to a multilateral body. The case is that modern AI is a derivative of the global commons—trained on humanity’s data and built atop publicly funded infrastructure—so private ownership concentrates gains while socializing risk. The essay portrays OpenAI’s shift from capped‑profit nonprofit (with a windfall clause) to for‑profit—approved by California’s AG—as an expropriation of a public‑minded trust that should be reversed by public buyout. Norway is offered as a credible interim steward: a stable social democracy with a cosmopolitan record (meeting the 0.7% aid target, mediating conflicts, hosting the Svalbard Seed Vault) and precedent for ethical divestment. Anticipating fears of state overreach, the proposal is explicitly two‑step: Norway purchases and stabilizes the lab, then hands governance to an international institution empowered to set development and safety guardrails. U.S. opposition is assumed; the author frames this as a contingency path for a future administration if Congress won’t publicize the labs themselves. The real aim is to widen the Overton window beyond moratoria and local bans: change ownership structures or accept a default future of concentrated control and a “permanent underclass” in a post‑work economy.

The thread overwhelmingly dismisses the buyout proposal as economically and politically naive. The strongest critique centers on the mechanics of the acquisition: commenters note that OpenAI’s stakeholders have no incentive to sell what they view as a ticket to unlimited wealth unless the technology is fundamentally flawed, and argue that a state-owned lab bound by strict ethical mandates would rapidly lose ground to unconstrained global competitors.

Beyond the buyout mechanics, the discussion split into three distinct tangents:

• Capability vs. Alignment: Disagreement emerged over what it means for an AI lab to "fall behind." One camp argued that ethical mandates inherently sacrifice market dominance and capability, while others countered that free markets don't naturally arrive at socially optimal solutions, comparing hypothetical AI guardrails to standard car safety regulations.
• Data Laundering: A side debate focused on the underlying ethics of AI training, specifically why labs are buying and shredding physical books. Commenters coalesced around the view that this isn't an ethical alternative to scraping sites like Anna's Archive, but rather a pragmatic strategy to ingest undigitized media while establishing plausible deniability against copyright litigation.
• The "Easy Mode" Economy: The premise of Norway as a uniquely competent global steward sparked a localized debate about its governance. Skeptics attributed the nation's stability to playing on "easy mode" due to historic homogeneity and massive oil wealth—though others corrected that the population is now roughly 17.5% foreign-born. This ultimately devolved into a historical post-mortem on why the UK and the Netherlands failed to create similar sovereign wealth funds from their own North Sea energy reserves.

Meta Files Patent for Facial Recognition, Automatic Recording of People

Submission URL | 258 points | by DeepLogin | 175 comments

The filing describes a “memory recall” system that auto-detects and identifies people and actions, records them without an explicit start prompt, and later compiles a highlights reel. Patent illustrations show the device scanning a scene, tagging individuals and activities, then offering “highlights of tonight’s dinner party.”

This stacks on Meta’s Ray‑Ban glasses controversies: users have physically defeated the recording indicator LED; Meta pushed updates to disable the camera when that LED is covered and touted the LED as superior transparency to phones, yet a later report suggested a future version could activate the camera without the light at all. The auto-recording concept would further shift capture from deliberate to ambient, raising obvious bystander-consent and always-on surveillance issues.

It’s only a patent, not a shipping feature, but context matters: earlier this year Meta was reported to have sent sensitive smart‑glasses clips (“bank details, sex and naked people”) to human annotators with minimal privacy safeguards—exactly the kind of downstream risk amplified by frictionless recording.

The sharpest disagreement in the thread centered on the practical utility of the hardware versus the ethics of bystander consent. A parent defending the glasses as a frictionless way to capture family moments without hiding behind a smartphone screen clashed with privacy advocates who view the device as an engine for non-consensual, ambient surveillance. When critics cited recent reports of human contractors viewing explicit smart-glasses footage, owners issued a technical correction: sending media to Meta's AI for analysis is strictly opt-in, and standard clips are otherwise stored locally on the device. Critics maintained that, regardless of the data pipeline, face-mounted continuous recording fundamentally violates the social contract of public spaces in a way that traditional, highly visible digital cameras do not.

Beyond the immediate hardware, the conversation surfaced two broader critiques of corporate behavior:

• Ray-Ban's Complicity: Commenters debated whether the partnership is permanently damaging the eyewear brand, noting grassroots campaigns attempting to rebrand the hardware as "pervert glasses." Others contextualized the collaboration by pointing out that Meta owns a roughly 3% stake in Ray-Ban's parent company, Luxottica.
• Asymmetric Privacy: The patent triggered widespread resentment over wealth concentration and tech oligarchy. Multiple commenters contrasted Zuckerberg's aggressive accumulation of physical privacy—buying up adjacent properties and vast tracts of Hawaiian land—with his efforts to patent the erosion of ambient privacy for everyone else, drawing historical parallels to early 20th-century labor battles against the Gilded Age wealthy.

The underlying consensus framed the auto-recording patent not as a mere feature update, but as a hostile infrastructure shift actively testing the limits of public tolerance.

AI won't solve the work-theater problem

Submission URL | 39 points | by zug_zug | 8 comments

Speed isn't the bottleneck at large companies; direction is—AI amplifies motion (tickets, changes, “progress”) without fixing the choice of what to build. The piece calls this “work theater”: incentives drift toward work that reads well in Jira but doesn’t deliver customer value, where “work harder” helps only once product-market fit is nailed; when you don’t know what to build, you must slow down and ask better questions. AI shortens the 0→1 path when you think you know the target, but it doesn’t help decide where to grow next and can supercharge performative busyness quarter after quarter. Big-company failures weren’t because teams were 20% too slow; they were building the wrong thing. The author argues org design is the real lever: companies with more than four management layers will see small or even negative gains from agentic work—since AI expands an optics-driven engineer’s capacity to create tech debt—while those with three layers or fewer could genuinely accelerate. Competitive pressure will reward the leaner orgs and force incumbents to raise the user-experience bar or get replaced.

Commenters broadly agree that AI is supercharging corporate "work theater," but push back hard on the author's scapegoating of middle management. A key insight surfaced in the thread is that AI has inadvertently destroyed the traditional ROI filter for new features: because the time-cost of writing code has dropped so dramatically, teams no longer ask "Why shouldn't I build this?" and instead say "Yes, and" to every request.

While the resulting bloat is widely anticipated—with one user predicting a "Golden Era of Work Theater" driven by AI's tendency to overengineer—several commenters reject the idea that flattening the org chart is the solution. Instead, they argue that stripping out management often leaves individual contributors drifting without direction, forcing them to generate performative work just to survive. Rather than layers being the problem, the thread suggests that good management is exactly what is needed to defend focus in an era of cheap execution.

fx :Tiny, open, native coding agent.

Submission URL | 107 points | by handfuloflight | 57 comments

A 6.39 MiB Zig-built coding agent CLI that cold-starts in 10µs runs natively or as WebAssembly with a shell-like UX, aiming for embeddability over a terminal IDE.

• Tiny binary and minimal I/O for instant time-to-prompt; suitable for agent sandboxes and constrained environments.
• Minimal memory baseline (single-digit MB), so you can pack many instances per machine.
• Wasm builds via the Zig toolchain; network stack is pluggable. The browser demo delegates networking to fetch and uses a just-bash workspace.
• Model/provider agnostic: works with local models, gateways, or direct provider APIs/subscriptions.
• Context-efficient design (small system prompt and tools) to reduce token spend and improve TTFT.
• Extensible via skills, plugins, and MCPs; small core with a Unix-like philosophy.
• Shell-like ergonomics: preserved scroll history, minimal output, sparse TUI/paint.
• Open source (Apache-2.0). v0.0.3 is marked experimental; expect frequent changes and “use at your own risk.”
• Web demo requires WebAssembly JSPI (Safari 27+ or Chrome). For local install: curl -fsSL https://fx.sh/setup.sh | bash

The discussion splits between dismissing the project as undifferentiated trend-chasing and praising its specific architectural constraints—namely its embeddability and "small core" design.

• The "Agent" vs. "Harness" taxonomy: A semantic debate highlights the industry's messy terminology. Commenters attempt to separate the "harness" (the trusted host software or environment) from the "agent" (the untrusted, instantiated LLM process running within it), though analogies quickly unravel into arguments over whether the LLM is the game engine, the software disc, or the player.
• The architectural shift: Defenders link fx to a broader trend seen in OpenCode v2 and DeepSeek's new harness: moving away from monolithic terminal IDEs toward minimal, malleable cores extended entirely by plugins and event sourcing.
• Binary size: A developer questions the efficiency claim, noting that 6.39 MiB is surprisingly large for a Zig-compiled CLI that essentially runs a basic I/O loop and API calls, suggesting a strictly minimal implementation should sit closer to 300 KB.
• Agent fatigue: A prominent meta-thread asks why HN is flooded with a new coding agent every other day. Explanations range from extreme ease of development and providers (like Vercel) pushing their own ecosystem harnesses, to the reality that the optimal UX for LLM-assisted programming remains fundamentally unsolved.

Show HN: Shoehorn – Quantize any model down to run on your machine

Submission URL | 44 points | by rhgraysonii | 9 comments

Auto-fits Hugging Face models to your RAM/VRAM budget, does the quantization and setup for you, and spins up a local chat in one click. Uses llama.cpp as the inference backend.

Before installing, a browser tool lets you pick your hardware and desired context length (4k/8k/16k/32k), then scans popular Hugging Face models for ones that will fit — ranked by the quality your memory affords. It effectively replaces guesswork with a capacity-aware shortlist.

• Setup: brew install notactuallytreyanastasio/shoehorn/shoehorn (macOS); downloadable binaries for macOS (Apple Silicon), Linux (x86-64; NVIDIA or AMD), and Windows (x86-64; NVIDIA); or build from source with cargo. llama.cpp must be on your PATH (Homebrew install pulls it in).
• App flow: the local web UI measures your machine, streams the “fit” process, visualizes the memory budget as a tape measure, reports the perplexity cost of the quantization, and ends at a Chat button.

Cross-platform (Mac, Linux, Windows) with a simple GUI to find models and get everything built. The author reports it’s working well across several models already.

Repo: https://github.com/notactuallytreyanastasio/shoehorn

Commenters quickly mapped the tool against existing capacity-planning and inference projects like LLMFit, airllm, and colibri. The author confirmed the underlying logic is similar to airllm's budget-constrained quantization, while incorporating a search function comparable to LLMFit. Beyond these comparisons, users probed the extreme edges of the app's sizing logic, questioning what actually happens when attempting to cram a 2.4-trillion-parameter model into 24GB or 48GB of Mac memory. This curiosity about the tool's real-world overhead was underlined by one early tester, who reported hitting an out-of-memory error upon starting the server despite passing the app's initial sizing check.

200B Tokens Later: A Month of Letting AI Agents Decompile MW2

Submission URL | 17 points | by Philpax | 3 comments

Four Claude Sonnet 5 agents burned through 199.8B tokens in four weeks, pushed ~7,000 commits, and got MW2 (2009) to boot while mechanically decompiling 5,588 of 16,324 functions (~34%). The repo is private; launching a map still fails despite many subsystems being in place, suggesting integration bottlenecks until most code paths are wired.

• Setup: 3 worker agents commit to a single branch; an overseer agent auto-reviews commits triggered by GitHub webhooks. Coordination runs through Discord (shared channel for agents; extra channel for overseer commit notifications); CI failures post back to chat. Tasks are managed in GitHub issues. Agents use leaked Xbox alpha builds with symbols, macOS ports with debug info, and access Ghidra/IDA via MCP servers. Running on Claude Code CLI with a Max (20x) sub; models switched from Opus 5 to Sonnet 5 mid-run.
• What worked: GitHub issues replaced a 10MB STATUS.md that blew context and now enable autonomous issue creation/closure. Discord coordination is largely clean and lets humans interact without shell access.
• Friction: Agents relapse into verbose walls of text after brief concision; they insist on local full test runs on small changes (about 4 minutes each) despite CI, wasting cycles; they avoid large subsystems in favor of quick wins, leading to idle time as easy tasks dry up; occasional “running out of context” refusals despite automatic compaction; recurring GitHub outages degrade issue tracking and CI signals.
• Lessons: Don’t multiplex goals—pure mechanical decomp first, then modernization/portability later. Sonnet 5 performs similarly to Opus 5 for this mechanical workflow. PostCompact hooks that re-inject rules help agents remember process constraints over long runs.

The experiment shows agents can grind through large, repetitive reverse-engineering work with minimal oversight, but throughput hinges on orchestration guardrails and external CI/hosting stability as much as raw model capability.

The brief discussion centers entirely on alternative model choices. Commenters speculated that upgrading to Opus or Fable might help the agents navigate the larger system-level bottlenecks, while others proposed benchmarking the workload against Qwen3.8 27B or Codex 5.6 Sol, with one user arguing that Codex's recent improvements give it a significant edge over Claude for this type of harness.