Vision language models for CCTV are a description and search engine, not a real-time alerter. The cost math is what tells you that, before anyone gets to talk about accuracy.

The thesis: a VLM is too expensive to be the eyes and too good to waste on detection

The marketing pages on this topic talk about VLMs as if they replace the detector. They do not. They sit one layer behind the detector and they do a different job. The detector decides whether anything is in the frame at all. The VLM decides what the something means once you have already paid for it to be there. Confusing those two roles is what breaks the math.

Once the roles are kept apart, the architecture writes itself. A small detector runs on every frame, locally, on an edge accelerator. A dwell timer holds the candidate track until it has earned an escalation. A 5-frame burst, stitched into one image, goes to the VLM with a class-specific prompt and comes back as JSON. A separate text index stores the VLM’s one-line description so the property manager can search the footage in English later. None of those layers is interchangeable. Each one is doing the job the layer above it cannot afford to do at the rate the layer below it produces work.

The arithmetic that decides everything else

A 1024 by 768 image is on the order of 1,048 image tokens to a frontier VLM. A typical 25-camera property recording at 15 frames per second produces 25 multiplied by 15 multiplied by 86,400, which is 32,400,000 frames per day. Multiply that by image tokens per frame and the per-day input-token volume sits in the tens of billions. At Claude Sonnet input pricing of about three dollars per million input tokens, the naive daily cost is in the high five figures per property. Even with batching, prompt caching, and aggressive resolution downsampling, the regime does not move enough to matter.

The number that actually has to drop is not the per-token price. It is the number of frames that reach the model. The detector throws away the frames where nothing relevant is happening. The dwell timer throws away the candidates that did not stay long enough to be worth a sentence. By the time a frame burst is on its way to the VLM, the gate has already discarded more than 99.99 percent of the day’s frames. That is the only architecture where the math works at the per-property prices an installed multifamily operator is willing to pay.

On a Cyrano unit, that math lands at roughly 250 candidate events per day across 25 cameras. Each one becomes a single multimodal request carrying a 5-frame stitched image, a short metadata block, and a class-specific prompt. The combined daily token volume is on the order of 1.31 million image tokens plus a thousand or so text tokens. The cost is in the low single digits of cents per property per day, or about $0 /mo per property in the steady state.

What the VLM is actually for: the sentence and the index

Once a candidate event has cleared the gate, the VLM does two things, and the rest of the system is built around its outputs.

The first output is a strict-JSON verdict. Three fields: threat_level (LOW or HIGH), one_line_summary (an English sentence the operator can read), and policy_match (whether the activity breaks a posted property rule). That JSON is what the dispatcher reads to decide whether to send an SMS, place an outbound call, or just write the event to the morning digest. The reason this field set is small is that the operator’s phone is the slowest part of the chain; the JSON has to be parseable in microseconds and routable in single-digit milliseconds. Anything richer than three fields is wasted on the dispatch path.

The second output is the natural-language description that goes into the index. This is the use case nobody on the marketing pages writes about, and it is the one that justifies the model in production. The description is a sentence in plain English, attached to the event, persisted to disk. Six months later, when a tenant asks why a package went missing on a Tuesday afternoon, the property manager types “person in the lobby with a delivery uniform last Tuesday between 2 and 4 pm” and the index returns the matching events. The retrieval is a text search over sentences, not a vision inference over frames. The VLM was paid for once, at the moment of the event. After that the index is plain text.

That is the operational economics of the search use case: the cost is bounded by the number of events, not the number of queries. A property that has 250 events a day pays for 250 VLM calls a day. The same property can search its index 10,000 times without paying for a single additional model call. That is the regime where putting a VLM in the surveillance stack pays for itself, and it has nothing to do with watching the live feed.

Local VLM versus cloud VLM, decided by one integer

Inside the cascade, there is a second split that the marketing pages collapse into a single “the VLM.” In production there are usually two: a small open-source VLM on the device (LLaVA-class, Qwen-VL-class, or a quantized derivative of one of them), and a frontier hosted VLM on a remote API. The local model writes the routine sentences for free. The hosted model writes the high-stakes ones for cents.

The handoff is governed by a single threshold. The local model returns a verdict and a confidence score. If the score is above the threshold, the verdict is final and the event is dispatched. If the score is below, or the event class is one of the small set that always escalates (tailgate, force entry, after-hours pre-action zone entry), the same 5-frame burst is also sent to the hosted model and the verdict is the union of the two. That threshold is one integer in a config file. Tuning it is the lever that moves the monthly cloud bill up and down without changing any code.

This is the part of the architecture that pays the dividend on the choice of a small local model. The 80 percent of events that are unambiguous (a person in a parking lot is a person in a parking lot) are described locally at zero per-event cloud cost. The 20 percent that are ambiguous or high-stakes are described by the model that can actually read intent. The combined per-property cost is dominated by the share of escalations, not the total event count, which is the regime where the architecture is tunable to the operator’s budget rather than fixed by the camera count.

Where current VLMs still get it wrong

An evaluation of vision-LLMs on UCF-Crime and RWF-2000, published on arXiv in October 2025 (paper 2510.23190), reports that frontier VLMs do well on simple, spatially salient events and struggle with noisy spatial cues, identity obfuscation, and dense crowd scenes. They also degrade when full-body GAN privacy filters are applied, because the transform breaks the spatial statistics the model was pre-trained on. The paper’s conclusion is that VLMs are not a drop-in replacement for a structured surveillance pipeline; they are most useful when the inputs have already been narrowed to a single track and a small temporal window.

That conclusion lines up exactly with what the cost arithmetic forces you to build anyway. The detector and the dwell timer narrow the input to a single track and a 5-frame window before the VLM ever sees the event. The model is then operating in the regime where the published papers say it is reliable, not the regime where it fails. The cost gate and the accuracy gate point in the same direction; both want a cheap front end and a smart back end, not the other way around.

The mistake on the marketing pages is to imply that a VLM can be the front end. It can, in a lab, on a single feed, for a research demo. On 25 feeds at 15 frames per second across a real property, the same architecture pays a six-figure-per-day model bill and produces results no better than the gated version. Both arguments converge on the cascade.

The counterargument: when the live-feed VLM is actually the right answer

There are three regimes where pointing a VLM at the live feed is defensible. First, post-incident analysis. A single event has already happened, you have a 30-second clip, you want a structured description. There is no rate problem because there is one clip. Send it to a frontier VLM and read the output. The cost is bounded by the analyst’s patience, not by the camera count.

Second, very low frame rate situations. A doorbell that captures one frame per second is a fundamentally different cost regime than a 15-fps property feed. At 1 fps with a single camera, naive every-frame VLM is on the order of dollars per day, not tens of thousands. For a single-door consumer product, the cascade complexity may not be worth the savings.

Third, research and red-team work. Running a VLM continuously over a real feed to study where it fails is a perfectly good use of the model. The output is a research artifact, not a paged operator. Cost per insight is what matters, not cost per property.

None of those is the multifamily-property use case. None of them ships with an SLA an on-call manager has to live with. None of them has an installed DVR fleet on the other side of the equation. The cascade is the answer for the operational case; the live-feed VLM is the answer for the analyst case. Confusing the two is the source of the bad architectures on the market.

What to ask before buying anything that says “VLM-powered surveillance”

Five questions, in order. Each one is answered in seconds by an honest vendor and is a fog of marketing language by a dishonest one.

1. How many frames per day actually reach the VLM on a 25-camera property?The honest answer is in the low hundreds. If the answer is “all of them, we have efficient batching,” ask for the daily cost number and watch the conversation change.
2. What runs on the device, and what runs in the cloud? The detector and the dispatcher have to be on the device or the latency story is fiction. The hosted VLM may live in the cloud; the decision to fire an alert cannot.
3. What does the VLM return and where does the JSON go? Three fields max on the dispatch path. If the API contract is freeform paragraphs, the dispatcher is a regex pile and will break in production.
4. Can a property manager edit the prompt without a platform deploy? The prompt is a policy artifact, not source code. Hardcoded prompts are a ticket-driven deployment surface that no operator wants to touch.
5. Is the natural-language search of footage real, and is it free at query time?If “search” means another VLM call per query, the architecture has not understood why the index exists. The search has to read the persisted sentences, not re-watch the frames.

A vendor whose system passes those five questions has thought about the regime carefully. A vendor whose system fails any of them is selling the marketing-page architecture and will produce the marketing-page bill.

The resolution

Vision language models belong in CCTV pipelines. They do not belong on every frame, and they are not the thing watching the live feed. They are the layer that turns a small number of high-value events into structured verdicts, plain-English descriptions, and a searchable index of the property’s footage. The detector and the dwell timer are what make that economically possible, and the cascade is the only architecture where the per-property costs are within an order of magnitude of what a property operator will actually pay.

The Cyrano version of this is an edge box that plugs into the existing DVR or NVR over HDMI, runs the detector and dwell layer locally, sends a small number of stitched bursts to the VLM with class-specific prompts, and exposes the resulting sentences as a search index the property manager can query in English. Same cameras as last week. Same DVR. Different stack behind it.