MurphyA/hacker-news huggingface dataset:
by throwyawayyyy | 2026-03-11 01:46:13+00:00
I do find it hilarious that after all the machine learning optimizations done on people's feeds over the years, all the promos got for a 1% improvement on this metric, every E7 and E8 who can claim x% of this or that, after all of that work, we might genuinely, and not even as a joke, be in the situation of needing to throw _other_ AI agents at this selfsame feed in order to extract any real value from it. What a world we've built.
by abacate | 2026-03-11 01:46:36+00:00
I believe you are understanding the opposite of what was said.

I understood it as "there cannot be trust anymore" - mostly because different people are at risk of becoming a victim in different ways: from a crime itself, or from being falsely accused of committing a crime.

Individuals will act in a way that makes sense for them. Asking them to "just trust more" does not solve the problem - it needs to be addressed at the root (education, communities), which goes far beyond the individual level.
by JamesLangford | 2026-03-11 01:46:49+00:00
I mostly ignore how the code was made and review the artifact the same way I always have: correctness, tests, readability, and whether it matches the system design. The prompt history is fine, but it’s not something I want to rely on during review because it’s not stable or reproducible.

What does help is requiring a short design note in the PR explaining the intent, constraints, and alternatives considered. That gives the context reviewers actually need without turning the review into reading a chat transcript.
by rgoulter | 2026-03-11 01:46:50+00:00
I think you're missing out on magit.

With magit, the routine git tasks are very fast & flowing, git becomes highly discoverable, and complex tasks are made easy.

For example of things that are tedious on the CLI: magit makes it easy to make "--fixup" commits (since you can select the commit you intend to fix up). Or if you want to use something like git-absorb, that's also easy in magit.

Or magit makes it easy to stage/unstage line by line.
by rekabis | 2026-03-11 01:47:15+00:00
WTF did I just read?

I mean, maybe I’m just a bit on the older side. And being on the spectrum, I am also brutally practical.

But reading this was a lot like having an alien psychology described to me. It’s got solid echoes of the Beanie Baby craze of the 90s, and confuses me deeply and to no end.
by ekropotin | 2026-03-11 01:48:14+00:00
As someone who been a teen long time ago, I can’t imaging someone in this age responsibly planning their retirement.

I’d 100% blow out all money on some useless crap.

If you are really a teen, who can think so clearly and far-sightedly, you are going to have a really bright future as an adult. I wish you luck and please do something good for this world, instead of chasing high paying job in FAANG.
by coderenegade | 2026-03-11 01:48:35+00:00
I think that in the long run, AI assisted coding will turn out to be better than handcrafted code. When you pay for every token, and code generation is quick, a clean, low entropy codebase with good test coverage gets you a lot more for your dollar than a dog's breakfast. It's also much easier to fix bad decisions made early on in a project's life, because the machine is doing all of the heavy lifting.

This also lines up with the history of automation in many other industries. Modern manufacturing is capable of producing parts that a medieval blacksmith couldn't dream of, for example. Sure, maybe an artisan can produce better code than an llm now, but AI assisted humans will beat them in the near future if they aren't already producing similar quality output at greater speed, and tomorrow's models will fix the bad code written today. The fact that there's even a discussion on automated vs hand written today means that the writing is almost certainly on the wall.
by themafia | 2026-03-11 01:49:08+00:00
The traditional Bloomberg money worship.

> But the platform’s more successful game makers say they don’t have complaints.

Imagine being a journalist and just accepting this and ending a paragraph with it.

> “In Amsterdam we did get a VIP table at a club overlooking everyone,” Zirschky says. “But we always make sure to try McDonald’s in every country.”

Blind consumerism making up for a lost childhood? Yikes, even for Bloomberg.
by gwern | 2026-03-11 01:49:46+00:00
> They almost certainly have never seen regular conversations in Base64 in their training set, so its weird that it 'just works'.

People use Base64 to store payloads of many arbitrary things, including web pages or screenshots, both deliberately and erroneously, and so they have almost certainly seen regular conversations in Base64 in their 10tb+ text training sets scraped from billions of web pages and files and mangled emails etc.
by fleebee | 2026-03-11 01:50:37+00:00
The most egregious thing Perplexity did was to straight up ignore robots.txt. Cloudflare promise not to do that, so if we take their word for it, it's a quite different setup.

That said, I'm not fan of letting users forge whatever user agents they please. Instead, AIUI to opt-out of getting crawled I have to look for the existence of certain request headers[1].

[1]: https://developers.cloudflare.com/browser-rendering/referenc...
by michaelteter | 2026-03-11 01:51:31+00:00
0.0043.

But I think this kind of test can really be limited on your display and color profiles.

Most of my misses were on blues, but sometimes the line was obvious. Other times, I could “see” many phantom bars of slightly different colors.

And in bright sunlight, I can see variations in the film in my phone screen. I suspect this could affect a test like this.
by sanchitmonga22 | 2026-03-11 01:51:34+00:00
Fair question, let me clarify.

RunAnywhere is an inference company. We build the runtime layer for on-device AI.

There are two pieces:

MetalRT, a proprietary GPU inference engine for Apple Silicon. It runs LLMs, speech-to-text, and text-to-speech faster than anything else available (benchmarks: https://www.runanywhere.ai/blog/metalrt-fastest-llm-decode-e...). This is our core product.

RCLI, an open-source CLI (MIT) that demonstrates what MetalRT enables. It wires STT + LLM + TTS into a real voice pipeline with 43 macOS actions, local RAG, and a TUI. Think of it as the reference application built on top of the engine.

On RAG specifically: voice + document Q&A is a natural pairing for on-device use cases. You have sensitive documents you don't want to upload to the cloud, you ingest them locally, and then ask questions by voice. The retrieval runs at ~4ms over 5K+ chunks, so it feels instant in the voice pipeline. Its not random, it's one of the strongest privacy arguments for running everything locally.

The longer-term vision is bringing MetalRT to more chips and platforms, so any developer can get cloud-competitive inference on-device with minimal integration effort.
by sanchitmonga22 | 2026-03-11 01:52:33+00:00
Fully public Metal APIs, no private frameworks, no Neural Engine, no undocumented entitlements.

MetalRT is built on the public Metal API. The performance comes from how we use the GPU, not from accessing anything Apple doesn't document.

We specifically chose to stay on public APIs so that MetalRT works on any Apple Silicon Mac without special entitlements or SIP workarounds. This also means its App Store compatible for future macOS/iOS distribution.

The results speak for themselves: 1.1-1.19x faster than Apple's own MLX on identical model files, 4.6x faster on STT, 2.8x faster on TTS. Full methodology published here: https://www.runanywhere.ai/blog/metalrt-fastest-llm-decode-e...

Appreciate the kind words, the "OpenClaw world" framing is exactly why we built this.
by al_borland | 2026-03-11 01:52:37+00:00
At the end of the day, the code is the only thing that matters. That is what defines, in concrete terms, what the program is doing. I don't view an LLM as a high level language, as we can run a prompt 10 different times and get 10 different results. This isn't valuable when it comes to programming.

Even without LLMs, there was a thought process that led to the engineer coming to a specific outcome for the code, maybe some conversations with other team members, discussions and thoughts about trade offs, alternatives, etc... all of this existed before.

Was that all included in the PR in the past? If so, the engineer would have to add it in, so they should still do so. If not, why do you all the sudden need it because of an AI involved?

I don't see why things would fundamentally change.
by sanchitmonga22 | 2026-03-11 01:53:29+00:00
Respectfully, the benchmarks show it is different.

MetalRT and mlx-lm use the exact same model files, identical 4-bit MLX weights. That makes it a pure engine-to-engine comparison:

LLM decode: MetalRT is 1.10-1.19x faster across all models tested

STT: 70s audio in 101ms vs 463ms (4.6x faster)

TTS: 178ms vs 493ms (2.8x faster)

mlx-lm is a general-purpose array computation framework that also supports inference. MetalRT is purpose-built for inference only. That focus is where the performance gap comes from.

You can reproduce these numbers yourself: rcli bench runs the same benchmarks we published. Full methodology: https://www.runanywhere.ai/blog/metalrt-fastest-llm-decode-e...

Yes, MetalRT is closed-source. We're transparent about that. The performance difference is the reason it exists.
by kerkeslager | 2026-03-11 01:54:11+00:00
> If you are a two man startup, burning through runway and pre-product-market fit... then spending a lot of time on tests is questionable (although the cost-benefit now with AI is changing very fast).

What's insane that people in 2026 still think tests slow you down.

It takes me maybe 40 hours (1 week) of coding to start receiving ROI from writing tests in a greenfield project, and by 80 hours I'm pretty sure I've saved more time from bugs and improved design due to TDD than I've spent writing the tests.

The ROI is even faster if I'm not the only developer on the project.

If your flagship product takes less time to develop than 40 hours, then your product is extremely vulnerable to being copied by another company, so your entire software project is a bad business idea.

So there really aren't many exceptions: either your project benefits from tests, or it's too easy a project to be a business.

So frankly, it's your comment lacking in cost/benefit analysis.
by stanfordkid | 2026-03-11 01:54:24+00:00
It's pretty simple... the word circle and what you can correlate to it via english language description has somewhat less to do with reality than a physical 3D model of a circle and what it would do in an environment. You can't just add more linguistic description via training data to change that. It doesn't really matter that you can keep back propagating because what you are back propagating over is fundamentally and qualitatively less rich.
by sanchitmonga22 | 2026-03-11 01:54:33+00:00
uzu is a strong engine, it beat us on Llama-3.2-3B (222 vs 184 tok/s) and we reported that honestly in our benchmarks.

But looking at the full picture across all four models tested:

Qwen3-0.6B: MetalRT 658, uzu 627

Qwen3-4B: MetalRT 186, uzu 165

Llama-3.2-3B: uzu 222, MetalRT 184

LFM2.5-1.2B: MetalRT 570, uzu 550

MetalRT wins 3 of 4. The bigger difference is that MetalRT also handles STT and TTS natively, uzu is LLM-only. For a voice pipeline where you need all three modalities running on one engine with shared memory management, that matters.

That said, uzu is great open-source software and worth checking out if your looking for an OSS LLM-only engine on Apple Silicon.
by jasomill | 2026-03-11 01:54:40+00:00
I'm still waiting for the first password manager to incorporate biometrics and security questions, as predicted decades ago by Douglas Adams:

There were so many different ways in which you were required to provide absolute proof of your identity these days that life could easily become extremely tiresome just from that factor alone, never mind the deeper existential problems of trying to function as a coherent consciousness in an epistemologically ambiguous physical universe. Just look at cash point machines, for instance. Queues of people standing around waiting to have their fingerprints read, their retinas scanned, bits of skin scraped from the nape of the neck and undergoing instant (or nearly instant-a good six or seven seconds in tedious reality) genetic analysis, then having to answer trick questions about members of their family they didn't even remember they had, and about their recorded preferences for tablecloth colours. And that was just to get a bit of spare cash for the weekend. If you were trying to raise a loan for a jetcar, sign a missile treaty or pay an entire restaurant bill things could get really trying.

Hence the Ident-i-Eeze. This encoded every single piece of information about you, your body and your life into one all-purpose machine-readable card that you could then carry around in your wallet, and therefore represented technology's greatest triumph to date over both itself and plain common sense.
by sanchitmonga22 | 2026-03-11 01:55:42+00:00
Fair feedback on the README clarity, we've updated it to make the licensing distinction between RCLI (MIT) and MetalRT (proprietary) more prominent. That should have been clearer from day one.

On why we built MetalRT instead of using CoreML or MLX:

CoreML is optimized for classification and vision models, not autoregressive text generation. ANE is powerful for fixed-shape workloads but doesn't handle the dynamic shapes in LLM decode well.

MLX is much closer to what we need, and we respect what Apple has built. But MLX is a general-purpose array framework, it carries abstractions for developer ergonomics and portability that add overhead. MetalRT is purpose-built for inference only, and the numbers reflect that: 1.1-1.2x faster on LLMs (same model files) and 4.6x faster on STT.

We also needed one unified engine for LLM + STT + TTS rather than stitching three separate runtimes together. That doesn't exist in any of the alternatives listed.

The libraries you mentioned (FluidAudio, mlx-swift-audio, sherpa-onnx) are good projects. RCLI actually uses sherpa-onnx as it's fallback engine when MetalRT isn't installed. They solve different problems at different layers of the stack.
by themadturk | 2026-03-11 01:55:42+00:00
This reminds me of someone I knew slightly back in the late 70s: Robert Shields, who kept the world's longest diary [0]. He was eccentric but very nice...but he wrote 33 million words, filling 90+ boxes, of every detail of his life for decades, only quitting when a stroke rendered him unable to type about ten years before his death. I doubt he tried to reach any conclusions based on his journaling, though.

[0] https://en.wikipedia.org/wiki/Robert_Shields_%28diarist%29
by panick21_ | 2026-03-11 01:56:02+00:00
Nuclear plans have objectively made power generation save and clean. When they were built in the 1960-1990s the were objectively the best and cleanest energy that saved a gigantic amount of lives.

The exclusion zone is nonsense because many that live in that zone has lower cancer rates then those outside. The idea is based on a invalid assumption about radiation an a linear relationship between radiation and harm. An I do think the standards we apply are to extreme in many cases mostly dating back to this misunderstanding about radiation.

As for the locality to nuclear plants and cancer, this is as far as I know been shown in many countries and as far as I know at least can mostly be explained by nuclear plants usually being built in industrial areas that often used to have coal plants and other industry going on.

> nuclear reactors are there for the spicy atoms, not the price tag or public safety.

Not sure what 'spicy' means in this context. In terms of price tag they are objectively a fantastic deal if built in larger numbers. Even in places where they were not built in the numbers they did in France, they are good life time deal, and give relativity stable long term prices.

And they don't have to be 'there' for public safety, they just need a good record on public safety and they do.

In places like Austria and Germany we have many known cases where a nuclear plant was planned and was prevented by activists, only to be replaced by coal, in both cases impacting 10000s of lives being worse financially in the long term.
by sanchitmonga22 | 2026-03-11 01:56:46+00:00
Not yet with MetalRT, right now we support models up to ~4B parameters (Qwen3 4B, Llama 3.2 3B, LFM2.5 1.2B). These are optimized for the voice pipeline use case where decode speed and latency matter more then model size.

Expanding to larger models (7B, 14B, 32B) on machines with more unified memory is on the roadmap. The Mac Studio with 192GB would be an interesting target, a 32B model at 4-bit would fit comfortably and MetalRT's architectural advantages (fused kernels, minimal dispatch overhead) should scale well.

What model / use case are you thinking about? That helps us prioritize.
by gcanyon | 2026-03-11 01:57:27+00:00
I think you have evolution backwards. There only needs to not be a reason we need it to survive long enough to reproduce. Or more probabilistically, there needs to not be a significant reproductive benefit to it.

And bear in mind that most people don't have a problem surviving colds and the like long enough to reproduce even with no vaccines at all, and that was probably more true for much of our evolutionary history when we were living much more isolated lives, and not cohabiting with chickens and pigs.
by sanchitmonga22 | 2026-03-11 01:57:53+00:00
Ha, not yet. Metal 4 is interesting and we're keeping an eye on it.

MetalRT currently targets Metal 3.1 GPU compute because that's where we get the most control over the decode pipeline. Neural Engine / ANE is powerful for fixed-shape inference (vision, classification) but autoregressive LLM decode, where you're generating one token at a time with dynamic KV cache, doesn't map as cleanly to ANE today.

That said, if Metal 4 opens up new capabilities that help with sequential token generation or gives better programmable access to the neural accelerator, we'll absolutely look at it. The M5 will be a fun chip to benchmark on.
by canadiantim | 2026-03-11 01:57:54+00:00
I don't think just saying it's an anti-pattern for a multitude of reasons and then not naming any is sufficiently going to convince anyone it's an anti-pattern.

This is in fact precisely what skills is meant for and is the opposite of an anti-pattern, but more like best practice now. It's explicitly using the skills framework precisely how it was meant to be used.
by gwern | 2026-03-11 01:58:12+00:00
Adding, swapping, or duplicating layers has a long history (eg. StyleGAN, upcycling), and it was pointed out at least as far back as He et al 2015 (Resnets) that you could ablate or add more layers because they functioned more as just doing some incremental compute iteratively, and many of them were optional. So this idea is not far out of distribution, if at all, especially if you're a LLM who knows the literature and past approaches (which most humans would not because they only just got into this area post-ChatGPT).
by scrumper | 2026-03-11 01:58:24+00:00
> that rule could still look valid in the ECL long after the original reasons for it stopped applying.

Ha, then it'd be doing a great job of internalizing institutional knowledge! Wait a few years and then put another one on top. I'm not sure how these things incorporate new knowledge over time, or handle re-orgs and strategy shifts, or adapt as new verticals are added. Do you need ever increasing numbers of agents to keep things in line?

As much as I'd love to have a perfect example of one of these running - it really would be very beneficial - I do have a vague feeling that these ECL concepts (and similar Enterprise-wide knowledge management AI panaceas) are the 21st century equivalents of trying to build comprehensive expert systems in Prolog.

This is cool though. Agents make it seem more plausible in a way that pure RAG systems don't. I am sure there is mileage in more focused cases (like at the author's startup, or departmentally.)
by sanchitmonga22 | 2026-03-11 01:59:03+00:00
Thanks for trying it and for filing the bug, we're looking into the homebrew install issue.

On unsloth quants: agreed, they're consistently better bit-for-bit. Adding broader quantization format support (including unsloth's approach) is on the roadmap. Right now MetalRT works with MLX 4-bit files and GGUF Q4_K_M, we want to expand that.

On the grounding issue ("navigate to google.com" not actually navigating): you're right, that's a gap. The "open_url" action exists but the LLM doesn't always route to it correctly, especially with compound commands. Small models (0.6B-1.2B) have limited tool-calling accuracy, upgrading to Qwen3.5 4B via rcli upgrade-llm helps significantly. We're also improving the action routing prompts.

Appreciate the detailed feedback, this is exactly what we need.
Show HN: OpenClaw skill for think-tank style analysis of crises like Iran war
by vassilbek | 2026-03-11 02:00:00+00:00
Built a small OpenClaw skill for turning messy geopolitical situations into something closer to a real analyst memo.

The use case I had in mind was exactly the kind of fast-moving crisis where everyone has opinions, but very few people structure the problem well, for example the Iran war and its second-order effects on escalation, oil, regional actors, sanctions, shipping routes, and policy response options.

This skill is designed to help break that kind of situation into:
stakeholder mapping scenarios policy options and trade-offs implementation risks confidence levels and assumptions The goal is not “predict the future,” but force a more disciplined way to think through what might happen and what decisions actually follow from that.

Repo: https://github.com/vassiliylakhonin/global-think-tank-analys...

Example prompt: Use $global-think-tank-analyst to assess escalation scenarios, regional spillover risks, and policy response options related to the Iran war.
by sanchitmonga22 | 2026-03-11 02:00:01+00:00
Fair criticism. The action executed on the LLM side but didn't translate to the correct macOS action, the model hallucinated success instead of routing to the open_url tool.

This is a known limitation with small LLMs (0.6B-1.2B) doing tool calling. They sometimes confuse "I know what you want" with "I did it." Upgrading to a larger model improves tool-calling accuracy significantly.

We're also working on verification, having the pipeline confirm the action actually succeeded before reporting back. Thats a fair expectation and we should meet it.
by pqdbr | 2026-03-11 02:00:05+00:00
Off-topic, but I'm having a terrible experience with Cloudflare and would love to know if someone could offer some help.

All of a sudden, about 1/3 of all traffic to our website is being routed via EWR (New York) - me included -, even tough all our users and our origin servers are in Brazil.

We pay for the Pro plan but support has been of no help: after 20 days of 'debugging' and asking for MTRs and traceroutes, they told us to contact Claro (which is the same as telling me to contact Verizon) because 'it's their fault'.
by raviisoccupied | 2026-03-11 02:00:14+00:00
I have been working on a web app called Beval - Simple evaluations for your AI product that meant to be a 'lay person' introduction to evals.

In my day to day as a Product Manager working in a team that ships AI products, I often found myself wanting to do 'quick and dirty' LLM based evaluation on conversation transcripts and traces. I found myself blocked by 'Gemini in Google Sheets', it was too slow and cumbersome, and it didn't handle eval changes well. And because I was exploring, it wasn't helpful to try and set up something more robust with the team.

To fix the problem I eventually learned to call the OpenAI API in python and more sophisticated approaches like some listed here, but I really felt that I wanted a 'product' to help me and potentially help others.

You can check it out at https://www.beval.space

Full disclosure - this is vibe coded and still a work in progress.