Your scooters run locally. Your AI should too.

Using a giant cloud LLM (or routing it to humans) to check whether a scooter is parked straight is a silly thing for a sustainability-focused industry to do. It's expensive, it's quietly burning carbon, and it makes your riders wait. There's a better way - and it happens to be the greener one.

Let's start with the silly bit.

When a rider finishes a trip, they point their phone at the scooter, snap a photo to prove it's parked properly, and hit submit. That image then travels across a cellular network, lands in a data center, gets queued, gets run through a multi-billion-parameter vision model spun up on a rack of accelerators somewhere, and a verdict travels all the way back.

All of that - the round trip, the GPUs, the storage, the egress bill - to answer a question a competent human answers in half a second: is the scooter visible, upright, and not blocking the footpath?

We've convinced ourselves this is a responsible use for AI, but it's mostly waste, and in an industry that sells itself as the clean alternative to cars, that should bother you.

The micromobility paradox

Every micromobility operator pitches the same story to cities, riders, and investors: we are the sustainable, scalable way to move people through dense urban space. Lower emissions, less congestion, fewer cars.

Then a lot of those same operators verify millions of parking and proof-of-ride photos by shipping every single one to the cloud and throwing a general-purpose model at it. Your product might be green, but your verification stack is not. There are hidden costs in every verification that pings the cloud; nobody puts that on the sustainability slide, but the bytes don't care if you mention them or not.

Here is the uncomfortable math: The IEA projects electricity use from data centers and AI rising from roughly 460 TWh in 2022 to more than 1,000 TWh by 2026. A facility-level US study found data centers already drawing more than 4% of US electricity, 56% of it from fossil fuels, at a carbon intensity 48% above the grid average. Cloud compute is not a free, invisible, infinitely clean resource.

When you scale from 60,000 rides a day to 850,000, the cloud-LLM approach scales your carbon footprint and your bill right along with it - so that scalability actually just ends up being an environmental liability with a growth curve.

The right-sized model is the "AI for good" model

Here's the opinion this whole blog entry is built on: using the biggest possible model for the smallest possible task is not sophisticated. It's lazy, and it's wasteful.

The responsible move - the actual "AI for good" move - is to use the smallest model that solves the problem, run it as close to the data as possible, and never move a byte you don't have to. It means using models that have already been through the process, done the work, and been compressed down for their specific use cases.

You do not need a frontier vision-language model to check a parking photo. You need a purpose-built model that's been trained on exactly that job - right vehicle, good framing, adequate light, not blocking the path - and you need it to run on the phone, in the camera, before anything gets uploaded.

That's what we build. A model around 5MB that runs on the device - including budget Android handsets - and returns a verdict in about 30 milliseconds. On parking-domain tasks it matches a current cloud LLM's accuracy at roughly 44× lower latency, with no per-image cloud bill attached. Juxtapose that with the cloud LLM approach, and you're talking about bringing a bazooka to a knife fight.

Cheaper, because the cloud bill stops growing

Cloud image verification charges you per image - somewhere around $0.001–$0.0015 per call just for inference, before you add storage, egress, and the retries when the network flakes. Multiply that by every ride, every day, forever, and watch it compound.

On-device validation inverts the curve. The decision happens on hardware your rider already paid for. You upload one verified image instead of a stream of candidates, so the cloud cost per ride doesn't climb as you scale - it largely flattens. Validate millions of rides without a cloud bill growing alongside them. For an operator, that's the difference between a cost center that punishes growth and infrastructure that rewards it.

Greener, because the cleanest byte is the one you never send

We're not going to tell you the edge is always greener - it isn't, and vendors who claim otherwise are selling, not measuring. Here's what we will stand behind:

Catching a bad image at the point of capture prevents it from being uploaded, stored, reprocessed, and manually reviewed downstream - and the work you never trigger is the work with zero footprint.

This is exactly how serious software-carbon accounting frameworks like the Green Software Foundation's SCI tell you to think: count the network, storage, and compute you avoid. Edge filtering research backs the mechanism hard - one edge-cloud sensing system cut data transmission by 95% and total system energy by 73% just by classifying near the source instead of shipping everything up.

For a micromobility operator drowning in rider-submitted photos over patchy cellular networks, that's not a rounding error. It's fewer uploads, fewer retries, less storage, less data-center compute - measured as net savings, on a workflow you control. That's a sustainability number you can actually stand behind when you're advocating for cities and municipalities to introduce micromobility options into their current transport schemes and ecosystems.

Better UX, because nobody should wait for a server to end their ride

Think about how Face ID works. You don't take a photo, upload it, wait for a server, and receive a verdict. The camera recognizes the right frame and you're in. It's instant because it's local - the data never leaves the device.

That's the experience riders should get at the end of every trip. With on-device validation, the camera guides them in real time: a little to the left, more light, there - done. The good photo gets captured the first time, the ride ends, they walk away.

The cloud-LLM flow gives you the opposite: capture, spinner, network dependence, a verdict that arrives after the rider has already mentally moved on, and a retry loop when it fails. Latency is where conversion and patience go to die - every extra second of waiting measurably increases drop-off, and mobile users are about twice as sensitive to it.

Here's an example: picture full time at a stadium, or a sold-out show letting out: thousands of people leave the same venue at the same moment and hit the same cell towers, and throughput collapses exactly when the surge of ride endings does - fastest for riders on budget phones. A cloud verdict that took three seconds on a quiet street now just hangs, and the retry loop plays out in a crowd, at night, with a rider who only wants to get home. The on-device check doesn't know the network is melting. It runs on the phone, in the camera, congestion or not - the photo validates, the ride ends, and your rider is moving while everyone around them is still waiting for a congested network call to go through.

Edge-validation doesn't just work for micromobility, either. It works for delivery also. When GoBolt put capture-time validation in their drivers' hands, "did-not-receive" disputes dropped 30% in the first week, around 96% of drivers re-took the photo when prompted in the moment - and crucially, sessions didn't get any slower. Quality is up, and friction gets minimized.

Pick a side

So here's the choice, stated plainly.

You can keep routing every parking photo to a data center, paying per image, growing your carbon footprint in lockstep with your ride count, and making riders wait on a server to finish their trip. You can call that AI.

Or you can run a right-sized model on the device, send only what matters, cut the waste before it's created, and give riders a Face ID-smooth ending. It's cheaper, greener, and easy to use.

Micromobility is supposed to be the efficient choice. Your AI stack should be too.

The cleanest, cheapest, fastest image is the one you validated before it ever left the phone. Stop sending your scooters to the cloud.

Captur builds an on-device real-time Vision Intelligence SDK - a validation layer at the point of capture. We decide whether it's the right photo before it enters any downstream workflow, so operators cut cost, carbon, and rider friction at the same time. Want to see the net-impact numbers on your own workflow? Let's measure it together.