macOS doesn't expose the monitor-mode / packet-injection path that WFB systems normally rely on. I really didn't like the idea of needing a separate linux box just to talk WFB to other edge devices, like drones. This talks to the ALFA AWUS036ACH as a USB peripheral directly, initializes the RTL8812AU, submits raw 802.11 WFB frames over bulk OUT, receives frames over bulk IN, and bridges them to WFB-NG’s distributor/aggregator UDP protocols.

Basically, this is what's working (you can see more detail in the readme):

- native macOS userspace RTL8812AU bring-up

- TX/RX of WFB datagrams

- production-ish service runtime

- macOS utun bridge helper (if you need an IP-based link)

- RF diagnostics, telemetry, LED heartbeat, TDD airtime controls

There's a GitHub alpha release with arm64 macOS binaries

This is definitely still alpha. The direct-radio path is currently macOS-focused and tested with ALFA AWUS036ACH adapters on both sides (the other side is a Raspberry Pi 5 running Bookworm). macOS 26 works through IOUSBHost as libusb is not reliable there. Linux should still use native WFB-NG + rtl88xxau monitor mode rather than this USB bridge. Long-range RF quality and calibration work are ongoing. So far, some short range profiles are showing pretty good results.

I’m sharing early because getting WFB-like radio links working from a Mac seemed unlikely when I started, and the path turned out to be more interesting than expected.

My goal is for this to be cross-platform as-needed. Next up is an attempt at Android support via USB-OTG. We'll see how that goes.

Comments URL: https://news.ycombinator.com/item?id=48053252

Points: 5

# Comments: 3

What about MetalRT's relationship to llama.cpp, onnx, MLX, transformers, etc? Is MetalRT a replacement for those? Designed to be compatible with a wide variety of model formats? Or are you just providing an abstraction on top of these?

We built DemoFly because we got tired of the gap between building features and showing them to people. Our team has been doing full-stack engineering for over a decade (most recently building Rownd, an authentication platform) and the one thing that never got easier was making demo videos. You finish a feature, you know it works, but showing it to someone means opening a screen recorder, figuring out what to say, re-recording when you stumble. So the demo just...doesn't happen.

DemoFly is a CLI tool. You point it at whatever you're building and it autonomously navigates your app using Playwright + image recognition, then produces a polished video with AI-generated voiceover. No screen recording, no scripting on your part.

How it works technically: - Node-based CLI. You run demofly against localhost or any browser-accessible target. - Playwright drives a headless browser. Image processing observes the rendered UI and decides what to interact with next. - As it navigates, it builds a narrative of what it's seeing and doing. - That narrative becomes a voiceover script, synthesized locally with AI TTS (kokoro). - Video is composited from the browser session frames + voiceover audio. - Output uploads to a dashboard where you can review, edit, and share.

What it's good at: Standard CRUD apps, multi-page flows, dashboards. Works well for "hey, check out what I built on this branch" type demos. Fits into CI if you want auto-generated changelogs or PR previews.

What's not perfect yet: Auth flows can trip it up (ironic, given our background in auth). Highly dynamic SPAs with lots of client-side state might confuse the navigation model. Canvas/WebGL/Video elements are mostly opaque to it. Voiceover occasionally describes something slightly wrong.

Pricing: Free tier has every feature, so no credit card is needed and there are no feature gates. Paid tiers just give you more credits for higher quality voices and output.

Grab the CLI, run your first demo, and roast our AI's narration! We’re ready for the feedback. I think...

Comments URL: https://news.ycombinator.com/item?id=47324590

Points: 4

# Comments: 1

Have you thought about supporting additional auth providers? Or providing a way for other auth services to add support for their products?

Agents will come and go (and probably run into the same orchestration headaches), but someone still has to build the reliable, open foundation they’ll stand on.

We also have plans for eval features in the product so that users can measure the quality of changes over time, whether to their own project configs or actual LlamaFarm updates.

Yes, all that's a bit hand-wavy, I know. :-) But we do recognize the problem and have real ideas on solutions. But execution is everything. ;-)

Maybe a better descriptor is "self-sovereign AI?" "Self-hosted AI?"

You could make the same argument for Kubernetes. If you have the cash and the team, why not build it yourself? Most don't have the expertise or the time to find/train the people who do.

People want AI that works out of the box on day one. Not day 100.

LlamaFarm provides an abstraction over most (eventually all) of those pieces. Something that should work out of the box wherever you deploy it but with various knobs to customize as needed (we're working on an agent to help you with this as well).

In your example (alarm monitoring), I think right now you'd still need to write the agent, but you could use LlamaFarm to deploy an LLM that relied on increasingly accurate examples in RAG and very easily adjust your system prompt.

The problem: We were building AI tools and kept falling into the same trap. AI demos die before production. We built a bunch of AI demos but they were impossible to get to production. It would work perfectly on our laptop, but when we deployed it, something broke, and RAG would degrade. If we were running our own model, it would quickly become out of date. The proof-of-concept that impressed the team couldn't handle real-world data.

Our solution: declarative AI-as-code. One YAML defines models, policies, data, evals, and deploy. Instead of one brittle giant, we orchestrate a Mixture of Experts—many small, specialized models you continuously fine-tune from real usage. With RAG for source-grounded answers, systems get cheaper, faster, and auditable.

There’s a short demo here: https://www.youtube.com/watch?v=W7MHGyN0MdQ and a more in-depth one at https://www.youtube.com/watch?v=HNnZ4iaOSJ4.

Ultimately, we want to deliver a single, signed bundle—models + retrieval + database + API + tests—that runs anywhere: cloud, edge, or air-gapped. No glue scripts. No surprise egress bills. Your data stays in your runtime.

We believe that the AI industry is evolving like computing did. Just as we went from mainframes to distributed systems and monolithic apps to microservices, AI is following the same path: models are getting smaller and better. Mixture of Experts is here to stay. Qwen3 is sick. Llama 3.2 runs on phones. Phi-3 fits on edge devices. Domain models beat GPT-5 on specific tasks.

RAG brings specialized data to your model: You don't need a 1T parameter model that "knows everything." You need a smart model that can read your data. Fine-tuning is democratizing: what cost $100k last year now costs $500. Every company will have custom models.

Data gravity is real: Your data wants to stay where it is: on-prem, in your AWS account, on employee laptops.

Bottom line: LlamaFarm turns AI from experiments into repeatable, secure releases, so teams can ship fast.

What we have working today: Full RAG pipeline: 15+ document formats, programmatic extraction (no LLM calls needed), vector-database embedding, universal model layer that runs the same code for 25+ providers, automatic failover, cost-based routing; Truly portable: Identical behavior from laptop → datacenter → cloud; Real deployment: Docker Compose works now with Kubernetes basics and cloud templates on the way.

Check out our readme/quickstart for easy install instructions: https://github.com/llama-farm/llamafarm?tab=readme-ov-file#-...

Or just grab a binary for your platform directly from the latest release: https://github.com/llama-farm/llamafarm/releases/latest

The vision is to be able to run, update, and continuously fine-tune dozens of models across environments with built-in RAG and evaluations, all wrapped in a self-healing runtime. We have an MVP of that today (with a lot more to do!).

We’d love to hear your feedback! Think we’re way off? Spot on? Want us to build something for your specific use case? We’re here for all your comments!

Comments URL: https://news.ycombinator.com/item?id=45504388

Points: 106

# Comments: 71

Most startups are not profitable after just one year and paying cloud bills is a drag on growth.

A graduated drop-off would be better maybe 100% off for year one, then 75% year two, 50% year three, 25% year four, and full price year five. All subject to some sort of annual or total cap, of course.

That's a more realistic picture of what it takes to get off the ground.

Comments URL: https://news.ycombinator.com/item?id=43688980

Points: 2

# Comments: 2