How Helen Gets Made A making-of, not the live show Watch her live

Frigate · detector · plain language

You probably do not need a Coral

Every Frigate guide from a few years ago says buy a Coral. Ours runs seven cameras on the graphics unit built into a 2018 desktop CPU, at about 12 ms a look, and it is mostly idle.

The code for the detector we built is on its own page. What follows is the decision.

Helen, a dilute tortoiseshell calico, at the food bowl; the detector that spotted her is the iGPU in an i7-8700
12.4 milliseconds from Frigate's point of view. Under 9 on the iGPU itself. Nothing was bought to get there.

A detector looks at one frame and answers with a class, a score and a box: "cat, 0.83, here". Frigate can run that on several kinds of hardware, and the choice is where new builders spend the most money and the most worry, which is odd, because the whole decision comes down to multiplying two numbers you can read off Frigate's stats page after a day on whatever you already own. The options as they stand in 2026, what we measured on ours, and that arithmetic follow. How we got the Intel iGPU working under WSL2, with the code, is its own page; it is more than most people need.

The four options a home builder has

CPU. Costs nothing, works everywhere, and is the default. Frigate's own docs will tell you it is the slowest option, and it is, but "slow" means tens of milliseconds, not seconds. For two or three cameras at a few frames a second it is fine. Its real cost is that the same cores are decoding your video; on a small machine the two jobs fight.

Intel iGPU through OpenVINO. If your machine has an Intel CPU from roughly 2016 onward, it has a graphics unit inside it that OpenVINO can run detection on. It costs nothing you have not already bought, it runs the same SSDLite model Frigate ships, and it takes the detector load off the CPU cores entirely. This is what we use. Frigate supports it directly on Linux; on Windows under WSL2 it needs the side door described on the next page.

Google Coral (USB or M.2). The classic answer: a small accelerator that runs Frigate's model in a couple of milliseconds. It still works. But the Coral software repositories on GitHub (edgetpu, libedgetpu, pycoral) are archived and read-only, the hardware has been intermittently unavailable for years, and Frigate's community has discussed retiring it from the docs. If you already own one, use it. If you would be buying one today, read Frigate's hardware page for the current word before you do.

Hailo, or a discrete GPU (NVIDIA, AMD, Intel Arc). Real accelerators for real load: dozens of cameras, higher detect frame rates, larger and more accurate models than SSDLite. Worth it when you have that problem, which a cat cam does not.

What we measured

Frigate ran on the CPU of this machine from the day it moved here in August until 2026-08-29. It worked; we did not record a millisecond figure, and we moved off it because detection and decoding were sharing the same six cores and the box had other jobs. On the Intel UHD 630 inside the same i7-8700, through OpenVINO with a half-precision (f16) model:

Intel UHD 630, OpenVINO 2025.3, SSDLite MobileNet v2, f16
MeasurementValue
Inference as the detector process sees itabout 8.5 ms steady, 8 to 13 ms range
Inference as Frigate reports it (inference_speed)12.4 ms, including the trip to and from the container
Inferences since it went live3,291,109 at time of writing
Cameras detecting7, at 640×360 and 2 fps each (eleven defined; three house cameras record only, one is disabled)
Detector busyabout 17 % at the ceiling; less in practice because only frames with motion are sent
Frigate's share of the whole CPU13.6 % for the whole Linux side (Frigate, go2rtc and every decoder) in the 2026-09-03 capture, with decode still on the CPU
Hardware boughtnone
The rule of thumb
# The only arithmetic that matters:
#   sum over cameras of (detect fps)  x  inference_ms   <<  1000

7 cameras x 2 fps = 14 frames/s (the ceiling; motion gating makes it less)
14 x 12.4 ms      = 174 ms of detector time per second  ->  ~17 % busy

# For comparison, the same maths with a slow detector:
14 x 60 ms        = 840 ms per second  ->  nearly saturated; skipped_fps climbs

Take the number Frigate shows you for inference_speed, multiply it by the total detect frames per second across all your cameras, and if the answer is well under a thousand milliseconds you have headroom. Frigate's stats page also shows skipped_fps per camera; if it stays at 0.0, the detector is keeping up, whatever it is.

When a real accelerator is worth it

When the arithmetic above stops working. That happens with a lot of cameras (twenty or more at 5 fps is a hundred frames a second), with a desire for higher detect frame rates (fast-moving objects, a road), or with a bigger model than SSDLite because you need it to tell a fox from a cat at forty feet. Those are all legitimate. They are also all things you can discover from the stats page after running on what you have, rather than guessing before you start.

The decision

Pick your detector
IfThen
You have 1 to 3 cameras and any modern CPUStart on the CPU. Look at inference_speed and skipped_fps after a day.
Your box has an Intel CPU with integrated graphics, on LinuxUse Frigate's built-in OpenVINO detector on device GPU. Free, and it removes the CPU contention.
Same, but you run Frigate on Windows under WSL2Frigate cannot see the iGPU from inside the container. Run the detector out of process: the ZMQ detector.
You already own a CoralUse it. It is still the fastest thing per watt.
You are about to buy a CoralCheck the hardware page first; try the iGPU before you spend.
Twenty-plus cameras, high fps, or a big modelHailo or a discrete GPU. This is the case those exist for.

Whatever you pick, it is one block in the config. Ours is four lines under detectors: on the config page, and changing detectors later is changing those four lines. The machine underneath, including why there is no /dev/dri to give Frigate, is on the WSL2 setup page.