A home camera does not need a cloud model to decide whether a garage door is open. In one 280-image household test, a 3B local vision-language model reached 94.3% zero-shot accuracy on that binary question. The same model's recall fell to 66.2% on a 13-class detection task, with a 47% false-positive rate on empty scenes. The lesson is architectural: keep narrow perception local, escalate only structured events, and never let one uncalibrated model control the house.
Evidence reviewed: 18 August 2026. The 280-image results are from one household test without a public image set or reproduction package; they are not a general security-camera benchmark.
Reading time: 8 minutes · About 1,600 words
TL;DR
- A local VLM can answer a narrow household question without sending images off-device. It should not be treated as a general object detector merely because the binary task works.
- The stable architecture is camera → local perception → structured event → policy router → optional cloud reasoning → reversible action gate.
- Raw images remain local by default. Cloud services receive the minimum event fields required for reasoning, not a caption containing every visible detail.
- Natural-language confidence is not calibrated probability. Use temporal agreement, deterministic sensors, task-specific detectors, repeated sampling, and human confirmation.
- Evaluate false negatives and false positives by action cost. A notification can tolerate more errors than unlocking a door or disabling an alarm.
What the garage test establishes
Yage tested Liquid AI's LFM2.5-VL-3B on 280 images from a home garage camera. A human labeled every frame as open or closed: any visible opening counted as open, and only a fully closed door counted as closed. The model had not seen garage-specific examples.
For that single zero-shot question, it achieved 94.3% accuracy and 92.6% recall for the open class. Local perception took about 1.5 seconds in the reported setup. The result is useful because the label is operationally clear and the failure cost can be defined.
The same test also reports the boundary. When the task expanded to detecting people, cars, and other objects across 13 classes, recall fell to 66.2%. Empty scenes produced a 47% false-positive rate.
Those numbers came from the same tester and no public dataset, hardware specification, confusion matrix, or runnable evaluation package accompanies the article. They should guide a design hypothesis, not certify a product. The strong result says a compact general VLM can handle one narrow scene question. The weak result says task scope matters more than the model label.
What LFM2.5-VL-3B is designed to do
Liquid AI released LFM2.5-VL-3B on 12 August 2026. It has 3.1 billion parameters, combines an LFM2.5 language backbone with a SigLIP2 vision encoder, and answers directly without a long reasoning mode. Liquid positions it for low-latency edge vision, screen understanding, grounding, OCR, and tool use.
The vendor reports roughly 3 GB of memory use, 228 output tokens per second on an Apple M5 Max, 116 TPS on an AMD Ryzen AI Max+ 395, and 20 TPS on a Galaxy S26 Ultra. Its reported RefCOCO score is 87.9 and ScreenSpot-v2 desktop score is 78.7.
These are vendor benchmarks. They show deployment feasibility and intended capabilities, not the accuracy of a camera in a particular home. Lighting, camera angle, infrared mode, seasonal changes, occlusion, and household objects can shift the distribution dramatically.
The model is a component. The home automation system is the infrastructure around it.
The architecture
camera / sensor
↓
local trigger and frame sampler
↓
local VLM or task-specific detector
↓
minimal structured event + local evidence reference
↓
policy and confidence router
├─ ignore / wait for another frame
├─ local notification
├─ cloud reasoning on structured text
└─ human confirmation
↓
reversible action gate
↓
Home Assistant / device API + audit log
Each boundary has one job. The camera observes. The local model converts pixels into a narrow claim. The router decides whether that claim has enough evidence for the next step. A cloud model can combine household context, schedules, weather, or user preferences. The action gate enforces what may actually change.
This separation also makes the system debuggable. A bad outcome can be traced to perception, event normalization, reasoning, policy, or execution instead of being attributed to a single opaque multimodal answer.
Send events, not scenes
Keeping inference local does not automatically preserve privacy. A caption can expose names, license plates, medical equipment, routines, or the contents of a room even when the JPEG stays home.
Define an event schema that contains only what the downstream decision requires:
{
"event": "garage_door_open",
"camera_id": "garage-east",
"observed_at": "2026-08-18T09:42:15+08:00",
"temporal_votes": ["open", "open", "open"],
"sensor_corroboration": "reed_switch_unknown",
"evidence_ref": "local://events/8f31...",
"privacy_class": "household-routine",
"allowed_cloud_fields": ["event", "observed_at"]
}
The local evidence reference can point to an encrypted image with a short retention period. The cloud receives the event and timestamp only if that is enough to decide whether to notify someone. Uploading the image should be a distinct, policy-controlled escalation.
This follows the same verifiable on-device principle used in privacy-preserving scam detection: local processing is valuable when the evidence boundary is explicit and auditable.
Confidence must come from the system
LFM2.5-VL-3B emits language, not a calibrated probability for the household event. Asking it to say 92% confident creates a number without demonstrated calibration.
A practical router can combine independent signals:
- Temporal agreement. Require the same classification across three frames separated by a few seconds.
- Deterministic sensors. Compare vision with a magnetic reed switch, motion sensor, lock state, or device telemetry.
- Task-specific models. Use a small classifier or detector for high-frequency known objects; reserve the VLM for open vocabulary or exception descriptions.
- Prompt and sample stability. Repeat the decision with a fixed alternate prompt or seed policy and flag disagreement.
- Distribution checks. Detect darkness, blur, obstruction, camera movement, or a scene unlike the validation set.
- Human confirmation. Ask for confirmation before an irreversible or safety-critical action.
The router does not need one universal score. It needs evidence rules matched to action risk.
Separate notification from control
The same perception error has different consequences depending on the action.
| Action | Tolerable evidence | Failure response |
|---|---|---|
| Add a local timeline entry | One frame | Mark uncertain; no alert |
| Send a phone notification | Multi-frame agreement | Include snapshot locally or offer review |
| Turn on a light | Vision plus motion | Auto-revert after timeout |
| Close a garage door | Vision plus door sensor and obstruction check | Require confirmation if sensors disagree |
| Unlock an exterior door | Strong identity and explicit authorization | Do not rely on a general VLM |
Design the system so a model recommendation cannot bypass the action gate. The cloud model can say what it thinks should happen; a deterministic policy decides whether that action is allowed, reversible, and sufficiently evidenced.
A privacy boundary with four controls
Data minimization
Capture only event-triggered frames where possible. Crop regions of interest locally. Do not send background details when a boolean state is enough.
Retention
Separate transient inference buffers from retained evidence. Delete ordinary negatives quickly. Retain an encrypted incident frame only when a notification, dispute, or debugging rule requires it.
Access
Use distinct service identities for cameras, local inference, cloud routing, and device control. The perception process should not hold credentials that can unlock doors.
Observability
Log model version, prompt version, device, latency, normalized event, routing reason, action, and later human correction. Avoid logging raw images or unrestricted captions by default.
Privacy and observability can coexist when the log records decisions and provenance rather than copying household content.
Build a household evaluation set
Generic VLM benchmarks cannot answer whether a system is safe in one home. Build a frozen local set that covers:
- day, night, infrared, glare, and weather;
- partial opening and closing transitions;
- cars, people, pets, deliveries, and empty scenes;
- camera obstruction, blur, network loss, and moved viewpoints;
- rare states with high action cost.
Measure the full event pipeline:
- precision and recall for each operational event;
- false alerts per day, not only percentage accuracy;
- missed dangerous events;
- local latency and cloud escalation latency;
- percentage of frames leaving the device;
- cloud calls and cost per accepted event;
- disagreement and human correction rates;
- recovery after sensor, network, or model failure.
The 280-image garage set is a useful start because it freezes one real task. Production readiness requires adding the failures the household actually experiences.
When cloud reasoning helps
Cloud reasoning is useful when an event requires broader context:
- The garage is open, nobody is home, rain is approaching, and the car is inside.
- A person is present, but the household calendar says a contractor is expected.
- A package remains outside after sunset and no one has acknowledged the notification.
- Repeated ambiguous events indicate the camera or door sensor may need maintenance.
The cloud should receive a bounded decision problem and allowed actions. It should not become the default destination for every frame or the direct controller for every device.
When the cloud is unavailable, low-risk local automations can continue under deterministic rules. Ambiguous or high-risk events should remain pending, notify locally, or ask for human review. Network failure must not silently route household data to an unapproved provider or weaken the action gate.
Native multimodal cloud models may become cheaper and faster. The local/cloud separation remains useful because latency, privacy, bandwidth, failure isolation, and action authority are system properties.
FAQ
Can a 3B local VLM replace a security-camera detector?
Not generally. The household test was strong for one binary door-state question and weak for 13-class detection. Use task-specific detectors where their label set is known and validated.
Does keeping the image local guarantee privacy?
No. Captions, event logs, embeddings, timestamps, and household routines can also be sensitive. Minimize both pixels and derived data.
How should the system decide when to call the cloud?
Use explicit rules based on event type, temporal agreement, sensor corroboration, distribution shift, action risk, and whether cloud context can materially change the decision.
Should the VLM's self-reported confidence be trusted?
No. Treat it as another model output until it has been calibrated on the household task. Independent signals and observed error rates are stronger routing inputs.
Which actions should remain human-approved?
Exterior access, alarm changes, financial actions, safety systems, and any action with difficult rollback should require deterministic safeguards and explicit authorization.