Local AI video generator: two jobs, one noisy keyword

In 2026 the phrase has split into two jobs that share a name. The first is synthesis: a model like HunyuanVideo, Wan 2.2, Wan 2.6 or LTX Video running on your own GPU, driven through ComfyUI, turning a text or image prompt into pixels. That is what almost every roundup covers. The second is capture and reasoning: an AI that records your real screen to local video files and makes decisions from what it sees, without shipping the footage to a cloud. That is a different category with different hardware requirements, and almost no article treats it as part of the same question.

HunyuanVideo is a 13B parameter text-to-video model and runs comfortably on 24 GB of VRAM. Wan 2.1 and Wan 2.6 are also usually quoted at 24 GB VRAM as the practical floor, with the fp16 versions wanting more. LTX Video is the lightest of the headline models and can fit on smaller cards at the cost of fidelity. In every case the assumed setup is NVIDIA, CUDA, a Python environment, and ComfyUI as the interface. None of them have first-class Apple Silicon support, and most of them will not generate useful clips on a laptop CPU. If you need synthesis and you do not already own a 3090, 4090, or 5090 class card, honest advice is to use a hosted API and stop fighting the stack.

Fazm is a consumer Mac app that does the second job. It uses Apple's hardware HEVC encoder (hevc_videotoolbox) through a bundled ffmpeg to record the frontmost window at 2 FPS into H.265 chunks on disk, then pipes each 60 second chunk into an on-device analysis loop so an AI can reason about what you are doing and act on real apps. That pipeline runs in what the Fazm source code explicitly labels 'local-only' mode: no backend URL, no backend secret, just a cache directory on your Mac keyed by a hardware UUID. No login, no upload, no account.

Two files. The orchestration is Desktop/Sources/SessionRecordingManager.swift in the startScreenObserver() function, roughly lines 56 to 117, which constructs a SessionRecorder configuration with framesPerSecond: 2.0, chunkDurationSeconds: 60.0, captureMode: .activeWindow, a storage URL under Library/Caches/observer-recordings/, and a deviceId derived from IOPlatformExpertDevice via getHardwareUUID(). The comment 'No backendURL/backendSecret, local-only mode' is in the source. The actual encoder invocation lives in the bundled macos-session-replay package at Sources/SessionReplay/VideoChunkEncoder.swift around line 232, where the ffmpeg arguments include '-vcodec', 'hevc_videotoolbox', '-tag:v', 'hvc1', '-q:v', '65', '-allow_sw', 'true', '-realtime', 'true', '-prio_speed', 'true', and '-movflags', 'frag_keyframe+empty_moov+default_base_moof'. Those are the flags that make the encoder use the Apple Silicon media engine and keep each chunk playable without finalization.

On Apple Silicon, hevc_videotoolbox runs on the dedicated media engine that lives next to the CPU and GPU on the M-series die. It does not spin up the fans, does not pin a core at 100 percent, and does not compete with whatever app you are recording. A software encoder like libx264 or libx265 would take the same job to the CPU and pay a significant power cost, especially at sustained multi-hour sessions. For an always-on local observer that ships to Gemini or a local model for analysis, the difference is the line between 'background process you forget' and 'laptop on a desk getting warm'. That is why the flag set is there.

No. That is the honest answer. Fazm does not ship HunyuanVideo or Wan, does not embed a diffusion pipeline, and does not run ComfyUI workflows. If your goal is to produce new pixels from a text prompt on your own hardware, you want a GPU-first stack and you should read one of the many ComfyUI-on-RTX guides. What Fazm does is a complementary thing. It generates video from your real screen, locally, so an AI can reason about your real work. Two different jobs, one noisy keyword.

The recording pipeline does. Screen capture via ScreenCaptureKit, HEVC encoding via the Apple media engine, chunk storage to Library/Caches/observer-recordings, and deviceId lookup via IOPlatformExpertDevice are all fully offline. Whether the reasoning layer needs network depends on which model you have configured. Routing analysis through Gemini or a remote API needs network. Routing through a local model through a proxy does not. Fazm exposes a single 'Custom API Endpoint' field in Settings (it maps to ANTHROPIC_BASE_URL on the bridge subprocess) that lets you point the reasoning step at whatever you like, including an on-device shim.

Descript and its peers upload your footage to a service, then run AI analysis or editing against it in their cloud. That is fine for finished content, awful for private work on internal apps or regulated data. QuickTime records locally but has no AI layer and no chunking, you get a single MOV file with nothing watching it. Fazm sits in the gap: local encoding (hevc_videotoolbox through ffmpeg), chunking every 60 seconds so the analysis loop has something to work with in near-real time, and a reasoning layer that can stay on-device if you route it that way. It is the stack, not the format, that is the distinction.

They live in Library/Caches/observer-recordings under your user account, which is a standard macOS cache location the system is allowed to evict under pressure. At 2 FPS active-window capture encoded in H.265, sustained chunk sizes are small, much smaller than typical video because the frame rate is low and the source is mostly static UI. Fazm does not keep chunks forever; it is a rolling buffer for the reasoning layer. The folder is inspectable. You can open it, play a chunk in QuickTime, and delete anything you want.