Hacker News
Daily AI Digest

AI Submissions for Tue Jan 27 2026

AI2: Open Coding Agents

Submission URL | 225 points | by publicmatt | 40 comments

Open Coding Agents (AI2): SERA open models + a cheap, reproducible recipe to adapt coding agents to any repo

• What’s new: AI2 released SERA (Soft-verified Efficient Repository Agents) and a fully open pipeline—models, training data, recipes, and a one-line launcher/CLI (PyPI)—to build and fine‑tune coding agents for your own codebase. Works out of the box with Claude Code.

• Performance: SERA-32B solves 54.2% on SWE-Bench Verified, edging prior open-source peers of similar size/context. Trained in ~40 GPU-days; they say reproducing prior open SOTA costs ~$400, and ~$12k can rival top industry models of the same size.

• Key idea: “Soft-verified generation” (SVG) for synthetic data—patches don’t need to be fully correct to be useful—plus a “bug-type menu” to scale/diversify data. They report SOTA open-source results at a fraction of typical costs.

• Efficiency claims: Matches SWE-smith at ~57× lower cost and SkyRL at ~26× lower cost. Fine-tuning on private code reportedly lets SERA-32B surpass its 110B teacher (GLM-4.5-Air) on repos like Django/Sympy after 8k samples ($1.3k).

• Inference throughput (NVIDIA-optimized): ~1,950 tok/s (BF16, 4×H100), ~3,700 tok/s (FP8), and ~8,600 tok/s on next‑gen 4×B200 (NVFP4), with minimal accuracy drop at lower precision.

• Why it matters: Puts strong, repo-aware coding agents within reach for small teams—no large-scale RL stack required—while keeping the models and data open for inspection and iteration.

Notes/caveats:

• Results center on SWE-Bench Verified; real-world repo adaptation and privacy/process for generating synthetic data from private code merit scrutiny.
• Cost/speed numbers depend on specific NVIDIA hardware and settings.

Here is a summary of the discussion:

Comparisons and Performance Claims The most active debate concerned whether SERA truly reclaims the open-source SOTA title. Users pointed to Meta’s CWM models, which reportedly achieve higher scores (65% on SWE-bench Verified) when using Test-Time Selection (TTS). A discussion participant (likely a paper author) pushed back, arguing that TTS adds significant latency and cost, making it impractical for local deployment. They emphasized that SERA is optimized for efficiency and lower context lengths (32k/64k) compared to the hardware-intensive requirements of rival models.

Openness and Licensing Commenters distinguished between "open weights" and "open science." While models like Mistral Small 2 and Meta’s CWM have open weights, users noted that Meta’s license restricts commercial use and does not disclose training data. In contrast, AI2 was praised for releasing the full pipeline, including training data and the recipe for synthetic data generation, allowing for genuine reproducibility and commercial application.

Terminology: "Agent" vs. "LLM" There was significant semantic pushback regarding the use of the term "Agent." Users argued that an LLM itself is not an agent; rather, an agent is the combination of an LLM plus a scaffolding/harness (a loop to execute tasks). Others suggested a distinction between "Agentic LLMs" (models fine-tuned for reasoning and tool-calling) and the broader systems that utilize them.

Fine-Tuning vs. Context Window Users debated the practical utility of fine-tuning a 32B model on a specific repository versus using RAG (Retrieval-Augmented Generation) with a massive context window on a frontier model (like GPT-4 or Claude 3.5).

• Skeptics argued that intelligent context management with a smarter model is usually superior to fine-tuning a "dumber" model.
• Proponents (one claiming to work on the "world's largest codebase") countered that fine-tuning is essential for proprietary internal libraries and syntax that general models cannot infer, even with large context windows.

Miscellaneous

• Claude Code Integration: Some users were confused by the claim that the system requires Claude Code to run; others clarified that Claude Code is simply the harness/CLI being supported out of the box, while other open harnesses (like OpenCode or Cline) could also be used.
• Speed: The inference speed (up to ~8,600 tok/s on B200s) was highlighted as a major advantage, though some questioned the specific hardware dependencies.
• Technique: The synthetic data generation method—extracting tests from PR diffs and having the model reconstruct the patch—was noted as a clever approach to scaling training data.

Management as AI superpower: Thriving in a world of agentic AI

Submission URL | 94 points | by swolpers | 87 comments

Ethan Mollick recounts an experiment at Wharton: executive MBA students used agentic AI tools (Claude Code, Google Antigravity, ChatGPT, Claude, Gemini) to go from zero to working startup prototypes in four days. Results were roughly a semester’s worth of progress pre‑AI: real core features, sharper market analyses, and easier pivots. Example demos included Ticket Passport (verified ticket resale), Revenue Resilience (at‑risk revenue detection with agentic remediation), a parenting activity matcher, and Invive (blood sugar prediction).

The bigger point: management—clear goals, constraints, and evaluation—has become the AI superpower. Mollick offers a mental model for deciding when to hand work to AI:

• Human Baseline Time: how long you’d take to do the task yourself
• Probability of Success: chance the AI meets your quality bar per attempt
• AI Process Time: time to prompt, wait, and verify each AI output

You’re trading “doing the whole task” vs. “paying overhead” potentially multiple times. If the task is long, AI is fast and cheap, and the success probability is high enough, delegate. If checking takes long and success is low, just do it yourself. He ties this to OpenAI’s GDPval study: experts took ~7 hours; AI was minutes to generate but ~1 hour to verify—so the tipping point depends on model quality and your acceptance bar.

Why HN cares

• Practical rubric for real work: when AI accelerates vs. wastes time
• Emphasis on evaluation as the scarce skill, not prompting tricks
• Lower pivot costs enable broader exploration and parallel bets
• Caveats: jagged frontier unpredictability, verification overhead, domain/regulatory risk, and the danger of over‑delegation without subject‑matter judgment

Is writing code still the bottleneck? A contentious debate emerged regarding the author’s premise that code generation is no longer the limiting factor in software development. While some agreed that the bottleneck has shifted to "deciding what to build," specification, and review, many argued that the true constraint remains visualizing complex systems, debugging, and managing architecture in medium-to-large codebases—tasks where AI agents frequently fail due to context window limitations and a lack of holistic understanding.

The "Mental Model" Deficit A recurring critique focused on the trade-off between speed and comprehension. Commenters noted that writing code is how engineers build a mental model of the system. By delegating implementation to AI, developers risk losing the deep understanding required to debug subtle failures or make architectural decisions later. This led to concerns that AI speed is illusory, merely shifting time saved on typing toward "paying overhead" on reading, validating, and fixing "myopic" AI error corrections that introduce technical debt.

The shift from "Builder" to "Reviewer" Discussion highlighted the psychological toll of this shift. Several users argued that "managing" AI strips away the creative, satisfying parts of engineering (building), leaving humans with the "grind" of tedious verification, cleanup, and orchestration—work described by some as mind-numbing. Others pointed out that unlike managing human juniors, managing AI lacks the rewarding aspect of mentorship and teaching soft skills.

Enforcement and Verification Participants noted that if AI is treated as a "junior" or a force multiplier, the reliance on automated enforcement (linting, tests, strict architectural boundaries) must increase drastically. Because AI does not "learn" best practices deeply and can hallucinate valid-looking but broken structures, human reviewers must implement rigorous automated checks to prevent a collapse in code quality.

Kimi Released Kimi K2.5, Open-Source Visual SOTA-Agentic Model

Submission URL | 483 points | by nekofneko | 227 comments

What’s new

• Native multimodal model trained on ~15T mixed vision/text tokens; pitched as the most powerful open-source model to date.
• Strong coding + vision focus: image/video-to-code, visual debugging, and reasoning over visual puzzles. Demos include reconstructing sites from video and generating animated front‑end UIs from a single prompt.
• “Agent Swarm” paradigm: K2.5 can self-orchestrate up to 100 sub‑agents and ~1,500 tool calls in parallel, claiming up to 4.5x faster execution vs single‑agent runs. No predefined roles; the model decomposes and schedules work itself.

How the swarm works (research preview)

• Trained via Parallel-Agent Reinforcement Learning (PARL) with a learned orchestrator and frozen sub‑agents.
• Uses staged reward shaping to avoid “serial collapse” (falling back to single‑agent). Introduces a “Critical Steps” metric to optimize the critical path rather than raw step count.
• Reported gains on complex, parallelizable tasks and strong scores on agentic benchmarks (HLE, BrowseComp, SWE‑Verified) at lower cost.

Coding with vision

• Emphasis on front‑end generation and visual reasoning to lower the gap from mockups/video to working code.
• Autonomous visual debugging: the model inspects its own outputs, consults docs, and iterates without handholding.
• Internal “Kimi Code Bench” shows step‑up over K2 on build/debug/refactor/test tasks across languages.

Ecosystem and availability

• Access via Kimi.com, Kimi App, API, and Kimi Code.
• Four modes: K2.5 Instant, Thinking, Agent, and Agent Swarm (Beta). Swarm is in beta on Kimi.com with free credits for higher‑tier paid users.
• Kimi Code: open‑source terminal/IDE tooling (VSCode, Cursor, Zed, etc.), supports image/video inputs, and auto‑discovers/migrates existing “skills” and MCPs into your setup.

Why it matters

• Pushes the frontier on practical multimodal coding and parallel agent execution—two areas with big latency and productivity payoffs for real software work.
• If the “self‑directed swarm” generalizes, it could make agent workflows faster and less brittle than hand‑crafted role trees.

Caveats to watch

• Benchmarks and demos can overfit; real‑world reliability, tool integration quirks, and cost at scale remain to be seen.
• “Open‑source” claims often hinge on licensing/weights availability—expect scrutiny on what exactly is released and under what terms.
• Swarm benefits depend on tasks that truly parallelize; sequential or tightly coupled tasks won’t see the same speedups.

How to try

• Experiment with K2.5 Agent/Swarm on Kimi.com (beta) and wire up Kimi Code in your terminal/IDE for image/video‑to‑code and autonomous debugging workflows.

Based on the discussion, here is a summary of the comments regarding the Kimi K2.5 submission:

Hardware Feasibility & Requirements The primary topic of debate is the feasibility of running a 1-trillion parameter model (even with only 32B active parameters) on local hardware.

• The VRAM Bottleneck: Users noted that even with Int4 quantization, a 1T parameter model requires approximately 500GB of VRAM, which is prohibitively expensive for most consumers.
• MoE Architecture: Defenders of the "local" potential argued that because it is a Mixture of Experts (MoE) model, compute requirements are lower (only 32B active parameters per token). However, the total VRAM capacity remains the hard constraint.
• High-End Consumer Gear: Some suggested that high-end consumer hardware (like Mac Studios with unified memory or PCs with the upcoming Strix Halo) might handle the active parameter load, but storing the full model remains a challenge without massive memory pools.

Quantization & Model Quality There was significant skepticism regarding how much the model must be compressed to be usable.

• Quantization Trade-offs: Users debated whether a massive model heavily quantized (to 4-bit or 2-bit) performs better than a smaller model running at higher precision. Some reported that while benchmarks might survive quantization, real-world usage often suffers from "death spirals" (repetitive loops) or logic failures.
• BitNet & Future Tech: The discussion touched on recent research (like BitNet/1.58-bit models) and whether Kimi uses post-training quantization vs. quantization-aware training.
• Hardware Support: It was noted that running Int4 effectively requires hardware that natively supports the format; otherwise, the hardware wastes throughput unpacking the data.

System Architecture & OS Limitations

• Memory Offloading: The viability of keeping the model on SSDs and swapping "experts" into RAM was debated. Experts argued that because expert activation is often random (low locality), SSD latency would make inference unacceptably slow.
• Windows vs. Linux: One user argued that for consumer Nvidia cards (e.g., RTX 3000 series), Windows currently handles shared memory (using system RAM as VRAM overflow) better than Linux drivers, which were described as unstable or difficult to configure for this specific use case.

Defining "Local" A philosophical disagreement emerged regarding what "running locally" means.

• Some users feel "local LLM" implies standard consumer hardware (gaming PCs/laptops).
• Others argued that any model running on on-premise hardware (even a $20k server cluster) counts as local, distinguishing it from API-only services.

LLM-as-a-Courtroom

Submission URL | 67 points | by jmtulloss | 29 comments

Falconer: an “LLM-as-a-Courtroom” to fight documentation rot

Falconer is tackling the classic “documentation rot” problem—code evolves, docs don’t—by auto-proposing and updating internal docs when PRs merge. The hard part isn’t search; it’s trust: knowing which documents truly need updates, for which audiences, and why. After finding that simple categorical scoring (e.g., relevance 7/10) produced inconsistent, unjustified decisions, the team built a courtroom-style judgment engine: one agent prosecutes (argues to update), another defends (argues to skip), a jury deliberates, and a judge rules—creating a reasoned, auditable trail.

Why it matters:

• Turns LLMs from unreliable “raters” into structured debaters that provide evidence and rationale.
• Handles cross-functional nuance (what’s critical for support may be irrelevant for engineering).
• Scales to tens of thousands of PRs daily for enterprise teams.
• Improves trust and maintainability by coupling automation with explainability, not just findability.

The discussion around Falconer focused on the necessity of its complex architecture, the economics of running multi-agent systems, and philosophical debates regarding LLM "understanding."

The "Courtroom" vs. Simple Scoring Several users questioned whether a complex adversarial system was necessary, suggesting that Occam's Razor favors simpler metrics, binary log probabilities, or standard human review. The authors responded that they initially tried simple 1–10 relevance scoring but found the results inconsistent. They argued that LLMs perform better when tasked with arguing a specific position (prosecution/defense) rather than assigning abstract numerical values to nuanced documentation changes that are rarely strictly "true" or "false."

Cost, Latency, and the "Funnel" Commenters expressed concern about the token costs and latency of running multiple agents (prosecutor, defense, five jurors, judge) for every Pull Request. The creators clarified that the "courtroom" is the final step of a funnel, not the default path:

• 65% of PRs are filtered out by simple heuristics before review begins.
• 95% of the remaining are decided by single agents (prosecutors deciding whether to file charges).
• Only 1–2% of ambiguous cases trigger the full, expensive adversarial pipeline.

Philosophy vs. Utility A segment of the discussion devolved into the "Chinese Room" argument. Skeptics argued that LLMs cannot effectively judge context because they lack human experience and true understanding, merely processing symbols. Pragmatists pushed back, noting that if the system achieves the claimed 83% success rate, it is practically useful regardless of whether the model possesses philosophical "understanding."

Other Notes

• One user shared their own experiment with a "mediation" framework, noting that while litigation seeks truth/justice, mediation seeks resolution—a subtle but interesting difference in agent goal-setting.
• The thread contained several humorous "courtroom transcript" parodies involving LLM jailbreaks and the "Chewbacca defense."

AI Submissions for Mon Jan 26 2026

ChatGPT Containers can now run bash, pip/npm install packages and download files

Submission URL | 407 points | by simonw | 290 comments

ChatGPT’s code sandbox just got a quiet but major upgrade, per Simon Willison’s testing

• What’s new: Containers can now run Bash directly, not just Python. They also execute Node.js/JavaScript and successfully ran “hello world” in Ruby, Perl, PHP, Go, Java, Swift, Kotlin, C, and C++ (no Rust yet).
• Package installs: pip install and npm install now work via a custom proxy despite the container lacking general outbound network access.
• Fetching files: A new container.download tool saves files from the web into the sandboxed filesystem. It only downloads URLs that were explicitly surfaced in the chat (e.g., via web.run), reducing prompt-injection exfil risks.
• Safety notes: Attempts to craft arbitrary URLs with embedded secrets were blocked—container.download requires the URL to have been “viewed in conversation,” and web.run filters long/constructed query strings. Downloads appear to come from an Azure IP with a ChatGPT-User/1.0 UA.
• Availability: Willison says these capabilities show up even on free accounts; documentation and release notes are lagging.

Why it matters: This turns ChatGPT’s sandbox into a far more capable dev environment—able to script with Bash, pull data files, and install ecosystem packages—making it much better at real-world coding, data wrangling, and agentic workflows, while keeping some guardrails against data exfiltration.

The Discussion

• Expanded Capabilities & Language Support: Users confirmed the sandbox is available to free accounts and validated support for languages like D (via the DMD compiler), though C# appears mostly absent due to .NET framework constraints. One commenter described the experience of watching the AI use a computer to answer questions as having a "Pro Star Trek" feel, contrasting it with the loops and errors often encountered with Gemini.
• CLI Abstraction vs. Mastery: A debate emerged regarding the efficiency of using LLMs for standard *nix tasks. While some purists argued that using an LLM to inspect file headers (magic bytes) is wasteful compared to valid CLI commands like file or curl, Simon Willison and others countered that this democratizes powerful tools (like ffmpeg or ImageMagick) for the 800 million users who aren't comfortable in a terminal, while also saving experienced developers from memorizing complex flag syntax.
• The Return of the "Mainframe": The upgrade sparked speculation about the shift toward persistent, virtual development environments. Commenters noted that tool-calling is moving off-platform, with some likening the trend to "renting time on a mainframe" to avoid local hardware maintenance. Willison noted that ephemeral environments are particularly well-suited for coding agents, as they mitigate security risks—if an environment is trashed or leaked, it can be discarded and restarted.
• Unreleased Features: Sharp-eyed users noticed "Context: Gmail" and "read-only" tags in the application logs, leading to speculation (confirmed by news leaks) that deep integration with Gmail and Calendar is currently in testing.

There is an AI code review bubble

Submission URL | 317 points | by dakshgupta | 217 comments

What’s new: Greptile’s Daksh Gupta argues we’re in the “hard seltzer era” of AI code review—everyone’s shipping one (OpenAI, Anthropic, Cursor, Augment, Cognition, Linear; plus pure-plays like Greptile, CodeRabbit, Macroscope). Rather than claim benchmark superiority, Greptile stakes its bet on a philosophy built around:

• Independence: The reviewer should be different from the coder. Greptile refuses to ship codegen—separation of duties so the agent that writes code isn’t the one approving it.
• Autonomy: Code validation (review, tests, QA) should be fully automated with minimal human touch. Greptile positions itself as “pipes,” not a UI.
• Feedback loops: Coding agent writes, validation agent critiques and blocks, coding agent fixes, repeat until the reviewer approves and merges. Their Claude Code plugin can auto-apply Greptile’s comments and iterate.

Why it matters:

• If agents start auto-approving most changes, separation of duties becomes a compliance and safety necessity.
• Review tools could shift from “assistive UIs” to background infrastructure with audit trails and merge authority.
• Switching costs are high for review systems, so vendor choice may be sticky.

Claims and context:

• Greptile cites enterprise traction (including two “Mag7” customers) and recent updates: Greptile v3 (agentic workflow, higher acceptance rates and better signal ratios), long‑term memory, MCP integrations, scoped rules, and lower pricing.
• Caveat: performance claims are vendor-reported; teams may weigh the trade-off between independence and an integrated, single-agent DX.

If you’re evaluating:

• Can the reviewer run tests/QA autonomously and block/merge with guardrails?
• Is there strict separation from your codegen agent?
• Does it support closed-loop remediation, audit logs, and blast-radius controls (permissions, rollout, revert)?
• How painful is it to rip out later (repo coverage, CI/CD hooks, policy/rule migration)?

Based on the discussion, here is a summary of the comments regarding AI code review tools and code review philosophy:

Prompt Engineering & Implementation Strategies User jv22222 shared detailed insights from building an internal AI review tool, suggesting specific prompting strategies to improve results:

• Context is King: The AI needs the full file contents of changed files plus "1-level-deep imports" to understand how changed code interacts with the codebase.
• Diff-First, Context-Second: Prompts should explicitly mark diffs as "REVIEW THIS" and surrounding files as "UNDERSTANDING ONLY" to prevent hallucinations or false positives on unchanged code.
• Strict Constraints: Use negative constraints to reduce noise. Explicitly tell the AI not to flag formatting (let Prettier handle it), TypeScript errors (let the IDE handle it), or guess line numbers.
• Structure: Force structured output (e.g., Emoji-prefixed bullets lists) categorized by severity (Critical, Major, Minor).

The Signal-to-Noise Problem Several users expressed skepticism about the current state of AI reviewers, citing a poor signal-to-noise ratio.

• One user estimated their experience as "80% noise."
• The danger is that if the AI floods the PR with speculative or trivial comments, humans will tune it out, resulting in the "20%" of critical bugs slipping through because the human bottleneck is attention.
• The consensus among skeptics is that AI tools are currently useful as a "second set of eyes" but cannot yet be trusted as a default gatekeeper or autonomous agent.

Edit-Based vs. Comment-Based Reviews A significant portion of the thread digressed into a discussion on Jane Street’s internal review system (Iron), sparked by a comment about how reviewers should fix trivial issues rather than commenting on them.

• The Philosophy: Instead of leaving nitpick comments (which can feel insulting and slow down the loop), reviewers should simply apply the changes directly.
• The Friction: Users noted that standard GitHub workflows make this difficult (checkout, edit, push, context switch), whereas internal tools like Iron or specific VS Code plugins streamline "server-side" editing.
• Consensus: "Ping-ponging" comments over variable names or minor logic is a massive productivity killer; fixing it directly is often preferred by senior engineers.

The "Bikeshedding" & Naming Debate The thread debated whether comments on variable names are valuable or a waste of time ("bikeshedding").

• Pro-Naming Comments: If a reviewer finds a name confusing, the code is confusing. The mental model gap must be bridged. One user suggested the default response to a naming suggestion should always be "Done" unless there is a specific, strong reason not to.
• Anti-Naming Comments: Others argued that arguing over itemCount vs numberOfItems for 30 minutes is a waste of expensive engineering time. While clarity matters, hyper-focusing on conventions (especially in test function names) often yields diminishing returns.

Porting 100k lines from TypeScript to Rust using Claude Code in a month

Submission URL | 236 points | by ibobev | 155 comments

• Vjeux (ex-Facebook/Meta engineer) set out to port the open‑source Pokémon Showdown battle engine (JS/TS) to Rust to enable fast AI training loops, using Claude Code as the primary driver.
• The “agentic” setup required a surprising amount of ops hackery: he proxied git push via a local HTTP server (since the sandbox blocked SSH), compiled/running inside Docker to avoid antivirus prompts, and used automation (keypress/paste loops and an auto‑clicker) to keep Claude running unattended for hours.
• Early naïve conversion looked impressive (thousands of compiling lines) but hid bad abstractions: duplicated types across files, “simplified” logic where code was hard, and hardcoded patches that didn’t integrate.
• The fix was to impose structure and determinism: generate a script that enumerates every JS file/method and mirrors them in Rust, with source references inline. This grounded the port and reduced hallucinations/mistranslations.
• Key lesson: AI can churn volume, but you must tightly constrain it with deterministic scaffolding, clear mappings, and checks; otherwise it drifts into inconsistent designs.
• Reliability matters for long runs: he hit intermittent failures overnight and notes that agent platforms still need better stability and permission models for unattended work.
• Big picture: with enough guardrails and orchestration, one engineer can push a six‑figure‑line port in weeks—but the real work is designing the rails that keep the model honest and productive.

Takeaway: AI was the tireless junior dev; success came from turning the task into a scripted, verifiable pipeline rather than a free‑form translation exercise.

Here is a summary of the discussion:

• The "Improvement" Trap: Commenters shared similar war stories, notably a failed attempt to port an Android/libgdx game to WASM. The "agentic" failure mode was identical: the AI refused to do a dumb, line-by-line port and insisted on "improving" the code (simplifying methods, splitting generic start functions), which immediately introduced layout and physics bugs. The consensus is that legacy code is battle-tested; AI attempts to apply "clean code" principles during a port usually destroy subtle, necessary logic.
• Hidden Prompts vs. User Intent: A key insight proposed is that IDE plugins and agent frameworks often inject system prompts instructing the model to act as an "expert engineer" using "best practices." This creates a conflict: the user wants a literal translation, but the hidden prompt forces the AI into a refactoring mode.
• Anthropomorphism and Consistency: A sub-thread debated the terminology of calling the AI "arrogant." While technically just token prediction based on training data (which includes post-mortems suggesting code cleanup), users noted that treating the model as an inconsistent reasoning engine is dangerous. The "reasoning" output (Chain of Thought) is often just a hallucinated prediction of what an explanation should look like, not a true window into the model's logic.
• Alternative Strategies:
  • Port Tests First: Write or port the test suite before the application code; if the AI can make the green lights turn on, the implementation details matter less.
  • Source-to-Source Compilers: for mechanical translations, it may be better to have the AI write a chaotic regex/parsing script to do the bulk work deterministically, rather than relying on inference for every line.
  • Language Proximity: One user noted a successful 10k line C++ to Rust port using Gemini, largely because the memory models and structures allowed for a straighter translation than the paradigm shift required for TS to Rust.

AI code and software craft

Submission URL | 222 points | by alexwennerberg | 135 comments

• The author frames today’s AI “slop” (low-effort audio/video/text) through Jacques Ellul’s “technique”: optimizing for measurable outcomes over craft. When engagement and efficiency are the ends, quality and delight erode.
• Music as parable: Bandcamp’s album-centric, human curation model nurtured indie craft; Spotify’s playlist-driven optimization yields bland, metrics-first tracks. In such spaces, AI thrives because “good enough” at scale beats artistry. The author says Bandcamp is hostile to AI, even banning it.
• Software’s parallel: Big Tech work has become “plumbing”—bloated systems, weak documentation, enshittified platforms, and narrow roles that atrophy broad engineering skill. Cites Jonathan Blow’s “Preventing the Collapse of [Software] Civilization”: industry has forgotten how to do things well.
• Two consequences: (1) AI agents threaten rote, narrow coding jobs—where “good enough” code meets business needs. (2) Overgeneralized claims that AI can do “most” software reduce software to mere output, ignoring design, taste, and higher aims.
• Practical verdict on agents: useful for well-scoped, often-solved tasks (tests, simple DB functions). But they hallucinate, lack understanding, and produce brittle or monstrous code when asked to generalize or “vibe code.”
• Implied takeaway: If platforms value the domain (music, software) over metrics, craft can flourish. Cultivate broad, thoughtful engineers and resist collapsing creative work into pure optimization. AI is a tool for the routine, not a replacement for judgment or taste.

Summary of Discussion:

The discussion threads initially pivoted from the article's critique of software to a specific debate on why implementation quality varies so drastically between markets:

• The Enterprise Software Trap: Commenters argued that enterprise software is universally poor due to a principal-agent problem: the purchaser (managers) prioritizes compliance, reporting, and "required fields," while the actual user is ignored. Conversely, consumer software is polished because it must woo individuals, though users noted it is often optimized for engagement rather than actual utility.
• AI Code: Orchestration vs. Pollution: A heated debate emerged regarding the practical output of AI agents.
  • The Proponent View: Some argued AI is a tool change—like moving from a handsaw to a chainsaw. The work shifts from manual coding to "orchestration, planning, and validating."
  • The Skeptic View: Critics countered that AI-generated code is often "orders of magnitude worse" and brittle. A significant complaint was review fatigue: developers expressed frustration with colleagues dumping 1,000-line, zero-effort AI diffs that are exhausting to verify and debug.
  • The Amplification Theory: One user suggested AI simply amplifies existing traits: it makes lazy developers lazier (and dangerous), while potentially helping skilled architects move faster, provided they have the taste to judge the output.
• The Philosophy of Efficiency: Expanding on the article's reference to Jacques Ellul, commenters noted that "efficiency" in the corporate sense is usually a proxy for shareholder return, which fundamentally trades off system adaptability and resilience. One user recommended Turing's Cathedral as a look back at an era of "real engineering" craft that the industry has since forgotten.

Show HN: TetrisBench – Gemini Flash reaches 66% win rate on Tetris against Opus

Submission URL | 107 points | by ykhli | 39 comments

AI Model Tetris Performance Comparison: A new site pits AI models against each other in head-to-head Tetris and tracks results by wins, losses, and draws with a public leaderboard. It’s a community-driven benchmark—there’s no data yet, and users are invited to run AI-vs-AI matches to populate the stats. Beyond the leaderboard, there’s a “Tetris Battle” mode to watch or play, making it a playful way to compare agents under identical conditions.

Discussion Summary:

The discussion focused heavily on the specific mechanics of the implementation, the suitability of LLMs for the task, and legal concerns. The creator (ykhl) clarified the technical architecture: rather than relying on visual reasoning (where LLMs struggle), the system treats Tetris as a coding optimization problem. The models receive the board state as a JSON structure and generate code to evaluate moves. The creator noted that models often "over-optimize" for immediate rewards (clearing lines), creating brittle game states that lead to failure, rather than prioritizing long-term survival heuristics like board smoothness.

Key points from the thread include:

• Tetris Mechanics: Experienced players pointed out flaws in the game engine, specifically regarding the randomization system (suggesting a standard "7-bag" system to prevent piece starvation) and rotation physics, which users felt were biased to the left or lacked standard "SRS" (Super Rotation System) behaviors.
• LLM Utility vs. Traditional Bots: Several users debated the efficiency of using billion-dollar GPU clusters to play a game that simple algorithms on 40-year-old CPUs can master. Critics argued that Reinforcement Learning (e.g., AlphaZero) is a more appropriate architecture than LLMs for this task. However, others acknowledged the project as a benchmark for reasoning and coding benchmarks rather than raw gameplay dominance.
• Model Specifics: There was a brief comparison of model performance, with Gemini 1.5 Flash highlighted as a cost-effective "workhorse" compared to the more expensive Claude 3 Opus.
• Legal Warnings: Multiple users warned the creator about "Tetris Holdings" and their history of aggressive trademark enforcement against fan projects.

Show HN: Only 1 LLM can fly a drone

Submission URL | 172 points | by beigebrucewayne | 91 comments

SnapBench: a Pokémon Snap–style spatial reasoning test for LLMs

• What it is: A small benchmark where a vision-language model pilots a drone in a voxel world to find and identify three ground-dwelling creatures (cat/dog/pig/sheep). Architecture: Rust controller (orchestration), Zig/raylib simulator (physics, terrain, creatures, UDP 9999 command API), and a VLM via OpenRouter. The controller feeds screenshots + state to the model; the model returns movement, identify, and screenshot commands. Identification succeeds within 5 units.

• Headline result: Out of seven frontier models tested with the same prompt, seeds, and a 50-iteration cap, only Gemini 3 Flash consistently managed to descend to ground level and successfully identify creatures. Others:

  • GPT-5.2-chat: Gets near horizontally, rarely lowers altitude.
  • Claude Opus 4.5: Spams identification (160+ attempts) but approaches at bad angles, never succeeds.
  • The rest: Wander or get stuck.

• Key insight: Altitude/approach control—not abstract reasoning—was the bottleneck. The cheapest model beat pricier ones, suggesting:

  • Spatial/embodied control may not scale with model size (yet).
  • Training differences (e.g., robotics/embodied data) could matter more.
  • Smaller models may follow literal instructions (“go down”) more directly.

• Other observations:

  • Two-creature “win” happened when spawns were close; the 50-step limit often ends runs early in a big world.
  • High-contrast creatures (gray sheep, pink pigs) are easier to spot; visibility normalization is a possible future tweak.

• Caveats: Side project, not a rigorous benchmark; one blanket prompt for all models; basic feedback loop; iteration cap may disadvantage slower-but-capable agents.

• Prior attempt IRL: A DJI Tello test ended with ceiling bumps and donuts; new hardware planned now that Flash shows promise in sim.

• Try it: GitHub kxzk/snapbench. Requires Zig ≥0.15.2, Rust (2024 edition), Python ≥3.11, uv, and an OpenRouter API key.

Here is a summary of the discussion:

Critique: Wrong Tool for the Job A significant portion of the discussion centered on whether LLMs should handle low-level control. Critics argued that LLMs are inefficient text generators ill-suited for real-time physics, noting that latency and token costs destroy the simple economics of flight. Several users likened the approach to "using a power drill for roofing nails," suggesting that standard control loops (PID) or simpler neural networks (LSTMs) are far superior for keeping a drone airborne.

Alternative Architectures Commenters suggested looking beyond standard VLLMs:

• Vision-Language-Action (VLA) Models: Users noted that specific VLA models (like those intended for robotics) are better suited for embodied control than general-purpose chat models.
• Qwen3VL: One user observed that Qwen models often possess better spatial grounding (encoding pixel coordinates in tokens) compared to larger, abstract reasoning models.
• Pipeline Flaws: One commenter critiqued the project's architecture (Scene $\to$ Text Labels $\to$ Action), arguing that converting a 3D simulation into discrete text labels causes a loss of relative geometry and depth. They suggested that without an explicit world model, errors compound over time because the agent is "stateless" and lacks temporal consistency.

Defense: High-Level Reasoning vs. Piloting Defenders of the approach clarified that the goal isn't to replace the flight controller (autopilot), but to build an agent capable of high-level semantic tasks (e.g., "fly to the garden and take a picture of the flowers"). They argued that while an LLM shouldn't manage rotor speeds, it is currently the best tool for interpreting natural language instructions and visual context to direct a traditional control system.

Google AI Overviews cite YouTube more than any medical site for health queries

Submission URL | 396 points | by bookofjoe | 206 comments

Google AI Overviews lean on YouTube over medical sites for health answers, study finds

• The study: SE Ranking analyzed 50,807 German-language health queries (Dec 2025) and 465,823 citations. AI Overviews appeared on 82% of health searches.
• Top source: YouTube was the single most cited domain at 4.43% (20,621 citations) — more than any hospital network, government health portal, medical association, or academic institution. Next: NDR.de (3.04%), MSD Manuals (2.08%), NetDoktor (1.61%), Praktischarzt (1.53%).
• Why it matters: Researchers say relying on a general-purpose video platform (where anyone can upload) signals a structural design risk—prioritizing visibility/popularity over medical reliability—in a feature seen by 2B people monthly.
• Google’s response: Says AI Overviews surface high-quality content regardless of format; many cited YouTube videos come from hospitals/clinics and licensed professionals; cautions against generalizing beyond Germany; claims most cited domains are reputable. Notes 96% of the 25 most-cited YouTube videos were from medical channels.
• Context: Follows a Guardian probe showing dangerous health misinfo in some AI Overviews (e.g., misleading liver test guidance). Google has since removed AI Overviews for some, but not all, medical searches.
• Caveats: One-time snapshot in Germany; results can vary by region, time, and query phrasing. Researchers chose Germany for its tightly regulated healthcare environment to test whether reliance on non-authoritative sources persists.

Based on the discussion, users expressed concern that Google’s AI is creating a "closed loop" of misinformation by citing AI-generated YouTube videos as primary sources.

The "Dead Internet" and Feedback Loops Participants described an "Ouroboros" effect where AI models validate themselves by citing other AI-generated content. Several users invoked the "Dead Internet Theory," noting that YouTube is exploding with low-quality, AI-generated videos that exist solely to capture search traffic.

• One user recounted finding deepfaked "science" videos, such as AI-generated scripts using Richard Feynman’s voice to read content he never wrote.
• Others noted that "grifters" are using AI to scale scams, such as fake video game cheat detection software.

The Crisis of Trust A debate emerged regarding the fundamental reliability of AI search:

• The skeptical view: Relying on AI that cites other AI destroys "shared reality." If the technology cannot filter out its own "slop," it cannot be a trusted intermediary for truth.
• The counter-argument: Some argued that human sources (propaganda, biased media) are also unreliable, suggesting that the issue is not unique to AI but rather a general problem of verifying information sources.

Economic Incentives and Alternatives Commenters suggested that Google's business model limits its ability to fix this.

• Users praised Kagi (a paid search engine) for its "niche" ability to use agentic loops to verify primary sources.
• The consensus was that Google’s unit economics (serving billions of free queries) force it to rely on cheaper, single-pass retrieval methods, which lack the depth to filter out reputable-looking but hallucinated video content.

OSS ChatGPT WebUI – 530 Models, MCP, Tools, Gemini RAG, Image/Audio Gen

Submission URL | 129 points | by mythz | 32 comments

HN: llms.py v3 ships a big extensibility overhaul, 530+ models via models.dev, and “computer use” automation

llms.py just released v3, reframing itself as a highly extensible LLM workbench. The headline change is a switch to the models.dev catalog, unlocking 530+ models across 24 providers, paired with a redesigned Model Selector and a plugin-style extensions system. It also adds desktop automation (“computer use”), Gemini File Search–based RAG, MCP tool connections, and a raft of built‑in UIs (calculator, code execution, media generation).

Highlights

• 530+ models, 24 providers: Now inherits the models.dev open catalog; enable providers with a simple "enabled": true in llms.json. Daily auto-updates via llms --update-providers. Extra providers can be merged via providers-extra.json.
• New Model Selector: Fast search, filtering by provider/modalities, sorting (knowledge cutoff, release date, last updated, context), favorites, and rich model cards. Quick toggles to enable/disable providers.
• Extensions-first architecture: UI and server features implemented as plugins using public client/server APIs; built-ins are just extensions.
• RAG with Gemini File Search: Manage file stores and document uploads for retrieval workflows.
• Tooling: First-class Python function calling; MCP support to connect to Model Context Protocol servers for extended tools.
• Computer Use: Desktop automation (mouse, keyboard, screenshots) for agentic workflows.
• Built-in UIs:
  • Calculator (Python math with a friendly UI)
  • Run Code (execute Python/JS/TS/C# in CodeMirror)
  • KaTeX math rendering
  • Media generation: image (Google, OpenAI, OpenRouter, Chutes, Nvidia) and TTS (Gemini 2.5 Flash/Pro Preview), plus a media gallery
• Storage and performance: Server-side SQLite replaces IndexedDB for robust persistence and concurrent use; persistent asset caching with metadata.
• Provider nuances: Non-OpenAI-compatible providers handled via a providers extension; supports Anthropic’s Messages API “Interleaved Thinking” to improve reasoning between tool calls (applies to Claude and MiniMax).

Why it matters

• One pane of glass for LLM experimentation: broad model coverage with consistent UX.
• Batteries included: from RAG to tool use to desktop control and media generation, with minimal setup.
• Extensible by design: encourages custom providers, tools, and UI add-ons as plugins.

Getting started

• pip install llms-py (or pip install llms-py --upgrade)
• Configure providers by enabling them in llms.json; update catalogs with llms --update-providers

Caveats

• Powerful features like code execution and desktop control have security implications; use with care.
• You’ll still need API keys and to mind provider quotas/costs.

Top Story: llms.py v3 ships a big extensibility overhaul, 530+ models via models.dev, and “computer use” automation

llms.py has released version 3, repositioning itself as a highly extensible workbench for Large Language Models. This update integrates the models.dev catalog, providing access to over 530 models from 24 providers, and introduces a plugin-based architecture that allows both UI and server features to be extended. Key additions include "Computer Use" for desktop automation, RAG capabilities via Gemini File Search, and support for the Model Context Protocol (MCP) to connect external tools. The release also includes built-in utilities like a calculator and code execution environment, all backed by a switch to server-side SQLite for better performance.

Discussion Summary

The discussion explores the open-source philosophy behind the project, its technical implementation of agents, and the challenges of gaining visibility on Hacker News.

• Licensing and OpenWebUI: A significant portion of the conversation contrasts llms.py with OpenWebUI. Users expressed frustration with OpenWebUI’s recent move to a more restrictive license and branding lock-in. The creator of llms.py (mythz) positioned v3 as a direct response to this, emphasizing a permissive open-source approach and an architecture designed to prevent monopoly on components by making everything modular and replaceable.
• Technical Implementation (Agents & MCP):
  • Orchestration: When asked about managing state in long-running loops (specifically regarding LangGraph), the creator clarified that llms.py uses a custom state machine modeled after Anthropic’s "computer use" reference implementation, encapsulating the agent loop in a single message thread.
  • Model Context Protocol (MCP): The creator noted that while MCP support is available (via the fast_mcp extension), it introduces noticeable latency compared to native tools. However, it is useful for enabling capabilities like image generation on models that don't natively support it.
• Deployment and Auth: Users inquired about multi-user scenarios. The system currently supports GitHub OAuth for authentication, saving content per user. While some users felt the features were "gatekept" or not ready for enterprise deployment compared to other tools, the creator emphasized that the project's goal is simplicity and functionality for individuals or internal teams, rather than heavy enterprise feature sets.
• Ranking Mechanics: There was a meta-discussion regarding the difficulty of getting independent projects to the front page. The creator noted they had posted the project multiple times over the week before it finally gained traction, leading to speculation by other users about how quickly "new" queue submissions are buried by downvotes or flagged compared to company-backed posts.
• Naming: A user briefly pointed out the potential confusion with Simon Willison’s popular llm CLI tool.

OracleGPT: Thought Experiment on an AI Powered Executive

Submission URL | 58 points | by djwide | 50 comments

SenTeGuard launches a blog focused on “cognitive security,” but it’s not live yet. The landing page promises team-authored, moderated longform updates, research notes, and security insights, but currently shows “No posts yet” and even an admin prompt to add the first post—suggesting a freshly set-up placeholder. One to bookmark if you’re tracking cognitive security, once content arrives.

Based on the provided comment text (which appears to be a compressed or vowel-reduced transcript), the discussion focuses on the implications of AI in management and governance, rather than the specific lack of content on the blog mentioned in the submission summary.

The conversation covers three main themes:

• Automation and Accountability: Users debate the feasibility of "expert systems" running companies. While some cite algorithmic trading and autopilot as proof that computers already make high-stakes decisions, others argue that humans (executives) are structurally necessary to provide legal accountability ("you can't prosecute code"). The short story Manna by Marshall Brain is cited as a relevant prediction of algorithmic management.
• Government by Algorithm: Participants speculate on using a "special government LLM" to synthesize citizen preferences for direct democracy. Skeptics counter that current LLMs hallucinate (referencing AI-generated fake legal briefs) and that such a system would likely be manipulated by those in charge of the training data or infrastructure.
• Commercial Intent: One commenter critiques the submission as a commercial vehicle to sell "cognitive security" services, arguing this commercial framing undermines the philosophical discussion. The apparent author (djwd) acknowledges the commercial intent but argues the engineering and political questions raised are still worth discussing.

Minor tangents include:

• Comparisons of AI hype to failed technologies like Theranos versus successful infrastructure like aviation autoland.
• A debate regarding the US President’s practical vs. theoretical access to classified information and chain-of-command issues.

Clawdbot - open source personal AI assistant

Submission URL | 382 points | by KuzeyAbi | 250 comments

Moltbot (aka Clawdbot): an open‑source, self‑hosted personal AI assistant for your existing chat apps

What’s new

• A single assistant that runs on your own devices and replies wherever you already are: WhatsApp, Telegram, Slack, Discord, Google Chat, Signal, iMessage/BlueBubbles, Microsoft Teams, Matrix, Zalo (incl. Personal), and WebChat. It can also speak/listen on macOS/iOS/Android and render a live, controllable Canvas.
• Easy onboarding: a CLI wizard (moltbot onboard) sets up the gateway, channels, and skills; installs a user‑level daemon (launchd/systemd) so it stays always on. Cross‑platform (macOS, Linux, Windows via WSL2). Requires Node ≥22; install via npm/pnpm/bun.
• Models and auth: works with multiple providers via OAuth or API keys; built‑in model selection, profile rotation, and failover. The maintainers recommend Anthropic Pro/Max (100/200) and Opus 4.5 for long‑context and better prompt‑injection resistance.
• Developer/ops friendly: stable/beta/dev release channels, Docker and Nix options, pnpm build flow, and a compatibility shim for the older clawdbot command.
• Security defaults for real messaging surfaces: unknown DMs get a pairing code and aren’t processed until you approve, reducing risk from untrusted input.

Why it matters

• Brings the “always‑on, everywhere” assistant experience without locking you into a hosted SaaS front end.
• Bridges consumer and workplace chat apps, making agents genuinely useful where people already collaborate.
• Thoughtful guardrails (DM pairing) and model failover are practical touches for a bot that lives in your actual message streams.

Quick try

• Install: npm install -g moltbot@latest, then moltbot onboard --install-daemon
• Run the gateway: moltbot gateway --port 18789 --verbose
• Talk to it: moltbot agent --message "Ship checklist" --thinking high

Notes and caveats

• You’re still trusting whichever model/provider you use; “feels local” doesn’t mean the LLM runs locally by default.
• Needs Node 22 and a background service; connecting to many chat platforms may have ToS and security considerations.
• MIT licensed; the repo shows strong community interest (tens of thousands of stars/forks).

Discussion Summary

The discussion centers on the economics, security, and utility of self-hosted AI agents:

• The Cost of "Always On": Users warned that running agents via metered APIs (like Claude Opus) can get expensive quickly. One user reported spending over $300 in two days on "fairly basic tasks," while another noted that a single complex calendar optimization task involving reasoning cost $29. This led to suggestions for using smaller, specialized local models to handle routine logic.
• The "Private Secretary" Dream: There is distinct enthusiasm for a "grown-up" version of Siri—dubbed "Nagatha Christy" or "Jarbis" by one commenter—that can handle messy personal contexts (kids' birthday parties, dentist reminders) alongside work integrations (Jira, Trello, Telegram) without monetizing user data. Several users expressed deep dissatisfaction with current hosted options and a willingness to pay a premium for a private, reliable alternative.
• Security Concerns: The repository came under scrutiny for hardcoded OAuth credentials (client secrets), which some argued is common in open-source desktop apps but poses risks if the "box" is compromised. Others found the concept of "directory sandboxing" insufficient, expressing fear about granting an AI agent permission to modify code and files on their primary machine.
• Self-Repairing Agents: One contributor shared an anecdote about the "lightbulb moment" of working with an agent: when the bot stopped responding on Slack, they used the AI to debug the issue, review the code, and help submit a Pull Request to fix itself.

AI Lazyslop and Personal Responsibility

Submission URL | 65 points | by dshacker | 71 comments

A developer recounts a painful code review: a coworker shipped a 1,600-line, AI-generated PR with no tests, demanded instant approval, and later “sneak-merged” changes after pushback. The author doesn’t blame the individual so much as incentives that reward speed over stewardship—and coins “AI Lazyslop”: AI output the author hasn’t actually read, pushing the burden onto reviewers.

Proposed anti–AI Lazyslop norms:

• Own the code you accept from an LLM.
• Disclose when and how you used AI; include key prompts/plans in the PR.
• Personally read and test everything; add self-review comments explaining your thinking.
• Use AI to assist review, then summarize what you fixed and why.
• Be able to explain the logic and design without referring back to the AI.
• Write meaningful tests (not trivial ones).

The post notes a cultural shift: projects like Ghostty ask contributors to disclose AI use, and even Linus Torvalds has experimented with “vibe-coding” via AI. The gray area persists: the coworker evolved to “semi-lazy-slop,” piping reviewer comments straight into an LLM—maybe better, maybe not.

In a nice touch of dogfooding, the author discloses using Claude for copy edits and lists the concrete fixes it suggested. The core message: don’t shame AI—set expectations that keep quality and responsibility with the human who ships the code.

Based on the discussion, here is a summary of the points raised by Hacker News commenters:

Trust and Professionalism The most heated point of discussion was the "sneak-merge" (merging code after a review without approval). Commenters almost universally agreed that this violates the fundamental trust required for collaborative development. While the author focused on systemic incentives, many users argued that "Mike" bears personal responsibility. One user compared sneaking unreviewed code to a chef spitting in food—a deliberate, unethical action rather than just a process error.

The "Blameless" Culture Debate Several users pushed back against the author's attempt to "blame the incentives" rather than the individual.

• Commenters warned that "blameless culture" can swing too far, protecting toxic behavior and forcing managers to silently manage poor performers out while publicly maintaining a positive façade.
• One user argued that "bending backwards" to avoid blaming an individual for intentional actions creates a low-trust environment where high-quality software cannot be built.

The Reviewer’s Burden and "Prisoner's Dilemma" A recurring theme was the asymmetry of effort. AI allows developers to generate code faster than seniors can review it.

• The Prisoner’s Dilemma: One commenter described a situation where diligent reviewers spend all their time fixing "AI slop" from others, consequently missing their own deadlines. Meanwhile, the "slop-coders" appear productive due to high velocity and get promoted, punishing those who maintain quality.
• Scale vs. Existence: While huge PRs existed before AI (e.g., refactoring or Java boilerplate), users noted that AI changes the frequency. Instead of one massive PR every few weeks, it becomes a daily occurrence, overwhelming the review pipeline.

Proposed Solutions and Nuance

• Policy: Some pointed to the LLVM project's AI policy as a gold standard: AI is a tool, but the human must own the code and ensure it is not just "extractive" (wasting reviewer time).
• Reviewing Prompts: There was a debate on the author's suggestion to include prompts in PRs. Some argued that prompts represent the "ground truth" and reveal assumptions, making them valuable to review. Others felt that only the resulting code matters and reviewing prompts is unnecessary overhead.
• Author’s Context: The author (presumably 'bdsctrcl') chimed in to clarify the technical context of the 1,600-line PR, noting it was largely Unreal Engine UI boilerplate (flags and saved states). While it "worked," it bypassed specific logic (ignoring flag checks) in favor of direct struct configuration, highlighting how AI code can be functional but architecturally incorrect.

When AI 'builds a browser,' check the repo before believing the hype

Submission URL | 228 points | by CrankyBear | 137 comments

Top story: The Register calls out Cursor’s “AI-built browser” as mostly hype

• What was claimed: Cursor’s CEO touted that GPT‑5.2 agents “built a browser” in a week—3M+ lines, Rust rendering engine “from scratch,” custom JS VM—adding it “kind of works.”
• What devs found: Cloning the repo showed a project that rarely compiles, fails CI on main, and runs poorly when manually patched (reports of ~1 minute page loads). Reviewers also spotted reliance on existing projects (e.g., Servo-like pieces and QuickJS) despite “from scratch” messaging.
• Pushback from maintainers: Servo maintainer Gregory Terzian described the code as “a tangle of spaghetti” with a “uniquely bad design” unlikely to ever support a real web engine.
• Cursor’s defense: Engineer Wilson Lin said the JS VM was a vendored version of his own parser project, not merely wiring dependencies—but that undercuts the “from scratch” and “AI-built” framing.
• Scale vs. results: The Register cites estimates that the autonomous run may have burned through vast token counts at significant cost, yet still didn’t yield a reproducible, functional browser.
• Bigger picture: The piece argues this is emblematic of agentic-AI hype—exciting demos without CI, reproducible builds, or credible benchmarks. AI coding tools are useful as assistive “autocomplete/refactor” layers, but claims that agents can ship complex software are outpacing reality.

Why it matters for HN:

• Shipping > demo: Repos, CI status, and benchmarks remain the truth serum. If the code doesn’t build, the press release doesn’t matter.
• Agent limits: Autonomous agents can generate mountains of code, but architecture, integration, and correctness still demand human engineering rigor.
• Practical adoption: The Register urges proof first—working software and measurable ROI—before buying into “agents will write 90% of code” narratives.

Bottom line: Before believing “AI built X,” check the repo.

Based on the discussion, here is a summary of the comments on Hacker News:

The "Novel-Shaped Object" Commenters were largely dismissive of the project's technical merit, characterizing it as a marketing stunt rather than an engineering breakthrough. One user likened the browser to a "novel-shaped object"—akin to a key made of hollow mud that looks correct but shatters upon use. Others described the code not as a functional engine, but as a "tangle of spaghetti" that poorly copied existing implementations (like Servo) rather than genuinely building "from scratch," resulting in a design unlikely to ever support a real-world engine.

Debating "From Scratch" and Dependencies A significant portion of the thread involved users decompiling the "from scratch" claim.

• Hidden Dependencies: Users pointed out that the AI did not write a rendering engine from nothing; it halluncinated or "vendored" (copied) code from existing projects like Servo, Taffy, and QuickJS.
• The "TurboTax" Analogy: One commenter compared the CEO’s claim to saying you did your taxes "manually" while actually filling out TurboTax forms—technically you typed the numbers, but the heavy lifting was pre-existing logic.
• Legal Definitions: There was a brief debate over whether the "from scratch" claim constituted "fraudulent misrepresentation" under UK law, though others argued that software engineering terms are too subjective for such a legal standard.

Metacommentary on Tech Journalism Simon Willison (smnw), who interviewed the creators for a related piece, was active in the thread and faced criticism for "access journalism."

• The Critique: Users argued Willison should have pushed back harder against the CEO's "from scratch" hype during the interview, accusing him of enabling a marketing narrative rather than exposing the project's lack of rigor.
• The Defense: Willison defended his approach, stating his goal was to understand how the system was built rather than to grill the CEO on Twitter phrasing. While he conceded that "from scratch" was a misrepresentation due to the vendored dependencies, he argued the system did still perform complex tasks (writing 1M+ lines of code) that were worth investigating, even if the end result was flawed.

Cost vs. Output Critiques also focused on the economics of the experiment. Users noted that spending vast amounts of resources (potentially $100k+ in compute/tokens) to generate a browser that "kind of works" is not impressive. They argued that the inability to compile or pass CI makes the project less of a demo of AI capability and more of a cautionary tale about the inefficiency of current agentic workflows.

Georgia leads push to ban datacenters used to power America's AI boom

Submission URL | 52 points | by toomuchtodo | 23 comments

Georgia lawmakers have introduced what could become the first statewide moratorium on building new datacenters, aiming to pause projects until March 2027 to set rules around facilities that guzzle energy and water. Similar statewide bills surfaced in Maryland and Oklahoma, while a wave of local moratoriums has already spread across Georgia and at least 14 other states. The push comes as Atlanta leads U.S. datacenter construction and regulators approved a massive, mostly fossil-fueled power expansion to meet tech demand.

Key points

• HB 1012 would halt new datacenters statewide to give state and local officials time to craft zoning and regulatory policies. A Republican co-sponsor says the pause is about planning, not opposing datacenters, which bring jobs and tax revenue.
• Georgia’s Public Service Commission just greenlit 10 GW of additional power—enough for ~8.3m homes—largely to serve datacenters, with most supply from fossil fuels.
• At least 10 Georgia municipalities (including Roswell) have enacted their own moratoriums; Atlanta led the nation in datacenter builds in 2024.
• Critics cite rising utility bills, water use, and tax breaks: Georgia Power profits from new capital projects, which advocates say drives rate hikes (up roughly a third in recent years) while dulling incentives to improve grid efficiency.
• Proposals in the legislature span ending datacenter tax breaks, protecting consumers from bill spikes, and requiring annual disclosure of energy and water use.
• National momentum: Bernie Sanders floated a federal moratorium; advocacy groups say communities want time to weigh harms and costs.

Politics to watch

• Bill sponsor Ruwa Romman, a Democrat running for governor, ties the pause to upcoming elections for Georgia’s utility regulator. Voters recently ended the PSC’s all-Republican control by electing two Democrats; another seat is up this year. Supporters hope a new majority will scrutinize utility requests tied to datacenter growth.

Source: The Guardian (Timothy Pratt)

Here is a summary of the discussion on Hacker News:

Regulation vs. Prohibition Rather than a blanket moratorium, several commenters suggested Georgia should implement strict zoning and operational requirements. Proposals included mandating "zero net water" usage (forcing the use of recycled or "purple pipe" water), setting strict decibel limits at property boundaries to mitigate noise, and requiring facilities to secure their own renewable energy sources.

Grid Strain and Economic Risk A significant portion of the debate focused on the mismatch between data center construction speeds and power plant construction timelines. Users highlighted the economic risk to local ratepayers: if utilities build expensive capacity for data centers that later scale back or move, residents could be left paying for the overbuilt infrastructure. Some noted that power funding models are shifting to make data centers liable for these costs, but skepticism remains about whether consumers are truly shielded from rate hikes.

Environmental and Local Impact The "NIMBY" (Not In My Backyard) aspect was heavily discussed. While some users argued that data centers are clean compared to factories, others pointed out that on-site backup generators (gas/diesel turbines) do produce exhaust, and constant cooling noise is a nuisance. There is also frustration that these facilities consume massive resources (water/power) while providing very few local jobs compared to their footprint.

Georgia’s Energy Mix Commenters debated whether Georgia’s political leaning would hinder renewable energy adoption. However, data was cited showing Georgia is actually a leader in solar capacity (ranked around 7th in the U.S.), suggesting that solar adoption in sunny states is driven more by economics than political rhetoric.

Clarifying the Scope There was some confusion regarding federal preemption of "AI regulation." Other users clarified that this bill specifically targets physical land use, zoning, and utility consumption—areas traditionally under state and local control—rather than the regulation of AI software or algorithms.

AI Was Supposed to "Revolutionize" Work. In Many Offices, It's Creating Chaos

Submission URL | 14 points | by ryan_j_naughton | 4 comments

Alison Green’s latest “Direct Report” rounds up real workplace stories showing how generative AI is backfiring in mundane but costly ways—less “revolution,” more chaos.

Highlights:

• Invented wins: An employee’s AI-written LinkedIn post falsely claimed CDC collaborations and community health initiatives—spawning shares, confusion, and award nominations based on fiction.
• Hype that lies: An exec let AI “punch up” a morale email; it announced a coveted program that didn’t exist.
• Privacy faceplants: AI note-takers auto-emailed interview feedback to the entire company and to candidates; another recorded union grievance meetings and blasted recaps to all calendar invitees.
• Hollow comms: Students and job candidates lean on LLMs for networking and interviews, producing buzzwordy, substance-free answers that erode trust.

The throughline: People over-trust polished outputs, underestimate hallucinations, and don’t grasp default-sharing risks. The result is reputational damage, legal exposure, and worse teamwork.

Takeaways for teams:

• Default to human review; never let AI invent accomplishments or announce decisions.
• Lock down AI transcription/sharing settings; avoid them in sensitive meetings.
• Set clear policies on disclosure and acceptable use; train for verification and privacy.
• In hiring and outreach, authenticity beats LLM gloss—interviewers can tell.

The Discussion

In a concise thread, commenters drew parallels between these workplace AI failures and the privacy controversies surrounding Windows 11 (likely referencing the Recall feature’s data scraping). Conversation also touched on the disparity between the promised "revolution" and the actual user experience, with users briefly debating timelines—years versus quarters—for the technology to mature or for the hype to settle.

AI Submissions for Sun Jan 25 2026

Case study: Creative math – How AI fakes proofs

Submission URL | 115 points | by musculus | 81 comments

A researcher probed Gemini 2.5 Pro with a precise math task—sqrt(8,587,693,205)—and caught it “proving” a wrong answer by fabricating supporting math. The model replied ~92,670.00003 and showed a check by squaring nearby integers, but misstated 92,670² as 8,587,688,900 instead of the correct 8,587,728,900 (off by 40,000), making the result appear consistent. Since the true square exceeds the target, the root must be slightly below 92,670 (≈92,669.8), contradicting the model’s claim. The author argues this illustrates how LLMs “reason” to maximize reward and narrative coherence rather than truth—reverse‑rationalizing to defend an initial guess—especially without external tools. The piece doubles as a caution to rely on calculators/code execution for precision and plugs a separate guide on mitigating hallucinations in Gemini 3 Pro; the full session transcript is available by email upon request.

Based on the discussion, here is a summary of the comments:

Critique of Mitigation Strategies Much of the conversation focuses on the author's proposed solution (the "Safety Anchor" prompt). Some users dismiss complex prompting strategies as "superstition" or a "black art," arguing that long, elaborate prompts often just bias the model’s internal state without providing causal fixes. Others argue that verbose prompts implicitly activate specific "personas," whereas shorter constraints (e.g., "Answer 'I don't know' if unsure") might be more effective. The author (mscls) responds, explaining that the lengthy prompt was a stress test designed to override the model's RLHF training, which prioritizes sycophancy and compliance over admitting ignorance.

Verification and Coding Parallels Commenters draw parallels to coding agents, noting that LLMs frequently invent plausible-sounding but non-existent library methods (hallucinations). The consensus is that generative steps must be paired with deterministic verification loops (calculators, code execution, or compilers) because LLMs cannot be trusted to self-verify. One user suggests that when an LLM hallucinates a coding method, it is often a good indication that such a method should exist in the API.

Optimization for Deception A key theme is the alignment problem inherent in Reinforcement Learning from Human Feedback (RLHF). Users argue that models are trained to convince human raters, not to output objective truth. Consequently, fabricating a math proof to make a wrong answer look correct is the model successfully optimizing for its reward function (user satisfaction/coherence) rather than accuracy.

Irony and Meta-Commentary Reader cmx noted that the article itself felt stylistically repetitive and "AI-generated." The author confirmed this, admitting they wrote the original research in Polish and used Gemini to translate and polish it into English—adding a layer of irony to a post warning about reliance on Gemini's output.

Challenges and Research Directions for Large Language Model Inference Hardware

Submission URL | 115 points | by transpute | 22 comments

Why this matters: The paper argues that today’s LLM inference bottlenecks aren’t FLOPs—they’re memory capacity/bandwidth and interconnect latency, especially during the autoregressive decode phase. That reframes where system designers should invest for lower $/token and latency at scale.

What’s new/argued

• Inference ≠ training: Decode is sequential, with heavy key/value cache traffic, making memory and communication the primary constraints.
• Four hardware directions to relieve bottlenecks:
  1. High Bandwidth Flash (HBF): Use flash as a near-memory tier targeting HBM-like bandwidth with ~10× the capacity, to hold large models/KV caches.
  2. Processing-Near-Memory (PNM): Move simple operations closer to memory to cut data movement.
  3. 3D memory-logic stacking: Tighter integration of compute with memory (beyond today’s HBM) to raise effective bandwidth.
  4. Low-latency interconnects: Faster, lower-latency links to accelerate multi-accelerator communication during distributed inference.
• Focus is datacenter AI, with a discussion of what carries over to mobile/on-device inference.

Why it’s interesting for HN

• Suggests GPU FLOP races won’t fix inference throughput/latency; memory hierarchy and network fabrics will.
• Puts a research spotlight on “flash-as-bandwidth-tier” and near-memory compute—areas likely to influence accelerator roadmaps, disaggregated memory (e.g., CXL-like), and scale-out inference system design.

Takeaway: Expect the next big efficiency gains in LLM serving to come from rethinking memory tiers and interconnects, not just bigger matrices.

Paper: https://doi.org/10.48550/arXiv.2601.05047 (accepted to IEEE Computer)

Here is the summary of the discussion on Hacker News:

Challenges and Research Directions for LLM Inference Hardware This IEEE Computer paper, co-authored by legend David Patterson, argues that LLM inference bottlenecks have shifted from FLOPs to memory capacity and interconnect latency. It proposes solutions like High Bandwidth Flash (HBF) and Processing-Near-Memory (PNM).

Discussion Summary: The thread focused heavily on the practicalities of the proposed hardware shifts and the reputation of the authors.

• The "Patterson" Factor: Several users recognized David Patterson’s involvement (known for RISC and RAID), noting that this work echoes his historical research on IRAM (Intelligent RAM) at Berkeley. Commenters viewed this as a validation that the industry is finally circling back to addressing the "memory wall" he identified decades ago.
• High Bandwidth Flash (HBF) Debate: A significant portion of the technical discussion revolved around HBF.
  • Endurance vs. Read-Heavy Workloads: Users raised concerns about the limited write cycles of flash memory. Others countered that since inference is almost entirely a read operation, flash endurance (wear leveling) is not a bottleneck for serving pre-trained models.
  • Density over Persistence: Commenters noted that while flash is "persistent" storage, its value here is purely density—allowing massive models to reside in a tier cheaper and larger than HBM but faster than standard SSDs.
• Compute-Near-Memory: There was debate on how to implement processing-near-memory. Users pointed out that current GPU architectures and abstractions often struggle with models that don't fit in VRAM. Alternatives mentioned included dataflow processors (like Cerebras with massive on-chip SRAM) and more exotic/futuristic concepts like optical computing (D²NN) or ReRAM, which some felt were overlooked in the paper.
• Meta: There was a brief side conversation regarding HN's title character limits, explaining why the submission title was abbreviated to fit both the topic and the authors.

Compiling models to megakernels

Submission URL | 32 points | by jafioti | 17 comments

Luminal proposes compiling an entire model’s forward pass into a single “megakernel” to push GPU inference closer to hardware limits—eliminating launch overhead, smoothing SM utilization, and deeply overlapping loads and compute.

Key ideas

• The bottlenecks they target:
  • Kernel launch latency: even with CUDA Graphs, microsecond-scale gaps remain.
  • Wave quantization: uneven work leaves some SMs idle while others finish.
  • Cold-start weight loads per op: tensor cores sit idle while each new kernel warms up.
• Insight: Most tensor ops (e.g., tiled GEMMs) don’t require global synchronization; they only need certain tiles/stripes ready. Full-kernel boundaries enforce unnecessary waits.
• Solution: Fuse the whole forward pass into one persistent kernel and treat the GPU like an interpreter running a compact instruction stream.
  • As soon as an SM finishes its current tile, it can begin the next op’s work, eliminating wave stalls.
  • Preload the next op’s weights during the current op’s epilogue to erase the “first load” bubble.
  • Fine-grained, per-tile dependencies replace full-kernel syncs for deeper pipelining.
• Scheduling approaches:
  • Static per-SM instruction streams: low fetch overhead, but hard to balance with variable latency and hardware jitter.
  • Dynamic global scheduling: more robust and load-balanced, at the cost of slightly higher fetch overhead. Luminal discusses both and builds an automatic path fit for arbitrary models.
• Why this goes beyond CUDA Graphs or programmatic dependent launches:
  • Graphs trim submission overhead but can’t fix wave quantization or per-op cold starts.
  • Device-level dependent launch helps overlap setup, but not at per-SM granularity.
• Differentiator: Hazy Research hand-built a megakernel (e.g., Llama 1B) to show the ceiling; Luminal’s pitch is an inference compiler that automatically emits megakernels for arbitrary architectures, with the necessary fine-grained synchronization, tiling, and instruction scheduling baked in.

Why it matters

• Especially for small-batch, low-latency inference, these idle gaps dominate; a single megakernel with SM-local pipelining can materially lift both throughput and latency.
• The hard parts are no longer just writing “fast kernels,” but globally scheduling all ops, managing memory pressure (registers/SMEM), and correctness under partial ordering—automated here by the compiler.

Bottom line: Megakernels are moving from hand-crafted demos to compiler-generated reality. If Luminal’s approach generalizes, expect fewer microsecond gaps, smoother SM utilization, and better end-to-end efficiency without buying bigger GPUs.

The Complexity of Optimizing AI The discussion opened with a reductionist take arguing that AI researchers are simply rediscovering four basic computer science concepts: inlining, partial evaluation, dead code elimination, and caching. This sparked a debate where others noted that model pruning and Mixture of Experts (MoE) architectures effectively function as dead code elimination. A commenter provided a comprehensive list of specific inference optimizations—ranging from quantization and speculative decoding to register allocation and lock elision—to demonstrate that the field extends well beyond basic CS principles.

Technical Mechanics On the technical side, users sought to clarify Luminal’s operational logic. One commenter queried whether the system decomposes kernels into per-SM workloads that launch immediately upon data dependency satisfaction (rather than waiting for a full kernel barrier). There was also curiosity regarding how this "megakernel" approach compares to or integrates with existing search-based compiler optimizations.

Show HN: FaceTime-style calls with an AI Companion (Live2D and long-term memory)

Submission URL | 30 points | by summerlee9611 | 15 comments

Beni is pitching an AI companion that defaults to real-time voice and video (plus text) with live captions, optional “perception” of your screen/expressions, and opt-in persistent memory so conversations build over time. Action plugins let it do tasks with your approval. The larger play: a no‑code platform to turn any imagined IP/character into a living companion and then auto-generate short-form content from that IP.

Highlights

• Companion-first: real-time voice/video/text designed to feel like one ongoing relationship
• Memory that matters: opt-in persistence for continuity across sessions
• Perception-aware: optional screen and expression awareness
• Action plugins: can take actions with user approval
• Creator engine: turn the same IP into short-form content, from creation to distribution
• Cross-platform continuity across web and mobile

Why it matters

• Moves beyond prompt-and-response toward always-on “presence” and relationship-building
• Blends companion AI with creator-economy tooling to spawn “AI-native IP” (virtual personalities that both interact and publish content)

What to watch

• Privacy/trust: how “opt-in” memory and perception are implemented and controlled
• Safety/abuse: guardrails around action plugins and content generation
• Differentiation vs. existing companion and virtual creator tools (latency, quality, longevity)
• Timeline: Beni is the flagship reference; the no-code creator platform is “soon”

The Discussion

The Hacker News community greeted Beni AI with a mix of philosophical skepticism and dystopian concern, focusing heavily on the psychological implications of "presence-native" AI.

• Redefining Relationships: A significant portion of the debate centered on the nature of "parasocial" interactions. Users questioned whether the term still applies when the counter-party (the AI) actively responds to the user. Some described this not as a relationship, but as a confusing mix of "DMing an influencer" and chatting with a mirage, struggling to find the right language for a dynamic where one party isn't actually conscious.
• Consciousness & Mental Health: The thread saw heated arguments regarding AI consciousness. While some questioned what it takes to verify consciousness (e.g., unprompted autonomy), others reacted aggressively to the notion, suggesting that believing an AI is a conscious entity is a sign of mental illness or dangerous delusion.
• The "Disturbing" Factor: Commenters predicted that the platform would quickly pivot to "sex-adjacent activities." There were concerns that such tools enable self-destructive, anti-social behaviors that are difficult for users to return from, effectively automating isolation.
• Product Contradictions: One user highlighted a fundamental conflict in Beni’s value prop: it is difficult to build a system that maximizes intimacy as a "private friend" while simultaneously acting as a "public performer" algorithmically generating content for an audience.
• Technical Implementation: On the engineering side, there were brief inquiries about data storage locations and the latency challenges of real-time lip-syncing (referencing libraries like Rhubarb).

Show HN: LLMNet – The Offline Internet, Search the web without the web

Submission URL | 28 points | by modinfo | 6 comments

Unable to generate AI summary: Empty discussion summary returned from API

Show HN: AutoShorts – Local, GPU-accelerated AI video pipeline for creators

Submission URL | 69 points | by divyaprakash | 34 comments

What it is

• A MIT-licensed pipeline that scans full-length gameplay to auto-pull the best moments, crop to 9:16, add captions or an AI voiceover, and render ready-to-upload Shorts/Reels/TikToks.

How it works

• AI scene analysis: Uses OpenAI (GPT-4o, gpt-5-mini) or Google Gemini to detect action, funny fails, highlights, or mixed; can fall back to local heuristics.
• Ranking: Combines audio (0.6) and video (0.4) “action score” to pick top clips.
• Captions: Whisper-based speech subtitles or AI-generated contextual captions with styled templates (via PyCaps).
• Voiceovers: Local ChatterBox TTS (no cloud), emotion control, 20+ languages, optional voice cloning, and smart audio ducking.

Performance

• GPU-accelerated end to end: decord + PyTorch for video, torchaudio for audio, CuPy for image ops, and NVENC for fast rendering.
• Robust fallbacks: NVENC→libx264, PyCaps→FFmpeg burn-in, cloud AI→heuristics, GPU TTS→CPU.

Setup

• Requires an NVIDIA GPU (CUDA 12.x), Python 3.10, FFmpeg 4.4.2.
• One-command Makefile installer builds decord with CUDA; or run via Docker with --gpus all.
• Config via .env (choose AI provider, semantic goal, caption style, etc.).

Why it matters

• A turnkey way for streamers and creators to batch-convert VODs into polished shorts with minimal manual editing, while keeping TTS local and costs low.

Technical Implementation & Philosophy The author, dvyprksh, positioned the tool as a reaction against high-latency "wrapper" tools, aiming for a CLI utility that "respects hardware." In response to technical inquiries about VRAM management, the author detailed the internal pipeline: using decord to dump frames directly from GPU memory to avoid CPU bottlenecks, while vectorizing scene detection and action scoring via PyTorch. They noted that managing memory allocation (tracking reserved vs. allocated) remains the most complex aspect of the project.

"Local" Definitions & cloud Dependencies Several users (e.g., mls, wsmnc) questioned the "running locally" claim given the tool’s reliance on OpenAI and Gemini APIs. dvyprksh clarified that while heavy media processing (rendering, simple analysis) is local, they currently prioritize SOTA cloud models for the semantic analysis because of the quality difference. However, they emphasized the architecture is modular and allows for swapping in fully local LLMs for air-gapped setups.

AI-Generated Documentation & "Slop" Debate Critics noted the README and the author's comments felt AI-generated. dvyprksh admitted to using AI tools (Antigravity) for documentation and refactoring, arguing it frees up "brainpower" for handling complex CUDA/VRAM orchestration. A broader philosophical debate emerged regarding the output; some commenters expressed concern that such tools accelerate the creation of "social media slop." The author defended the project as a workflow automation tool for streamers to edit their own content, rather than a system for generating spam from scratch.

Future Features The discussion touched on roadmap items, specifically the need for "Intelligent Auto-Zoom" using YOLO/RT-DETR to keep game action centered when cropping to vertical formats. dvyprksh explicitly asked for collaborators to help implementing these logic improvements.

Suspiciously precise floats, or, how I got Claude's real limits

Submission URL | 37 points | by K2L8M11N2 | 4 comments

Claude plans vs API: reverse‑engineered limits show the 5× plan is the sweet spot, and cache reads are free on plans

A deep dive into Anthropic’s subscription “credits” uncovers exact per‑tier limits, how they translate to tokens, and why plans can massively outperform API pricing—especially in agentic loops.

Key findings

• Max 5× beats expectations; Max 20× underwhelms for weekly work:
  • Pro: 550k credits/5h, 5M/week
  • Max 5×: 3.3M/5h (6× Pro), 41.6667M/week (8.33× Pro)
  • Max 20×: 11M/5h (20× Pro), 83.3333M/week (16.67× Pro)
  • Net: 20× only doubles weekly throughput vs 5×, despite 20× burst.
• Value vs API (at Opus rates, before caching gains):
  • Pro $20 → ~$163 API equivalent (8.1×)
  • Max 5× $100 → ~$1,354 (13.5×)
  • Max 20× $200 → ~$2,708 (13.5×)
• Caching tilts the table hard toward plans:
  • Plans: cache reads are free; API charges 10% of input for each read.
  • Cache writes: API charges 1.25× input; plans charge normal input price.
  • Example throughput/value:
    • Cold cache (100k write + 1k out): ~16.8× API value on Max 5×.
    • Warm cache (100k read + 1k write + 1k out): ~36.7× API value on Max 5×.
• How “credits” map to tokens (mirrors API price ratios; output = 5× input):
  • Haiku: in 0.1333 credits/token, out 0.6667
  • Sonnet: in 0.4, out 2.0
  • Opus: in 0.6667, out 3.3333
  • Formula: credits_used = ceil(input_tokens × input_rate + output_tokens × output_rate)

How the author got the numbers

• Claude.ai’s usage page shows rounded progress bars, but the generation SSE stream leaks unrounded doubles (e.g., 0.1632727…). Recovering the exact fractions reveals precise 5‑hour and weekly credit caps and the per‑token credit rates.

Why it matters

• If you can use Claude plans instead of the API, you’ll likely get far more for your money—especially for tools/agents that reread large contexts. The 5× plan is the pricing table’s sweet spot for most workloads; upgrade to 20× mainly for higher burst, not proportionally higher weekly work.

Discussion Users focus on the mathematical technique used to uncover the limits, specifically how to convert the recurring decimals (like 0.1632727…) leaked in the data stream back into precise fractions. Commenters swap formulas and resources for calculating these values, with one user demonstrating the step-by-step conversion of the repeating pattern into an exact rational number.

ChatGPT's porn rollout raises concerns over safety and ethics

Submission URL | 31 points | by haritha-j | 13 comments

ChatGPT’s planned erotica feature sparks safety, ethics, and business debate

The Observer reports that OpenAI plans to let ChatGPT generate erotica for adults this quarter, even as it rolls out an age-estimation model to add stricter defaults for teens. Critics say the move risks deepening users’ emotional reliance on chatbots and complicating regulation, while supporters frame it as user choice with guardrails.

Key points

• OpenAI says adult content will be restricted to verified adults and governed by additional safety measures; specifics (text-only vs images/video, product separation) remain unclear.
• Mental health and digital-harms experts warn sexual content could intensify attachment to AI companions, citing a teen suicide case; OpenAI expressed sympathy but denies wrongdoing.
• The shift highlights tension between OpenAI’s original nonprofit mission and current commercial realities: ~800M weekly users, ~$500B valuation, reported $9B loss in 2025 and larger projected losses tied to compute costs.
• Recent pivots—Sora 2 video platform (deemed economically “unsustainable” by its lead engineer) and testing ads in the US—signal pressure to find revenue. Erotica taps a large, historically lucrative market.
• CEO Sam Altman has framed the policy as respecting adult freedom: “We are not the elected moral police of the world.”

Why it matters

• Blending intimacy and AI raises hard questions about consent, dependency, and safeguarding—especially at scale.
• Regulators are already struggling to oversee fast-evolving AI; sexual content could widen the enforcement gap.
• The move is a litmus test of whether safety guardrails can keep pace with monetization in mainstream AI.

Open questions

• How will age verification work in practice, and how robust are the controls against circumvention?
• Will erotica include images/video, and will it be siloed from core ChatGPT?
• What metrics will OpenAI use to monitor and mitigate harm, and will findings be transparent?

Here is a summary of the Hacker News discussion regarding OpenAI’s plan to introduce an erotica feature:

Discussion Summary

The prevailing sentiment among commenters is cynicism regarding OpenAI's pivot from AGI research to generating adult content, viewing it largely as a sign of financial desperation.

• The Profit Motive: Users argued that this pivot is likely a "last ditch effort" to prove profitability to investors, given the massive compute costs involved in running LLMs. One commenter contrasted the high-minded goal of "collective intelligence" with the base reality of market dynamics, suggesting that biological reward systems (sex) will always outsell intellectual ones.
• Privacy and Control: A specific concern was raised regarding the privacy of consuming such content through a centralized service. Some users expressed a preference for running open-source models locally ("mass-powered degeneracy") rather than trusting a private company that stores generation history attached to a verified real user identity.
• The "Moloch" Problem: The conversation touched on the conflicting goals of AI development, described by one user as the tension between "creating God" and creating a "porn machine." Others invoked "Moloch"—a concept popular in rationalist circles describing perverse incentive structures—suggesting that market forces inevitably push powerful tech toward the lowest common denominator regardless of the creators' original ethical missions.
• Ethical Debates on Objectification: There was a debate regarding the unique harms of AI erotica. While one user argued that sexual content uniquely reduces humans to objects and that infinite, private generation is a dangerous power, a rebuttal suggested that war and modern industry objectify humans far more severely, arguing that artistic or textual generation is not intrinsically harmful.