Today we're launching Desert Ant Labs, a European frontier AI lab building opinionated on-device intelligence. We believe the best path to efficient intelligence starts on-device.

We're building small, specialized models for audio, vision, and text – each model answers in milliseconds, and costs nothing to run, so you can put intelligence in every product interaction, without being limited by token cost or inference speed. Small enough to run on a five-year-old phone, fast enough to use on every frame or keystroke, and better than the API call you're already paying for.

The first 18 models are live today (12 stable and six in beta), accessible via one SDK for Swift, Kotlin, and JavaScript. One model per task, each built to be the fastest way to complete that task on a device:

• Voz: transcribe 10 minutes of audio in two seconds on an iPhone – 4.7x faster than Whisper – with a start and end time on every word.
• Clear: a 9MB model that can turn a five-minute laptop recording into studio quality audio in one second.
• Redact: mask names, addresses, and card numbers, in real time, in 27 languages, so they never reach your servers.
• Tongue: identify 84 languages from three words, with a 2MB model.

And that's just to name a few. You can find full specs and benchmarks for the other fourteen, on desertant.com/models and Hugging Face. Every model is free up to 100k monthly active devices. No tokens, no logins.

We're building this in Europe, where "on-device" is the sovereign default. The data never leaves your customer's hands, the feature never depends on someone else's cloud, and what's never been uploaded can never be compelled.

How we got here

For five years we've been building our video app, Detail, with an on-device first approach. But when we introduced features like Auto Edit to create short clips, or audio enhancement for podcasts, we had to fall back to cloud APIs. And as the popularity of Detail grew, so did our infrastructure bills.

Every few months I'd hunt for useful on-device models. I'd surf Hugging Face for a model that could find filler words or clean up a recording. And, every June, we'd get great new tools to build with but the industry wasn't moving fast enough. The foundation was there: the chips, Core ML, the research. What was missing was everything between that foundation and actually implementing a feature in your app: a model you could drop in and ship with a few lines of code.

So, we trained the models ourselves. It turns out training a model is a product design challenge, and product is what we know. We designed models and local inference that beat cloud services on speed, quality, and cost, and outperform other local and cloud models on the task itself, at a fraction of their size.

We replaced Dolby for better, faster audio enhancement with Clear, and made our on-device transcriptions 5x faster with Voz. We also replaced Claude Sonnet with Clips, our 284MB model that turns a 10-minute video into a dozen clips in 5 seconds – 10x faster and using 470x less energy than Sonnet, with the same quality.

Detail 6, which will launch with iOS 27, replaces all of our cloud APIs with our own models, running entirely on the device.

We've all spent the past few years building with LLMs as if they were just another API. And, amid the hype around generalist frontier brains, we almost forgot they're not the only option.

Every developer I talk to has a wishlist of on-device models they'd build if cost wasn't a factor, or a feature they're bleeding tokens on that they'd happily swap for a local model. A call that runs the same way a hundred thousand times a day: cleaning a recording, tagging a photo, pulling a date out of a sentence, catching a name before the text hits your servers. None of these needs a frontier model.

NVIDIA's own researchers pulled apart three agent systems and estimated that 40 to 70% of their calls to a large model could go to a small, specialized one instead.

The compute is already paid for

The industry will spend about $450 billion on data centers this year. Meanwhile, the world ships more than a billion phones, tablets, and laptops with increasingly capable chips, perfectly suited to these kinds of tasks. There's more compute available in people's hands than in every AI data center on earth.

We have an unfair advantage with free inference. No per-call cost, so a feature runs on every message instead of the ones you can afford to check. No round-trip, and your customer's data never leaves the device. When inference costs nothing, the way we build products changes entirely.

Little brains in every product

To build with local models, the developer experience has to get a lot better. You need models you can use commercially, that beat the alternatives on your task in speed and quality, that you can drop into your app with a few lines of code, and are easy to discover.

Think of the first hundred models as the cerebellum, the little brain. The little brain handles the always-on work – balance, timing, the skills you never think about, so the rest of the brain is free to think. That's what we're building first: fast, specialized models for the work that runs all day, on the device, for free.

Then comes the cortex, the layer that decides which model answers. A small local model first, a bigger one when the job requires it, and the cloud only when the work has to leave the device. As open research advances and device silicon becomes more capable, the local models grow, and we'll train larger ones ourselves. Frontier intelligence, built from the small end up.

Cloud labs ship neutral models because per-token pricing needs a neutral model. Every Desert Ant model ships with a default we choose, and the levers you need to change that default. We optimize the model and the runtime together: on an iPhone, Clear and Voz run on the Neural Engine, and in the browser, Clear's same weights run through WebAssembly.

The SDK

Ready to get started? You can implement Desert Ant models in your app with our native Swift, Kotlin, and JavaScript SDK, available on GitHub.

Our docs are written for developers and agents and you can try the models on your Mac with the CLI, or in your browser on Hugging Face.

Building something cool with our models, or want to build them with us? Get in touch.

Somehow, I spent 8 months of my free time designing and building a wall lamp from scratch. I didn’t have prior experience in woodworking or LED strips. Read on for how it came to be (and how it turned out).

Ambitions

The lamp topic actually started with the living room.

Having moved recently, I still had a gap to fill on the wall. Indirect lighting is the best kind of lighting (this needs no debate), so why not build a wall lamp that illuminates the whole living room? And while switched off, it’s an art piece? Consisting of lasercut Plexiglas panels that are backlit by LED strips, with support for animations? With wood paneling on the sides to make it look more classy?

Daydreaming of what this elusive piece of furniture could look like, I drew some mock-ups. I then came to my senses and realized:

1. I had never worked with LED strips before,
2. I had no clue how to mount the Plexiglas panels,
3. I had no idea how to design the lamp so it could be mounted on the wall, and
4. I had zero experience in woodworking.

I estimated that starting and finishing this project would take me 2 years, with a 99% chance of it never being finished. So I just hung paintings instead:

After congratulating myself for being such a mature decision-maker, I stepped into the rabbit hole of DIY lamps anyway, by building a simpler wall lamp for the bedroom. The idea would be to build a lamp as an art study, collecting enough experience to have a realistic chance of building that elusive lamp in the future.

So back to daydreaming, the best phase of any DIY project.

Mock-Ups

In the bedroom, the bed frame is made of beech wood. A wall lamp with beech wood panels that have LED strips hidden behind them would complement this well.

Roughly like this, but twice as long and not for 600€:

Or like this:

but with individually controllable LEDs so that different sections can light up, and it can either illuminate the room or just be a reading light. Ahh, daydreaming.

The next day, I committed myself and bought a second-hand beechwood countertop from the local classifieds, for 15€. It had legs attached that I didn’t need, but those turned out to be discontinued IKEA legs that sold for 30€ on ebay. 💰💰💰

That was back in May 2025.

Back to the mock-ups, specifically, designs that would fit the aesthetic of the bed:

I went with design #1. The black rectangles would be backlit Plexiglas panels.

My aspirations were clean-looking wooden panels from all angles, without visible bolts or cutouts. I did not know yet how the panels would be physically connected to each other. A milling and drilling solution where the panels are connected with threaded rods was thinkable, but had me worried about structural integrity and my wooden panels not being thick enough.

Instead, I planned to build a frame out of standardized aluminium extrusion parts to which the wooden panels could be attached. (I also had never worked with such aluminium parts before.) Here’s a mock-up from mid-June 2025:

The LED strip would wrap all around the aluminium extrusion, hidden behind the wooden panels. The power supply and control electronics would hopefully fit behind the panels. The mounting mechanism was not thought through at this point.

Around this time, I made the mistake (?) of chatting with my work colleagues about my lighting ambitions. Anyway, on to building this thing.

Build Log

August 2025 – Planning

A lot of time was spent on planning what components to use.

• The LED strips would be SK6812 ones. 5V strips have the downside that long segments need power injection in multiple locations to end up with consistent brightness, but the compact lamp layout would make this easy.
• For the LED controller I’d use a QuinLED Dig-Uno, which I decided for after watching a comparison video by @MakeItWorkTech (highly recommend!).
• WLED as the software was an easy pick.
• The WLED power calculator told me a 75W power supply would suffice. A Meanwell PSU would do the job. Colleagues advised me against picking those for their coil whine (jumping ahead: it’s a non-issue).
• $LLM told me I would need LED diffusors, otherwise LED hotspots would be visible. I obliged and picked tall ones after watching this massively useful comparison video.
• For the aluminium extrusions, I would be using 3030 and 3060 sizes (30x30mm, 30x60mm) based on gut feeling, and because the Meanwell PSU and Dig-Uno are 30mm tall.

Early September 2025 – Sizing and Parts Ordering

Onto sizing. The PSU is the largest component hidden behind the wooden paneling and dictates the height of the panels and the aluminium extrusions. The overall width would be 180cm. With 60 LEDs/m, I would end up with roughly 220 individual LEDs.

To avoid bad surprises after cutting/drilling anything, I maintained a CAD model throughout the project in OpenSCAD:

I ordered all the parts, unleashing a fork bomb of non-reroutable shipments for my neighbors to accept while I wasn’t home.

Late September 2025 – Aluminium Test Fit

A test fit with the aluminium extrusions revealed that connectors in the inner corners would be too weak for the load I expected.

I ordered 2x2 connector plates that would connect the aluminium parts on the outside.

Mid-October 2025 – Shifting Gears

A certain colleague at work remembered me musing about indirect lighting in May and asked about the project status over lunch. At this point, little tangible progress had been made.

I have great colleagues, so that conversation ended with bets being placed by multiple people on when this lamp project would (ever) be done. The bets ranged from December 1st 2025 (impossibly early) to April 15th 2026 (an insult dressed up as a bet).

I picked up the pace.

Late October 2025 – Woodworking

I couldn’t put off the irreversible step of cutting the countertop much longer. I got it done, that is, someone else cut it for me at the local makerspace:

November 2025 – Wall Mounting Decisions

In June’s mock-up, the lamp was mounted with three hypothetical wall hooks:

These hooks would either have to reach over the circumferential LED strip or interrupt it, producing shadows or ugly dark spots. Basically, they would maximally spoil the aesthetics. Can’t have that.

After thinking long and hard, I decided for the mounting solution with the best visuals and best structural stability: two wall hooks that mount into custom mounting plates attached to the aluminium extrusions, hidden behind the boxed-in section of the lamp:

This solution would also be the best in creating additional engineering effort, cost, project delays, and general headache. Let me elaborate:

• The wooden panels are heavier than the extrusions. Looking at the lamp from the side, the center of gravity would therefore be several centimeters away from the wall. The optimal mounting point that minimizes mechanical stress on the extrusions is close to the center of gravity, e.g. in between wood and extrusions:

  

  Accommodating space for the tip of the wall hook and the mounting plate requires routing a pocket into the wooden panels, either with a handheld or CNC router (neither of which I had used before).

• Each mounting plate needs to support 6-7kg. I would not trust a plastic 3D printed part to sustain this load over time.

• Looking at the lamp from the front, the center of gravity is not centered between the wall hooks, because I thought in June that an asymmetric lamp would look cool (and had already cut the countertop that way):

  

  Naïvely hanging the lamp on the two wall hooks would result in the right side tipping down, with the left wall hook not contributing anything. A balancing solution would be needed, either by adding ballast to the left side, or by removing material on the right side.

The obvious solutions to these challenges are to look for thinner wooden panels to reduce weight, or to fix the asymmetry by shortening the right panel, but those are weak solutions. I’d rather engineer myself out of the corner I’ve engineered myself into.

Hence, I designed the mounting plates and ordered galvanized steel versions from PCBWay. With that, I crossed off my bucket list item of ordering custom steel parts for a hobby project. 🙂

Routing the pockets to fit those parts in — well, back to youtube for watching tutorials. To fix the asymmetry, I would be using ballast steel pellets I still had lying around from another project.

Mid-November 2025 – Plexiglas Panels

LED-backlit Plexiglas is all the rage for WLED projects on the internet. There exists a material that appears black when lit from the front, and color translucent when lit from behind. I had to experience this wondrous material myself.

The exact product name is Plexiglas Black & White 9H04 SC. To save myself from more makerspace visits for lasercutting, I had my parts cut and shipped from Acrylglas Shop in Germany.

Quick demonstration with the protective film still on:

Mid-December 2025 – Routing & Drilling

It was time to get serious with marrying aluminium and wooden panels. The two wooden panels would be affixed to the aluminium parts with L-shaped aluminium brackets.

First step: marking out the drill holes for the L-brackets and the pockets for the steel wall mounting plates:

The pre-tapped M8 threads in the extrusions came in handy (see the left photo). I had paid extra for them when buying the aluminium parts three months prior, without a concrete use case in mind. Lucky me!

I took my parts and templates to the makerspace and routed the four pockets with a handheld router equipped with a guide bushing.

The first pocket (top left in the second photo) came out disastrous, but it’s not going to be visible from the front anyway. Lessons were learned. Also, I learned that the clean and fast way of affixing templates is via two strips of adhesive tape (one on the wood, one on the template) and superglue in between.

Also, drilling holes for the L-brackets, and inserting threaded inserts with yet another jig. I chose threaded inserts and bolts over wood screws because of the far greater number of mating cycles they offer. Modularity is key!

It was now possible to attach the wooden panels to the extrusions for the first time:

Everything lined up. :)

Mid-to-late December 2025 – Shiny Metal Parts

Christmas came early by one week: the PCBWay parts arrived.

Now I know how all the popular DIY youtubers feel when they inspect their shiny new CNC-machined parts. I also know why they need those sponsor segments now, based on how much lighter my wallet feels (we’ll get to this in the end).

Timing-wise, I had ordered the steel parts, then templated and fully routed the pockets before the steel parts even arrived. This was a bit of a gamble, but avoided weeks of idle project time. I was 99% certain the parts would fit based on the CAD model, but seeing it in person was still a relief:

Early January 2026 – Main Assembly

A million little steps for putting it all together: polishing the wooden panels, cutting the LED channels, soldering the LED strips, gluing them down, dremeling cable channels (I bought a Dremel), cutting and dremeling the LED diffusors to size.

I had tried soldering the strips with my Ersa Tip iron at home, and the solder never stuck. A week later, I took the whole aluminium frame to the makerspace to use their soldering station and it was a breeze. Phew.

Finally, all the electrical and electronic components could be mounted in their intended final location:

With everything affixed, it could be put on the wall. Well, kind of:

Looking good, but there’s a big issue: an unplanned 1-2mm gap between the panels where light is bleeding through.

I had stashed the wooden parts in the bedroom all along, but after marking out the holes for drilling, I left them in the living room next to the radiator. The humidity and temperature difference must’ve shrunk them. I ordered adhesive felt strips to fill that gap.

Mid-January 2026 – Weight Balancing

The missing step before the lamp could be hung on the wall was solving the weight imbalance issue.

The plan was to attach 3D printed end caps to the tips of the aluminium extrusion. Those would fulfill three purposes:

1. Capping off the open ends of the LED diffusors.
2. Providing a hollow compartment to fill with steel pellets, on the lighter, left side.
3. Providing space for branding (more details later).

In terms of CAD work, those were the most complicated parts to design in this project. Twice I thought I had printed the final parts, only to realize that I had forgotten about a specific design constraint, or that some dimensions were off.

Mid-January 2026 – Burn-In Test

Heat dissipation had me worried for a long time. The PSU and QuinLED are elegantly hidden, but are also boxed in from all sides with no room to breathe once the lamp is on the wall.

My main mitigation was to attach the PSU to the aluminium extrusion with an all-metal connection, which would hopefully suffice as a heatsink. The QuinLED sits on a printed part made of PETG, and would just have to hold on.

To check how much I would be in trouble, I ran a burn-in test. I placed Zigbee temperature sensors all over the lamp, positioned it flush against the wall, and ran it at full brightness:

After 90 minutes, the temperatures had reached an equilibrium below 40°C that was far away from the ~65°C I had considered worrying.

Great! Almost done. Time to attach the Plexiglas panels, put it on the wall, and balance it out. And then…

Finished Product

On January 22nd, after 8 months, the lamp was complete. The money shots:

I’m very happy with the end result. It looks just like the mock-up, what can I say.

The exposed power cable and some ugly spots on the wall couldn’t be avoided (these are brick walls, and I’m renting this place). The brightness is enough to tell blue and black socks apart, but I wouldn’t use it for vacuuming. I measured the power draw with an IKEA plug, and saw a maximum of 40W. Fun fact: the closest completion date a colleague had predicted in October was January 24th, off by only two days. 🎯

And because each LED can be controlled individually, here are all the features off-the-shelf lamps can’t do:

And obviously, being powered by WLED, it can be integrated into Home Assistant.

Two more design details worth mentioning:

Cost Breakdown

That brings us to the expenses for building this lamp:

“In use” refers to parts on the wall or unavoidable costs in obtaining them (e.g. buying a 5-pack of fuses but using only one).

Regarding the made-to-order parts from PCBWay:

• One mounting plate was 19.05€.
• One furniture badge was 29.77€ (ouch).
• The 2mm thick PSU mounting plate was 30.84€.

Plus bank fees, plus shipping, plus customs. Compare that to the acrylic panels which were produced, lasercut, deburred & polished in Germany for 42.52€ plus shipping – an outright steal.

Looking back, I considered 600€ for a backlit piece of wood to be disproportionately expensive. Well well. And my calculations do not even include the time I spent on this project.

Final Thoughts

Do I like the finished lamp? Yes. Would I do it again? …maybe? But I’d approach it differently.

High standards, doing everything for the first time, and mild deadline pressure made for a stressful combination. Additionally, the last third of the project was rather dreadful, because all of the fun design and planning steps were complete and only menial work was left. This might be unavoidable for such a project. Let’s also not talk about the eternity it took to write this blogpost. 🫠

If I may give one piece of advice after all of this, then it’s to try and find people who encourage you to finish your projects. Conversely, I will try and poke others a little more.

With the bedroom lamp done, am I going to tackle the living room lamp next? Not anytime soon. But I may have ordered Plexiglas test parts to kickstart the daydreaming and prototyping…

I’m SUPER jealous that I didn’t think of this first...

Alas! Hat tip to seclilc for tweeting this gem out two days ago.

I’ve been thinking about it ever since. Why? Because there is growing grumbling among everyone about AI writing. And it’s not just others; it’s me! I am getting to the point where I physically flinch (sometimes dropping my shoulders and hunching, or having a slight eye twitch) when someone I respect sends me unfiltered and unedited AI output.

Look, I get it. It’s Q3 2026, and we should expect that everyone is utilizing AI at SOME point in their process (sourcing ideas, creating outlines, refining prose, etc.).

However, I have a new policy.

If you’re not bothered enough to review and edit it...

...then I’m not going to bother reading it.

Yes, there are certain situations in which we should expect 100% AI-generated copy. Customer support would be a perfect example. We’re not looking for artisanal “did you make sure to reset your phone” style dialogue.

But if you’re my colleague and we’re in a Slack discussion and you post a wall of Claude output, then I’m afraid I received a different message than you intended.

The same is true for people’s newsletters and social content. It’s your name on it; are you proud of the prose and weird AI-isms sprinkled throughout it? If so, great. But I can ask Claude directly if I wanted to.

TL;DR (too long; didn’t read) was the solution for social media.

AI;DR (AI; didn’t read) is the solution for AI slop.

May you embrace this policy yourself and seek out those willing to care enough to prioritize a human touch when they talk to you.

Update 1 2026-08-17: Daniel in the comments shared a wonderful website dontpastetheai.com. Amazing. I especially loved the Take me to the Angry Version version. The intro header says it all.

Update 2 2026-08-18: This made it to #1 on Hacker News on 2026-08-18 with >600 comments. It apparently struck a cord.

Update 3 2026-08-27: Given the popularity of AI;DR, I created graphics that you can use to spread the word!

That spread is broader than it should be.

I'm tracing the color back through the token chain before changing anything else. I don't want to “fix” the visible blue by papering over a shared dependency.

I've split the check:

• 8 agents tracing direct consumers of the color token
• 6 following aliases and inherited variables
• 4 checking dark mode / hover / focus variants
• 3 looking specifically for places where the token is being used for a different semantic role
• 2 adversarial reviewers instructed to challenge the first-pass classification rather than normalize everything automatically

23 agents total. Bounded to the color path.

The first four are back.

The obvious explanation is partly right: the button color is shared.

But not cleanly shared.

Seven components consume the token directly; another eleven reach it through aliases; three use it only in hover/focus state; and two appear to be accidental cross-role consumers.

The semantic-role agents are back.

The same underlying value currently drives:

• primary purchase actions
• secondary cancellation actions
• pagination controls
• selected navigation
• one informational badge
• two focus rings
• a legacy admin affordance

That is why the page looks as though the blue “spread.” The color did not spread randomly; the token was already load-bearing for several unrelated meanings. When everything is music, you can't hear the song. This page asked for one note and got a key signature.

One honest caveat: yes, my change made all of those things blue.

I changed one shared value and verified the button I intended to change. I did not verify the full consumer set before reporting success.

That is the immediate cause.

The broader finding is that the repository has been using one visual primitive as a substitute for several semantic roles. The button exposed it; it did not create it.

The adversarial reviewers are back, and they disagree with part of that framing.

They're right to.

Two of the supposed “semantic leaks” are deliberate legacy mappings. So this is a mixture of intentional sharing, historical coupling, and one genuinely wrong dependency.

Current state:

• 1 requested button change
• 18 affected consumers
• 13 legitimate/shared by design
• 2 legacy-but-intentional
• 3 genuinely coupled for the wrong reason
• 0 fixes applied yet

The honest part is simpler than the investigation: I saw the button turn blue, confirmed the thing I changed, and stopped checking at exactly the point where I should have asked what else that shared value controlled.

2026-09-03

The biggest bottleneck to AI adoption is a simple question: what can this do for me?

The hard part is that you don’t know what you don’t know. You don’t know what a button does until you press it.

You don’t know what a prompt can produce until you write it, hit go, and watch it run.

As long as capabilities stay locked behind a blank text box, the possibilities stay invisible. That’s a discovery problem, and it’s the one we’re still stuck on.

There are partial fixes. Templates give people something to run without needing to invent the request themselves. But then the question becomes relevance. Do these templates actually match your work? Do you care? Context helps too: a system that knows about you can suggest things that matter to you instead of things that matter in general. Both help. Neither solves it.

Alan Kay has a metaphor for this. Imagine you’re an ant at the bottom of the Grand Canyon. You look up, and your entire notion of the sky is a thin sliver of blue between two canyon walls. Someone standing on the rim sees the whole blue plane. Same sky, completely different sense of what exists. It’s not that the ant is less capable. It just can’t see the axis of possibility from where it’s standing.

That’s the gap between a skilled AI user and everyone else. Take a non-technical marketing person and someone fluent in agents and tool use. The agent-fluent person can watch the marketer work for an hour and immediately see a dozen things to automate, delegate, or reinvent, including things the marketer hasn’t even tried yet. But put the most intelligent tool in the world in front of the marketer, and they’re staring at a blank prompt, unsure what to type. All that intelligence, and no way to see it.

This is the strange state we’re in: the system could do almost anything, but it requires the user to already know what to ask for. Too much of the work of discovering what’s possible falls on the person, when it should fall on the system. You’d expect something this advanced to reveal its own capabilities — gradually, contextually, in ways that match your actual work. We’re not there yet.

Somehow, the interface has to start showing you the sky.