Launched this week
Freu AI
Automate any Mac app with $0 recurring run cost
578 followers
Automate any Mac app with $0 recurring run cost
578 followers
Freu AI is an AI agent for Mac that automates any desktop app with natural language. It “sees” your UI to compile a cross‑app workflow once, then runs it locally via a deterministic DSL—no brittle coordinates/selectors and no recurring token bills. Bonus: we’re open‑sourcing freu-cli (our browser automation engine) today.
Freu AI
Hi Product Hunt! 👋 I'm Charles, founder of Freu AI.
A while back, we teased that we were working on extending our browser automation tech to the entire operating system. Today, we are officially launching Freu AI for Mac—an AI agent that automates any desktop software across your OS using natural language.
The Problem: Vision Agents are Too Expensive & RPA is Too Brittle
We hit a massive wall with current GUI automation. Traditional RPA (AppleScript, rigid X/Y coordinate clickers) breaks the moment you resize a window or an app updates its UI. On the flip side, modern multimodal agents (sending screenshots to cloud LLMs) scale terribly for repetitive tasks.
Right now, most desktop agents operate like interpreters. Every time you ask it to "Extract data from this local PDF and enter it into Excel," it takes a screenshot, sends it to the cloud, reasons about the visual layout, and clicks.
The Traditional Cost: ~10k tokens (Image context) × 5 steps × 10 runs a day = ~500k tokens/day just to navigate the exact same desktop UI, not to mention the unbearable latency.
The Solution: AOT Compilation + Semantic UI (SUI)
Freu AI changes this by introducing Ahead-of-Time (AOT) compilation for OS-level tasks. Instead of the agent analyzing the screen from scratch every single time, you show it the cross-app workflow once.
Freu AI uses a cloud vision-based model to "compile" that session into a deterministic, reusable DSL.
The Freu Cost: You pay the cloud "AI reasoning" token cost once when the agent watches and learns your workflow. But for future runs? The agent simply invokes the pre-compiled DSL command locally. This drops your recurring execution costs to zero and reduces latency from minutes to seconds.
How it works under the hood:
When you record a desktop workflow, our engine doesn't just save a dumb macro. It uses Semantic UI (SUI) to understand the screen:
Perceive: It recognizes buttons, text fields, and icons across any app.
Resolve: It anchors to the semantic meaning of the UI, not rigid coordinates. If Spotify moves their "Play" button, Freu AI still finds it.
Execute: It binds these visual anchor points into our DSL and executes them deterministically.
🎁 The Open-Source Bonus:
While the Mac desktop app is our core product, we are open-sourcing freu-cli today—our underlying DOM-based browser automation engine. You can drop it into your own agents to give them instant "muscle memory" for web tasks. Repo here: https://github.com/freu-ai/freu-cli
🔮 What’s Next: The Local Vision Execution Engine
We are relentlessly upgrading our stack. Very soon, we will launch a capability to run the execution phase using a lightweight, SUI-optimized vision model running entirely locally on your hardware. While we will always rely on powerful cloud LLMs to understand your complex intent during the initial "learning" phase, this upcoming local engine means your day-to-day repetitive executions will cost exactly zero API tokens and keep your real-time screen data 100% private.
We’d love for you to try Freu AI for Mac. I’d love to hear your feedback on our AOT approach or how you're currently handling repetitive cross-app tasks. My co-founders and I will be hanging out in the comments all day to answer your questions! 🚀
Quick question, can it handle when things go wrong mid-workflow? Like if a dialog pops up unexpectedly, does it know how to recover or does it just brick?
All the best team
Freu AI
@boyuan_deng1 Great question! This is the exact edge case that separates real engineering from demo-ware.
Here is the honest current state: If a random dialog pops up, our engine fails gracefully—it pauses safely instead of blindly clicking X/Y coordinates like traditional RPA. To automatically recover from this right now, it has to temporarily route that unexpected frame to a cloud model to understand the dialog (e.g., clicking "Dismiss"). So yes, handling sudden anomalies does incur a small, extra cloud token cost today.
But this is exactly why we are relentlessly building our local vision engine. Very soon, we will ship a lightweight local model that can understand and dismiss these unexpected popups entirely offline. Once that's live, even the anomaly recovery will drop back to exactly zero API cost.
The best part for me is not having the agent re-read the same UI every time. If a workflow is repeated daily, teaching it once and running it locally sounds way more practical and I'd mainly want to see how it handles small layout changes after app updates.
Freu AI
@busra_seker1 Spot on! That recurring cost and latency is exactly why we went the AOT route. 🚀
Regarding layout changes—this is where our Semantic UI (SUI) engine shines. Because the compiled DSL doesn't rely on rigid X/Y coordinates or fragile DOM paths, it anchors to the semantic meaning and visual context of the element. So if an app updates and moves a button slightly to the left, changes its color, or shifts a container, the local vision engine still easily resolves it. (Of course, if they completely redesign the entire app workflow, you'd just do a quick re-compile!).
Would love for you to put it to the test!
Compiling workflows once via a deterministic DSL and skipping LLM calls at runtime is a smart tradeoff. We've hit exactly this problem at RetainSure: brittle selectors break on every UI update and token costs add up fast. This architectural choice solves both at once. How does freu-cli handle mid-execution interrupts? If a modal pops up, does it replan via LLM or does the DSL have recovery logic baked in?
The deterministic DSL angle is what caught my attention. Most Mac automation tools I've tried rely on brittle coordinate clicks that break every time the UI shifts slightly. Compiling to a structured DSL first and then executing locally feels like the right abstraction — curious how the DSL handles conditional branches or waits for async UI states.
Hey Charles, went through Freu's page and the AOT compilation angle for OS-level tasks is honestly the most interesting framing I've read in this space. one thing I wanted to ask, when the vision model captures a workflow once, how do you handle UI drift like updated app versions or moved buttons, is there a re-record flow or some self-healing built in? deterministic DSL is great until the underlying app changes.
mailX by mailwarm
What kinds of apps does it work best with right now, native macOS apps or web apps in the browser?