SE Talk Track

This demo exists to make one point concrete: on Cloudflare's Developer Platform, "we want to try a completely different AI use case" is usually a prompt-engineering change, not a re-architecture. Every scenario here — counting objects, watching for a baby's distress, spotting a possible fall, flagging something for an exam proctor, flagging something for safety personnel — calls the exact same Workers AI model with a different question. Same camera capture code, same API route pattern, same billing model. Point this at the audience's own "what if we tried..." idea live and show how little would change.

Demo Steps

1 Start on Object counting — type "people" or "boxes", point the camera at a group of objects, watch the live count update as things move in/out of frame
2 Switch to Baby distress monitor — explain the honest limitation up front (vision-only, no audio) before demoing, since crying is fundamentally an audio signal
3 Switch to Fall detection — point out this is the same "look for X" pattern as the baby monitor, just a different prompt
4 Switch to Exam integrity flag — read the disclaimer banner out loud before tapping "Check this frame". This is the moment to make the responsible-AI point explicit: notice the output is never "cheating detected", only "flagged for review"
5 Switch to Safety flag — same pattern, strongest disclaimer in the demo. Use this to talk about where the line is between a legitimate proof-of-concept and something that needs a validated, specialised model before any real deployment
6 Open the Worker code panel and point out it is under 60 lines for ALL FIVE scenarios combined — that is the actual pitch: the incremental engineering cost of a new AI-powered monitoring idea on this stack is close to zero

Cloudflare Products

Workers AI@cf/moondream/moondream3.1-9B-A2B

"Isn't this just a demo — would a real safety or academic-integrity product actually work this way?" — No, and the demo says so explicitly. The exam-integrity and safety-flag scenarios deliberately never claim a verdict (no "cheating detected", no "weapon detected") — they surface details for a human to check, which is the same pattern responsible commercial products in these spaces use as a starting point before layering in specialised, validated models and human-in-the-loop review. The value of THIS demo is proving how cheaply you can prototype the idea before deciding whether it is worth that investment.

🧭 Retail / Childcare / Elder Care / Education / Safety

Scenario Vision Monitor

One Workers AI vision model, five real-world monitoring scenarios — object counting, baby distress, fall detection, exam integrity, and safety flagging. Swapping scenarios is a prompt change, not new infrastructure.

The Problem

""Every one of these monitoring ideas sounds like a separate product to build — separate models, separate pipelines, separate teams. We want to prove out several before committing engineering budget to any one of them.""

The Outcome

One Workers AI model (moondream3.1-9B-A2B). Five scenarios are five prompts against the same endpoint — no new model, no new pipeline, no new Worker per scenario.

Live demo below

🔢

Scenario Vision Monitor

Workers AI · one model, five scenarios

Type anything to count — "people", "boxes", "red cars" — and Workers AI counts every instance it can see, live.

⚠ Occluded or overlapping objects can be under-counted — this is a live count, not an audited inventory figure.

Count:

🔢

Type anything to count — "people", "boxes", "red cars" — and Workers AI counts every instance it can see, live.

—

Productionising this

What changes when you ship this for real

This is a prompting layer, not a product

Every scenario here is one Workers AI call with a different question — that is the whole point for a proof-of-concept. A real product in any of these categories needs scenario-specific validation, evaluation datasets, and — for the higher-stakes scenarios — a specialised model, not a general-purpose vision-language model.

Human-in-the-loop is not optional for exam/safety scenarios

The flagged_for_review response shape is deliberate — there is no field anywhere that reads as an automated verdict. Any real deployment of the exam-integrity or safety-flag concepts must route every flag to a human, log the decision, and never take automated action (contacting authorities, academic penalties, lockdowns) directly from model output.

Single-frame reasoning is a real limitation, not a demo simplification

Baby distress and fall detection would both benefit enormously from temporal (multi-frame) reasoning — "was this person standing a second ago?" is a much stronger signal than one frame. A production build should analyse a short clip or a sequence of frames, not one snapshot.

Pair with the right complementary signal

Baby monitoring: audio classification for crying is the primary signal, vision is a secondary confirmation. Fall detection: wearable accelerometers are the industry-standard primary signal for exactly this reason.

Rate limiting and cost

The continuous scenarios (counting, baby, fall) poll every 1.5s — same cost profile as the Live Object Detection demo's Smart mode. Add a KV-backed rate limiter per session/IP before any of this goes near production traffic.

Privacy and consent

All five scenarios point a camera at people, several at children or students specifically. A real deployment needs a clear consent/notice framework, data retention limits (this demo stores nothing — every frame is discarded after inference), and likely a legal review before any pilot with real subjects.