Aura

A visual monitor you write in English. Point a camera at something, say what to watch for, say what should happen when it happens. Aura does the rest, in a browser tab, with whatever AI you want behind it.

Try it → · no install, no account, no backend.

What it is

Aura is a webcam monitor whose rules are prompts instead of code. You give it two sentences:

• a mission — what it should be looking for ("a person at the front door", "the dog on the sofa", "the 3D print has come loose from the bed");
• an action — what it should say or send when that happens ("announce that someone is at the door", "roast whoever just walked past, briefly").

Then it watches. Every scan cycle it sends one camera frame to a vision model with the mission prompt. If the model says the thing is happening — and is confident enough — Aura runs the action prompt and delivers the result: spoken aloud, a buzz, a screen flash, a line in the log, an HTTP call to anything you like.

That's the whole idea. Everything else is a knob on top of it.

flowchart LR
    C["camera frame"] --> D["detection call<br/>your mission prompt"]
    D --> Q{"happening?<br/>and confident enough?"}
    Q -- "no" --> W["keep watching"]
    W --> C
    Q -- "yes" --> A["action call<br/>your action prompt"]
    A --> O["speak · vibrate · flash<br/>log · webhook"]
    O --> C

Most cycles stop at "keep watching" — the second call only happens on a real alert.

What people point it at

The same loop, different sentences. A few that work today:

Nothing in the app is specialised for any of these. A "security system" and a robot that insults your hoodie are the same program with different prompts — which is the point, and the reason the mission box is a free-text field and not a dropdown of object classes.

The webhook is where it stops being a toy: any alert can POST a JSON body you define to any URL, so Aura becomes a sensor for whatever you already run — Home Assistant, n8n, ntfy, a Kubernetes job, your own API.

It runs on the phone in your pocket

No extra hardware. No Raspberry Pi, no NVR box, no hub, no dongle, no second device to keep charged. Aura is a web page: open it on the phone, point the phone at the thing, press ARM.

No extra accounts either. Nothing to sign up for, no Aura login, no cloud tenancy — there is no Aura server to have an account on. Pick the in-browser engine and you never enter a key at all; the phone does the thinking.

It uses the cameras the phone already has — front or back, switchable while armed, at whatever capture size you pick. On a laptop it will equally take a USB webcam or a screen share instead. Install it to the home screen and it behaves like an app, offline shell included.

That is the whole setup: a device with a camera, a browser, and a sentence describing what you care about.

Bring your own intelligence

Aura has no model of its own and no opinion about whose you use. Three sources, switchable in Setup, all feeding the exact same loop:

The in-browser source picks its own brain: Qwen3.5 0.8B by default — an ONNX conversion downloaded once (~875 MB, then cached), with smaller models as fallbacks for modest devices. On desktop Chrome 148+ there is a second runtime, Chrome's built-in Gemini Nano, which Setup can prefer explicitly; AUTO only chooses it when it is already downloaded and image-capable, and it doesn't exist on Chrome for Android — phones always get the Transformers.js model.

It has to be a vision model. Aura sends a picture on every scan, so a text-only LLM — however clever, however new — cannot do this job at all: it has nowhere to put the image. Look for vision, VL, multimodal or image input in the model's name or docs (qwen3-vl, gemma-4-vision, llama-4-scout, gpt-5-mini, claude-sonnet-5…). A model that can't see will fail the first scan with an error rather than quietly guessing.

A stronger model is genuinely better, and the difference is not subtle. The in-browser models are small enough to fit in a phone's memory, and they behave like it: they reliably answer "is there a person" and get vaguer the more judgement a question needs ("is that person struggling with the door?", "is the parcel the one that was already there?"). A frontier cloud model reads the same frame with far more nuance, and follows a picky mission prompt instead of approximating it. Start local to prove the idea costs nothing; move to a bigger model when the mission gets subtle — the mission and action prompts carry over unchanged, because every engine gets the same two prompts.

The provider is three fields: base URL, model, and an API key that is allowed to be blank. Your key lives in your browser's localStorage and goes straight to the provider you named; there is no Aura server in the middle, because there is no Aura server at all. It's a static page.

Because all three sources return the same shape, you can compare them: the Evaluate screen runs your own labelled frames through several models and prompts and scores them, so "is the tiny local model good enough for this camera?" is a measurement rather than a guess. The Lab's Examples tab goes further and rewrites your prompt against your own examples.

What your phone actually needs

Cloud and local-server engines need nothing but a browser and a network — all the work happens elsewhere, so a five-year-old phone is fine. The requirements below are for running a model on the device, and they are per model. Every one of these is built in and picked in Setup; Aura probes the GPU adapter's real buffer limits and the reported memory on arrival and selects the largest one the device can actually run, falling back rather than failing.

Plus the browser itself, for every row above the first two:

Storage is the quiet requirement: weights live in the browser's cache, so a 1.1 GB model wants that much free space, once. RAM figures are what the browser reports (navigator.deviceMemory, which caps at 8), not what the phone has.

Two things worth knowing before picking the biggest model your phone will take: sustained in-browser inference makes a phone hot, and a hot phone throttles. The object gate exists for exactly this — a 3 MB detector watches for changes and only wakes the big model when the set of objects in frame actually changes, which takes the GPU from busy most of the time to busy almost never. Turn it on in Setup → Advanced → Object gate.

Being honest about it

• It's an LLM looking at one frame at a time. It is excellent at "is there a person", good at "is that person carrying something", and unreliable at anything requiring memory of what happened ten seconds ago. Don't wire it to anything safety-critical.
• Cost and battery scale with how often it looks. Scan modes, budget caps and the object gate all exist to pull that down — the gate especially, since it only wakes the expensive model when the objects in frame change.
• iOS Safari cannot background-monitor. Safari suspends camera access for hidden pages, and no workaround exists. An Android phone or a plugged-in laptop with the tab in front works fine, and survives backgrounding, lock screens and reloads.
• Small in-browser models are coarse detectors, not scene analysts. That's what the Evaluate screen is for.

Using it responsibly

Aura points a camera at people and reacts automatically. Use it only where you're allowed to record, tell people they're being watched, and remember that a best-effort judgement from a single frame is not evidence of anything.

More

Preview URLs

Aura can be previewed without changing the GitHub Pages deployment.

• On the development machine: run npm run preview:local, then open http://localhost:8787. For a phone on the same Wi-Fi network, run npm run dev -- --listen tcp://0.0.0.0:3000 and open http://<development-machine-lan-ip>:3000.
• Shareable Cloudflare preview: first run npx wrangler login, optionally change the globally-unique name in wrangler.jsonc, then run npm run preview:deploy. Wrangler prints the resulting https://<worker-name>.<account-subdomain>.workers.dev URL. This deploys only the static public/ folder; Aura still sends API keys and camera frames only from the browser directly to the provider configured by the operator.

Wrangler runs Aura's build automatically before both preview commands, so it never uploads a stale public/ directory. The workers.dev worker is deliberately an opt-in preview target. It adds no backend, stores no monitoring data, and does not proxy provider or webhook calls. After a preview deploy, close any existing Aura tabs before reopening the URL so the new service worker can activate; the app will otherwise deliberately keep a running monitor on its already-cached version.

• CONTRIBUTING.md — running it yourself, pointing it at a local model, hacking on it, deploying it.
• docs/ — design documents for the bigger pieces (in-browser engine, local pre-filters, alert hygiene, scan modes).
• CLAUDE.md — architecture and conventions.

License

GPL-3.0 — see LICENSE.