1Getting started
ClipLogger is a native macOS app that does three jobs in one place. It offloads camera cards with cryptographic proof. It helps you (and its AI) describe what is inside every clip. And it writes that understanding into open sidecar files that Premiere Pro, DaVinci Resolve, Final Cut Pro, and Avid already read. It lives at the storage layer, meaning your footage stays in ordinary folders on your disk or NAS, and it deliberately stops short of editing: sequences end at an FCPXML/EDL handoff to your NLE. The format is open; your metadata is readable JSON sitting next to your files, never trapped in a private catalog.
macOS 15 (Sequoia) or later on an Apple silicon Mac. The app ships as an Apple-silicon (arm64) build only and does not run on Intel Macs. For hardware-accelerated playback of MXF camera formats you can optionally install Apple's free Pro Video Formats package; ClipLogger detects whether you have it and falls back to its bundled ffmpeg decoder either way. Help ▸ Setup Check shows you at any time whether this Mac has everything installed.
Everything that runs on your Mac is free, forever, with no account: verified offload with MHL manifests, browsing, playback, search, projects, subjects, the full logging workflow, on-device AI, renaming, and every export. Money only enters when you use Rush, ClipLogger's own cloud batch-analysis service, which is metered in credits: one credit analyses one clip, flat, with a 15-minute per-clip cap. New accounts get a one-time 25-credit trial; paid plans include a monthly credit allotment and you can buy top-up packs.
No. The app works fully offline, with no sign-in, indefinitely. You only sign in for the two things that need a server: Rush cloud analysis and metadata sync between machines. Everything else, including bringing your own API key for cloud AI, works without an account.
You get a working browser immediately. There is no forced import, no library to create, and no wizard you must finish. A Welcome Tour is available (Help ▸ Welcome Tour). If you want local clip reasoning, the optional Built-in AI setup wizard walks you through a hardware check, model choice, download, and first load; it is reachable from Settings ▸ AI and the Help menu, and it never opens on its own. Plug in a card and the Ingest tab detects it; open a folder and you are browsing.
No. Camera originals are never rewritten: metadata goes into sidecar files beside the media, playback proxies are cached in your Library folder, and rename-on-copy renames only the copies. The only thing that touches a file's name on disk is the Rename workspace, which you invoke explicitly, with a preview and an undo. Even then it is a filesystem rename, never a rewrite of the file's bytes.
2Vocabulary
One durable identity in a project: a person, an item, or a place. The important part is that a subject is one identity carrying several kinds of evidence at the same time, not a thing with a single detection mode. A person-subject can hold face examples (ClipLogger groups the same face across your footage), appearance examples (a kit, a torso crop, a product's look), and a roster-bound jersey number, all at once, under one ID. Which signals a subject carries is derived from the evidence it actually has, so the same athlete found by face in one clip and by uniform in another can never split into two entries. The app's People features and its Subjects features are the same system; a person is one kind of subject.
The set of subjects a project owns. Your roster seeds it, you add to it by marking examples, and the AI links clips against it. The cast lives inside the project document, so it travels wherever the project does.
The organizing unit. A project owns three things: a palette snapshot (its own copy of your field schema), a subject cast, and a brief (what the deliverable is, plus an optional AI digest). Membership is a list of references; adding a clip to a project never moves or copies the file. Structured fields and AI logging require an active project because they need a schema and a cast to mean anything.
Your metadata schema: the fields you log, their types and options, plain-language definitions, keyboard bindings, lookup tables, and the project's two naming templates (display name and written file name). One palette is live in both Logging and Browse. Your library keeps reusable palette templates; attaching one to a project copies it, so project edits never change the template.
One entry in a palette: a key, a label, and a kind (flag, rating, color, text, keywords, single-select, multi-select, toggle, number, date, players, subject, or AI Description). The kind decides where the value is stored: native kinds land on standard metadata every app reads, structured kinds land in your custom log record. A field can carry a one-line steer for the AI, and a per-field switch controls whether the model may propose values outside its vocabulary.
A dimension you can filter the grid by. Every confirmed value becomes a facet: your log fields, ratings, flags, tech metadata, AI evidence like has-transcript or people-in-frame, ingest state, and review state. Pending suggestions are deliberately not facets until confirmed.
The complete on-disk record for one clip, written beside it as <full filename>.logger.json. It carries the media facts, the AI evidence, and your decisions, and it is what lets another machine pick up a folder without reprocessing anything. Writing it is on by default; the four NLE sidecar formats are off until you enable them.
The portable identity of a clip's content: a hash of the file's beginning, middle, and end plus its size. There is no hidden clip ID anywhere; the content key is how metadata re-attaches after a rename or a move, and how two machines agree they are looking at the same clip.
The watch mode. Strips layout gives each clip a filmstrip row you can hover-peek; String-Out lays the whole filtered set end to end. Use it to watch a day in order and cull as you go.
The entire filtered set laid out as one continuous strip you scrub like a single timeline, with a playhead and bulk-action rails. When the order tells the story, export it as an FCPXML sequence for your NLE.
A whole modifier layer of your keyboard turned into a code-entry surface: hold the modifier, type a code, and the bound lookup table resolves it into the field with an autocomplete HUD as you type. Holding shift and typing "72" to log an athlete by jersey number is this feature.
Any imported code-to-value sheet: a roster, location codes, shot codes, crew, SKUs. Parsed from CSV or TSV, bound to fields or code layers, searchable by code, name, or detail column. You can join several columns into the stored value and replace a table's contents in place later without breaking the bindings that point at it.
The canonical lookup table: jersey number, name, position. Importing one does two jobs at once: it becomes the code-replace source for typing numbers, and it seeds the project's cast with one person-subject per row, number bound, before any footage is analysed.
One example a subject is recognized by: a specific frame, a box on that frame, and a polarity (positive means "this is them", negative means "this looks like them but is not"). Each anchor belongs to the face space or the visual space depending on which embedder produced it, which is how one subject holds face and appearance evidence together. The frame reference is the truth; the stored vector is a cache that re-derives if you change embedding engines.
The drag gesture that creates an anchor: pause on a frame, drag a box around the person or thing, name it or pick an existing subject. A marquee is authoritative; unlike a scan hit it is never gated or second-guessed.
ClipLogger's own cloud batch service: submit a set of clips, they are analysed in parallel on hosted models, and results come back into the same suggestion-and-review flow as any local run, marked with Rush provenance. It requires sign-in and credits; nothing else in the app does.
The Rush unit: one credit analyses one clip, flat, with a 15-minute per-clip cap and up to 500 clips per job. The app shows "N clips → N credits · you have M" before anything is submitted, and failed or cancelled clips refund automatically.
Whatever runs an AI job. At the top level there are three families: Local (the built-in engine or your own LM Studio/Ollama endpoint; frames stay on your machines), Your API (your own OpenAI or OpenRouter key), and Rush. Within the local-and-cloud family, clip reasoning resolves down an ordered chain of rungs, and Settings shows you exactly which rung is active and why every other one is not.
The stored record of which engine produced a value: local, your own server, your API key, or Rush, recorded at the moment it ran. The clip's provenance badge displays it, and a value from before provenance tracking says "provenance unrecorded" rather than guessing.
Pending means proposed and not yet yours: AI suggestions, proposed subject links, proposed anchors. Pending values live only in the local index; they never enter sidecars, exports, search facets, or filenames, and they never travel to another machine. Confirmed values are decisions you made; they ride the sidecar and are what every export and search sees. A rejection is also a recorded decision, and it survives later re-runs.
A region attached to evidence: face groups store per-frame boxes, and clip reasoning can return per-region boxes that tie what the model said to where it saw it. Paused playback shows the overlay. Boxes are evidence for your confirm decision, never autonomous tags.
Query views inside a project, not folders that hold files. A manual bin is a curated list you drag clips into; a smart bin is a saved search (the exact search-box grammar) that evaluates live on each machine, plus any clips you pin in or exclude. Bins nest, and deleting one never touches a file.
A storage location ClipLogger manages: the volume or folder tree you browse, plus the .cliplogger folder beside it holding the index, the manifest, project documents, and caches. Settings rows marked "This vault" pin a choice (for example an embedding engine) into the open vault's manifest so every machine that opens it routes the same way.
The brief is a project's statement of intent: deliverable type, target duration, aspect, tone notes, must-includes, exclusions. The AI digest is an optional model-written overview of the whole project stored on the brief; once it exists it primes later AI runs so clip forty benefits from what the project already established.
The batch verb for AI logging: run the configured engine over the selected or browsed set and stage suggestions for review. You can stop a run (finished clips keep their results) and retry just the failures.
The per-clip do-over: clear that clip's cached AI result and run the model again, after you have improved field definitions, fixed a transcript, or switched engines. Your confirmed values and rejections are untouched.
A segment promoted to a first-class clip: its own browse row, its own analysis lane, its own name. Nothing is copied or transcoded; the range lives in the parent's sidecar as an ordinary segment, so any build can round-trip it. Promote the sections of a long clip that matter and treat them like clips everywhere, including Rush.
A marker is a timestamped note on a clip; a segment is an in-and-out range. Both carry an author stamp, both merge safely across machines, and both travel: markers ride into Premiere via XMP, into Final Cut via the metadata FCPXML, and into Resolve via a marker EDL.
The material the model reads alongside your palette: sampled frames (sharpness-aware), the transcript, on-screen text from OCR, detected framing and motion, and the clip's filename and folder names. Each text leg has a switch in AI settings, and a leg that is off is omitted from the prompt entirely.
3The order of operations
The app does not force this order, but each step exists to make the next one work better. This is the shape of a working day:
1. Offload the cards (or skip to step 2 for footage you already have). Verified copy comes first because everything after it assumes the bytes are safe; a card is never called wipeable until your destination policy is provably met.
2. Open the folder you will work in. Browsing is what builds the index, and the index is a cache, so there is no import step to wait on; pin the folder as a remembered location if you will come back to it.
3. Create or pick a project. Structured fields and subjects require one, because a field needs a schema and a name needs a cast before either can mean anything; the app prompts you the first time you touch a gated feature.
4. Set up the palette, and import your roster or lookup tables. The palette is both your keyboard and the AI's entire output space, so it has to exist before suggestions have anywhere to land, and the roster has to be in before typed or detected numbers can resolve to people.
5. Run the AI pass (Prepare), or just start logging by hand. Light on-device passes (OCR, transcription) already ran when you opened clips, so search works early; Prepare adds full clip reasoning against your fields once the schema and cast are in place.
6. Review and confirm. Nothing pending travels, exports, or renames, so the review pass is what converts proposals into metadata; Return accepts, Delete rejects, and a rejection is remembered.
7. Rename on disk. Renaming composes names from confirmed fields only, which is why it sits after review; sidecars move with the files and the content key reconnects anything renamed outside the app.
8. Export and hand off. Exports read confirmed values, so they come last; the enabled sidecar formats have been keeping themselves current the whole time, and the reel or sequence leaves as FCPXML/EDL for your NLE.
This is the exact order the code runs, from a name on a roster to that person found across a season.
1. Subjects get seeded three ways. You mark one with the marquee (pause, drag a box, name it). A roster import seeds one person-subject per row with the jersey number bound, before any detection runs; re-importing the same roster updates in place, it never duplicates. Or the AI proposes: clip reasoning can return grounded regions that attach to existing cast members as pending anchors, and names it read that are not in the cast surface as "new subject" proposals. The AI cannot invent a person on its own; new-subject proposals are locked to your roster and lookup vocabulary.
2. Every creation path goes through one resolver. Any code that binds a name or number to an identity calls the same match rule: first the jersey number (it resolves only when exactly one live person wears it; two wearers resolve to nobody rather than a guess), then a case-insensitive name match. A match reuses the existing subject's ID; only a genuine miss mints a new one. This single funnel is why the same athlete detected by two different models on two different days cannot fork into two entries.
3. Anchors accumulate as you confirm. Each confirmed example crop is an anchor, classified into the face space or the visual space by the embedder that produced it, positive or negative. A subject's live anchors plus its jersey binding are its recognition signals; there is no mode switch to set.
4. A scan finds the subject across the project. "Find in project" needs an active project and scans its members. Stage A shortlists candidates: a scoped scan (a selection, folder, or bin) takes the scope itself as the candidate set, while an unscoped scan prefilters the vault by comparing the subject's anchors against existing whole-clip embeddings. Stage B samples frames from each candidate on a deterministic grid (roughly one frame every two seconds, up to sixteen), embeds each frame once and memoizes the vector, then scores every frame against the subject's positive anchors, with negative anchors able to veto a frame and a background cohort normalizing the score. The clip's verdict pools its best three surviving frames.
5. Scan results land pending, never confirmed. An accept-or-review verdict writes an unconfirmed subject link with the frame that carried it; clips you already confirmed or rejected sit out. For a uniformed athlete recognized by appearance, a clean close-up face on the best frame is auto-rejected as background (a spectator, a ref), and the status line tells you how many were dropped so the filtering is never silent.
6. Review is grouped by subject. The review surfaces gather every pending item for a subject (field mentions, proposed anchors, scan hits) into one place, and group new-subject proposals by normalized name across clips so five sightings of one person are one card, not five. You confirm one instance, confirm all, or reject; rejects are recorded decisions that later re-analysis will not resurrect. If a proposed new name matches a subject the project already knows, the card says so before you click, and confirming resolves through the same match rule so no duplicate is minted. On a clip, the subject chip's ✕ unlinks that subject there (both the link and the tag).
7. Confirming writes the durable record. A confirmed link is stamped with the project scope, updates the subject's presence lanes and spans, rides the clip's per-project block in the sidecar, and becomes a facet you can filter, export, and rename by. Confirmed anchors also teach the next scan: every confirm sharpens what the matcher looks for, and every reject sharpens what it refuses.
8. Across projects, identity is copied but never forked. Reusing a subject in another project copies its definition and keeps the same ID, so cross-project queries know it is one person; a same-named subject created fresh is deliberately a different identity until you merge them.
9. When signals disagree, the conflict is surfaced, not settled. If face evidence in a clip binds to one identity and jersey evidence on that same person's torso resolves to another, ClipLogger records one conflict per pair (keeping the spatially tightest instance) and shows it for a one-click ruling: it is the face identity, it is the jersey identity (which rebinds the face group), or they are genuinely different people. A resolved conflict is sticky; a later scan cannot reopen it, and nothing is ever auto-resolved.
4Ingest & offload
Every file is streamed from the card with a running checksum (xxHash64 by default, the same family the ASC MHL standard uses; SHA-256 is also in the engine). It is written to a temporary file, flushed to the physical disk (F_FULLFSYNC), atomically renamed into place, then read back uncached from the destination and re-hashed. In the default "source and destination" mode ClipLogger also re-reads the source a second time, uncached, as an independent card-stability check, so a flaky card that returns different bytes on two reads is caught, not archived. Any mismatch fails that file closed: it is retried in full on transient errors, and if it cannot verify, the card is marked failed and is never called safe.
Yes. Each destination gets an ASC-MHL-v2-shaped hash list (per-file path, size, and xxh64, with a creator block) written into an ascmhl/ folder at the destination root, one per card, per destination. There is also a legacy MHL 1.1 writer on the transfer-queue path. You can later re-checksum any destination against its ascmhl/ manifest from inside the app ("verify-only," no source card needed) or from the command line with loupe-cli mhl-verify.
Yes. A run can target several destinations, and copies are planned in tiers (for example a fast local SSD first, then a NAS). An optional staging mode designates a fast SSD as the buffer the card is freed against first, with the remaining tiers trickling in the background; per-file byte verification remains the only thing that ever frees a card. Multiple cards also offload in parallel: cards on different USB controllers copy simultaneously, cards sharing one controller are serialized, and total read speed is capped at what the destination can absorb. The card's source folder tree is mirrored at each destination by default (you can flatten into the per-card folder instead, leaf names collision-uniquified), and two same-named cards in one run get distinct destination folders automatically.
When every file on the card has a verified copy on the number of distinct destinations your policy requires. The default policy is "2+ verified destinations", the classic never-on-fewer-than-two-media rule. You can set 1, 3+, or a strict mode that also requires you to acknowledge an offsite/second-media-type copy. A card shows "verified" (green) once everything is confirmed on at least one destination, and "secured" once the wipe policy is met; an unreadable file anywhere on the card blocks the verdict. An empty card is never called safe — there is nothing to certify.
Yes. Rename-on-copy rebuilds the copied file's name from a token template (default {date:YYMMDD}_{reel}_{scene}_{shot}_{take}_{original}). It applies to the copies only; the card originals and their sidecars are untouched, and verification is content-based so renaming never weakens it. It is off unless you turn it on for the run or preset.
ClipLogger fingerprints the card's files and looks them up in its manifest, then tells you it recognises the card and which destinations already hold verified copies; the tile reads "Already ingested" rather than silently re-copying. If you run it again anyway, files whose identical content already exists at the destination are skipped (the existing verified copy still counts). A *different* file that happens to occupy the same name is never overwritten: the new copy is written alongside under a content-suffixed name and flagged as a conflict. History alone never gates a wipe: the wipe verdict always re-checks that the copies exist now.
The file is retried with a fresh copy-and-verify attempt for transient faults (flaky readers, network blips); genuine corruption fails every attempt and the card goes to a failed state with the file named. Nothing partial is ever committed: the temp-then-atomic-rename design means an interrupted copy can't masquerade as a finished one, and a failed card can never show "safe to wipe." A per-run audit log (JSONL, plus a shareable HTML report) records exactly what happened to every file.
The card is freed as soon as every file's first-tier copy is source-verified, so you can pull it while later tiers (say, buffer to NAS) finish in the background. The eject buttons in the Ingest tab warn you if a volume is actually in flight, distinguishing "this card is still being read" from "this drive is being written to"; a forced eject mid-copy fails that card honestly rather than ever producing a false verdict. When a run finishes, ClipLogger plays a sound and posts a notification so you hear it from across the room.
As fast as the slower of your card reader and your destination, minus the cost of honesty: the default mode reads the card twice (copy plus stability re-read) and reads the destination back once. ClipLogger measures the card's read speed with a probe, then picks a parallelism plan from the file-size mix and shows the plan on the tile before the run. Thousands of small files copy many-at-once (they are latency-bound); large camera files use a narrow pool (they are bandwidth-bound). Live throughput is displayed per card while it copies.
5Projects
Not for the basics. Ratings, flags, color labels, titles, notes, keywords/tags, markers, and segments are "native" metadata that work on any clip anywhere on disk, project or not. A project becomes required the moment you want structured fields: your custom palette fields and the AI logging built on them. That gate exists because those fields need a schema and a cast to be meaningful; the app prompts you to pick or create a project when you first touch one.
Three things: a palette snapshot (its own copy of a Log Selector profile, covering your field schema, key bindings, lookup tables, and naming templates), a subject cast (the people, items, and places it knows), and a brief (deliverable intent plus an optional AI digest, a model-written overview of the whole project used to prime later runs). The palette is copied on attach, so editing it inside the project never mutates your library template.
You choose at creation. A volume-homed project is a JSON document at <volume>/.cliplogger/projects/ right beside the footage. It travels with the drive and appears wherever that drive mounts. An app-folder project lives in ~/Library/Application Support/ClipLogger/projects/. It survives the drive being disconnected and opens with zero volumes mounted. Both are the same file format read by the same store; a local mirror keeps every project listable and openable even when its volume is offline.
No. Membership is a reference: the project document records each member, and the clip's own sidecar carries a per-project block (which fields and subjects apply in that project). That backlink means a second machine that mounts the same storage can rebuild the project view from the clips themselves. Files never move for a project.
The members list comes from the project document joined against the index, never from scanning your drives. A member whose file can't currently be reached (drive unplugged, file moved, or a synced project whose media was never on this Mac) shows as an explicit offline placeholder with an orange badge, still carrying whatever metadata is known. An unmounted drive is never treated as a deletion. Directory scans only happen when you explicitly browse a folder.
The project record is tombstoned (marked deleted so it can't resurrect via sync), its child bins move to the top level, and the machine-local membership cache is dropped. Your clips, their sidecars, and all native metadata are untouched: deleting a project deletes the organizing unit, not the understanding. Nothing on disk is removed.
Both are query views inside a project, not folders that hold files. A manual bin is a curated list you drag clips into; a smart bin is a saved search: a stored query that evaluates live against the index on each machine, plus any clips you've pinned into it explicitly. Bins can nest, and a child bin without its own palette inherits the nearest ancestor's.
6The three working views
Five modes on the main toolbar: Browse (the grid/list), Reel, Log & Rename, Ingest, and Duplicates. Browse, Reel, and the Logging workspace are where you'll spend the day; Ingest is the card-offload surface; Duplicates groups near-duplicates and safety takes for review.
Scanning and triage. Cells show thumbnails you can hover-scrub, with badges for ratings, flags, color labels, offline status, and analysis state; audio files render as waveform cells you can audition by hovering. The filter panel and search bar drive what the grid shows, and everything you confirm becomes filterable there.
Watching a day as one strip. Strips layout gives each clip a filmstrip row with hover-peek; String-Out lays the entire filtered set end-to-end as one continuous snake you can scrub like a timeline, with a playhead, bulk-action rails, and jump-to-active. When the order tells the story, export the reel as an FCPXML sequence for your NLE.
Clip-by-clip capture. The Logging tab pairs the player with the Log Card (every field of your palette rendered as rows you fill by keyboard), plus the AI suggestion bar when suggestions are pending. Its sibling tab, Rename Files on Disk, is the batch-rename bench. Use Browse to find and triage, Reel to watch and cull in order, Logging to put words on clips fast.
Your palette maps physical keys to actions on layers (base, ⇧, ⌘, ⌥, ⌃): a key can stamp a value, pick a select option, add a keyword, or fire several fields at once. A whole modifier layer can be a code-entry surface: hold ⇧, type "72", and the roster resolves it to the athlete's name with an autocomplete HUD as you type. Return accepts the focused AI suggestion, Delete rejects it, ⌘Return confirms everything on the clip.
8Subjects: people, items, places
A subject is a durable identity in your project (a person, an item, or a place) that clips can be linked to. One subject carries several recognition signals at once: face examples, visual/appearance examples (a kit, a torso, a product), and an optional jersey-number binding. That means "Gibson" is one thing whether the evidence in a given clip was his face, his uniform, or his number.
It groups the same face across your footage, on your Mac: similar faces cluster together so you can name a group once and find that person everywhere. It ships no celebrity database and identifies nobody on its own; a group has a name only because you (or your roster) gave it one. All face grouping runs on-device.
Two ways: you create them, or a roster seeds them. Importing a roster CSV (jersey number, name, position…) mints a person-subject per row with the number bound. New-subject creation is deliberately roster/lookup-locked for AI flows: the model can propose linking an existing subject but can't invent a brand-new person, which is what keeps hallucinated names out of your cast.
A subject's jersey binding makes the number a deterministic key: an OCR'd or typed "72" resolves through the project's cast to the one live person wearing 72. Resolution refuses to guess: if two people share the number, it resolves to nobody rather than picking one. The same resolver is the only code path anywhere that binds a name or number to an identity, so the same athlete detected by two different models on two days can never fork into two entries. And when signals disagree (the face evidence says player A, the jersey says player B), the conflict is recorded and shown for a human call, never silently auto-resolved.
Pending means proposed and not yet yours. AI-proposed links, spans, and anchors are stored unconfirmed, live only in the local index, never travel to another machine, and are excluded from exports, search facets, and renames until a human confirms them. Confirmed values are the ones that ride the sidecar. Pending and confirmed both show during review so you can see what's waiting.
The review surfaces group proposals by subject so you can confirm or reject in bulk: confirm-all for a group, reject-all, and per-clip accept or unlink. Rejecting is a recorded decision, not a deletion: a later re-analysis will not resurrect something you rejected. On a clip, a subject chip's ✕ unlinks that subject for real (link and tag both), and multi-name suggestions accept one name at a time via per-chip ✓/✗ if you don't want the whole list.
Yes, as provably the same identity. Reusing a subject in another project copies its definition but keeps the same UID, so cross-project queries and merges know it is one person. A same-named subject created fresh in another project is deliberately a different identity until you say otherwise.
Yes, where recognition produced them: face groups store per-frame boxes, and AI clip reasoning can return per-region grounding boxes that attach evidence to the person or thing it describes. Paused playback shows the box overlay, and jersey-based proposals crop the torso region deterministically for review. Boxes are evidence for your confirm decision, not autonomous tags.
9AI logging
Local runs models on your own hardware, either the built-in engine (a bundled llama.cpp server running a vetted model such as Qwen2.5-VL 7B that you download once) or your own LM Studio/Ollama endpoint; frames never leave your machines. Your API uses your own OpenAI or OpenRouter key, stored in the macOS Keychain; sampled frames go from your Mac straight to your chosen provider on your own account, one clip at a time, and ClipLogger takes no cut and never proxies the traffic. Rush is ClipLogger's own paid cloud service: no keys, no setup, whole batches processed in parallel, priced in credits and disclosed before every run. All three produce the same metadata shape into the same review flow.
On-device. With nothing configured, analysis uses Apple's frameworks (OCR, transcription, face grouping, embeddings, aesthetics) plus deterministic evidence; add the built-in model and local clip reasoning joins them. Cloud engines only exist once you paste a key or sign in for Rush; there is no silent cloud fallback.
If two or more engine families are genuinely ready (local model installed or endpoint configured; a working key; signed in with a positive Rush balance), a chooser appears before the run with a card per engine and the palette it will log against. You can tick "Remember for this project" to skip the ask next time. The remembered pick is honored only while it is still actually usable (Rush out of credits falls back to asking). With one engine ready there is no ask; it just runs.
No. Every model output lands as a suggestion, visibly pending on the field row, and nothing touches your record, sidecars, exports, or filenames until you accept it. Return accepts the focused suggestion, Delete rejects, ⌘Return confirms the clip, and list suggestions support per-chip partial accepts. Your rejections are permanent decisions that survive later re-runs and resets.
Sampled frames (selection is sharpness-aware, so it reads the crisp frames, not motion blur), the clip's transcript, on-screen text from OCR (scoreboards, slates, lower thirds), detected numbers, framing and motion classification, and your palette (field definitions, options, your per-field guidance, and the project's AI context blurb). In a project it can also be primed with the project digest and what the batch has already established, so clip 40 benefits from clips 1–39.
Prepare Suggestions is the batch verb: it runs the configured engine over the selected or browsed set and stages suggestions for review. You can stop a run (completed clips keep their results) and retry just the failed clips. Opening a clip also auto-runs light on-device passes (OCR and transcription) by default, so search and fields have something to work with before you ever hit Prepare. Turn that off in Settings ▸ AI if you don't want it.
A per-clip do-over: it clears that clip's cached AI result and runs the model again, useful after you've refined field definitions, updated the transcript, or switched engines. Re-reason re-extracts a missing transcript first, so speech evidence is present before the model runs. Your confirmed values and rejections are untouched.
Within a project, yes, in an explicit, inspectable way: your accepted and corrected values feed field-level examples and vocabulary that shape later prompts, and the project digest gives every new run the project's accumulated context. There is no hidden model training on your footage, just prompt-side learning you can read.
The built-in engine runs on any Apple silicon Mac, and the setup wizard checks your hardware and recommends a model size for your RAM. More memory means bigger models and faster batches; a modest machine still runs the full pipeline, just slower. Re-running analysis you've already confirmed is free: results are cached and reused, so zero-GPU sessions stay snappy.
10Privacy & data routing
Three routes exist, all visible. (1) Rush runs you submit: sampled frames from the clips in that batch go to ClipLogger's cloud. (2) Your-API runs: sampled frames go directly to the provider whose key you pasted. (3) JuiceMount sharing: if (and only if) a volume you browse is backed by a JuiceMount storage server, ClipLogger can publish computed AI and your assertions (names, tags, log picks) to that server so teammates don't recompute it. Route 3 is on by default and lives in Settings ▸ Sharing & Privacy, where a master switch turns all of it off. Local engine runs, browsing, offload, and search send nothing anywhere.
Yes. Both switches (share metadata; contribute computed AI back to the volume) default on, because the destination is normally your own storage server backing your own volume. If no JuiceMount server backs a volume, the switches are inert. Settings ▸ Sharing & Privacy states this in plain language and is the one place to turn it off; the subordinate AI-contribution switch is disabled whenever the master is off.
The routing is built so they can't. "Local is configured" is derived from the raw endpoint text, so a mistyped URL fails safe to on-device, never through to cloud. The decision is re-checked against your current settings immediately before every send. And a configured-but-unreachable local endpoint with "keep frames local" set degrades to deterministic evidence, never to a cloud fallback. A server URL that is not on your own network is allowed but is never labeled local.
Sampled frames and evidence for the clips in the batch you confirmed, never your source media files. Frames are uploaded for processing and deleted after a retention window on the server; per the published privacy policy they are never used to train, fine-tune, or evaluate any model, ClipLogger's or a vendor's.
Every reasoning result stores its provenance (local, remote server, cloud with your key, or ClipLogger Rush), recorded at the moment it ran, not inferred later. The clip's provenance badge shows it, with an honest tooltip ("frames stayed on this Mac or your own network" vs "frames were sent to your API provider" vs Rush). A value from before provenance tracking says "provenance unrecorded" rather than guessing.
In the macOS Keychain, on your Mac. ClipLogger never proxies your-API traffic through its own servers, never sees your key, and adds no markup; you pay your provider directly. Signing in for Rush or sync changes none of the routing above: an account meters credits and identifies your sync peer, it never enables any background upload of footage or metadata.
11Settings, tab by tab
How the app behaves while you look at footage. Playback: the seek amount for arrow-key jumps (default 10 seconds, 1 to 60); Autoplay next clip (default off) advances to the next clip when one finishes; Autoplay on click (default on) starts playback the moment a clip opens, and turning it off opens clips paused. Proxy playback (NAS) applies on JuiceMount volumes: Prefer proxy (the default) plays the smaller server proxy when one exists, Disable proxies always plays the full original; the same control sits in the toolbar whenever you are on such a volume. Browser: where a clicked clip opens (default Hovered point, so it opens on the frame you were scrubbing; also Start of clip or a fixed position), thumbnail size (default 180 px, 120 to 360), filmstrip frame density (default 40 frames, 24 to 120; more frames means a denser timeline strip but slower generation), Drill down into subfolders (default on), and Exclude proxy media from the grid (default off). Viewing: Correct LOG → Rec.709 by default (default on) displays log footage through a viewing transform instead of flat. Markers: the author handle (defaults to @ plus your macOS username) stamped on every marker and segment you create, so multi-editor work knows whose note is whose. Drag & drop: whether dragging clips onto a folder moves or copies (default Move; hold ⌥ while dragging for the opposite). An Advanced disclosure holds read-only playback diagnostics: whether Apple Pro Video Formats is installed, and a list of recent playback decisions (native, transcode, proxy, failed, and why) you can paste into a report.
What ClipLogger must prove before calling a card safe, and how copies run. Safety: the "Safe to wipe" requirement (default 2 verified destinations; also 1, 3+, or a strict mode that adds an acknowledged offsite copy) and the copy verification mode (default Source + destination, which re-reads the card as a stability check; Destination only is faster; Size only is fast and unsafe before formatting, and is labeled that way). Change these only when you understand the trade you are making with irreplaceable footage. Naming: Rename files on copy (default off); the template itself lives on the Ingest screen next to the cards it applies to. Staging: route card copies through a fast local drive before the real destinations (default off, and the toggle does nothing until you choose a staging folder); the card frees the moment the staged copy verifies, and the copies to your destinations continue in the background, surviving a relaunch. When a run finishes: play a sound (default on) and show a notification (default on), for the operator loading the next card from across the room. The Ingest mode itself is ⇧⌘I.
Everything the app does with a model, in four groups. Analysis: Read text and speech automatically (default on) runs on-device OCR and transcription when a clip opens, so search and fields have material before you ever run Prepare; turning it off cancels passes in flight. Let AI suggest what's in a clip (default off) is the master opt-in for clip reasoning suggestions; a note appears if reasoning is already active through a local engine, because this switch only gates the cloud fallback. A confidence slider (default 0, meaning show all) hides suggestions below a floor. Engine: the clip-reasoning fallback chain rendered as an ordered list, with the active rung marked and every other rung stating why it is not the one (Apple's on-device model when enabled and available, then the built-in engine, then your LM Studio/Ollama endpoint, then your cloud key, then the on-device deterministic pass); a line underneath states plainly whether frames leave the Mac right now, and Refresh live-probes your endpoint. Below it, Routing by task: one row per AI job (on-screen text, transcription, clip reasoning, the embedding jobs; a couple of slots are visible but marked as coming), each with an engine picker where a real choice exists, a "This vault" checkbox that pins the engine into the open vault's manifest so it travels, and a disclosure opening that engine's own setup. Clip reasoning cannot be pinned per vault; its routing is your endpoint and privacy settings. The transcription row's disclosure is where whisper setup lives: install status, a base English model download (~150 MB), and the recommended Whisper Large v3 Turbo download (~1.6 GB, higher accuracy, only used when you pick it). The clip-reasoning row's disclosure holds the built-in engine toggle (default off), the Apple Foundation Model toggle (default off, usable only on a Mac that has it), the local endpoint fields (Server URL and model, with one-click LM Studio and Ollama presets, a live label saying where the address actually points, Test connection, and Load model now), the cloud provider picker (OpenAI or OpenRouter, with the OpenRouter model field), and a checkbox to fall back to your cloud key when the local server is unreachable (default off: with it off, an unreachable local server degrades to on-device evidence, never to cloud). Models: the built-in engine's live status (running, loading, stopped, port, active model) with Start and Stop, per-model rows showing download size, RAM guidance, and a fit note against this Mac's memory, plus the guided setup wizard; and the Vision models section, where optional embedder downloads (SigLIP2, DINOv2) read "Planned" until a hosted release exists and flip to a live download button the moment one does. Advanced tuning, collapsed by default: frames per clip (default 6, 2 to 60; long clips scale up automatically and blurred frames are skipped), frame size (default 768 px longest edge), Calibrate (measures how many images your local model actually attends to and stores it per model; Prepare then sends the smaller of that and the app's own cap), max reply tokens (default 4,000, 200 to 32,000; reasoning models think against this same budget, so keep it generous), request timeout (default 240 seconds; the first request against an unloaded local model is also the load), the evidence legs (on-screen text, transcript, filename and folders, all default on; a leg you turn off is omitted from the prompt entirely), Transcribe on this Mac before sending (default on: before a Rush batch uploads, clips without a transcript are transcribed locally first, and clips that genuinely cannot be are disclosed and sent), the experimental agentic tool loop (default off: when the first pass looks uncertain, the model may re-examine the clip through a bounded tool-calling loop), and per-channel transcription (default off; turn it on for multichannel audio where people talk over each other). Tuning changes apply to clips reasoned after the change; already-reasoned clips keep their stored results until you Re-reason them.
The one tab about where data goes. Sharing with a JuiceMount server: the master switch (default on) lets ClipLogger publish the AI and metadata it computes (captions, transcripts, on-screen text, embeddings, face groupings and the names you gave them, your log picks and tags) to the JuiceMount server backing a volume, so teammates reuse it instead of recomputing; the subordinate switch (default on, disabled whenever the master is off) contributes this Mac's computed AI back to the volume. Both default on because the destination is normally your own storage server; if no JuiceMount server backs a volume, the switches do nothing. A caution line states plainly that faces, names, and transcripts are personal data. Turn the master off and nothing ClipLogger derives on this Mac leaves it. Sidecar files beside your media: the five writers. The .logger.json sidecar is on by default and is the only on-disk carrier of the full record; the per-file XMP (Premiere and Bridge), the Resolve CSV, the FCPXML manifest (Final Cut), and the ALE (Avid) all default off, and every tag, rating, or color change refreshes whichever formats are enabled. Turn on exactly the formats your pipeline reads. Maintenance: Forget cached project registries clears what this Mac remembers about project libraries between launches (offline sidebar listings, member snapshots); the project files on your volumes are untouched, and reopening a volume relearns everything.
Bring-your-own API keys, one row per provider (OpenAI, Anthropic, Gemini, Replicate, OpenRouter), stored in your macOS Keychain. Keys are used only when you opt into the matching cloud feature, ClipLogger never proxies or adds a markup, and you pay the provider directly. Clip reasoning today uses the OpenAI or OpenRouter key, chosen in the AI tab's cloud provider picker.
Sign-in for the two features that need a server: Rush and cross-device sync. Signed out, everything local keeps working. Signed in, the tab shows your email, plan tier, and credit balance (a Studio member also sees the team pool line, which is what Rush actually spends), plus Refresh, Manage Billing, and Sign Out. Below it, Sync projects across devices (default off) keeps your projects, palettes, casts, and briefs current on every Mac you sign in on; local logging never depends on it.
12File naming & renaming on disk
Yes, that's the point of the token templates. A template like {f:team}_{action}_{players}_{original} composes an output name from your confirmed fields (only confirmed values; pending suggestions never reach a filename), plus built-ins like {date}, {reel}, {scene}, {shot}, {take}, {rating}, and a {seq} counter with padding, start, and step. Any palette field is addressable as {f:key} or plain {key}.
Rename-on-copy names the copies during offload and never touches originals. The Rename Files on Disk tab is the in-place bench for files already on disk: point it at a folder or at your current browsed/filtered set, stack rules (find/replace with regex, token template, case transform, sequence), and watch a live before→after preview per file. Nothing happens until you apply.
The engine detects collisions up front (per-directory, so a name taken in folder A doesn't block folder B) and applies in a cycle-safe two-phase order so swaps can't collide mid-flight. It never overwrites a file outside the set, and it rolls back on any conflict. Afterwards a one-click Undo restores the previous names of the entire batch. Files you uncheck are excluded but stay visible in the preview.
Yes, twice over. Every sidecar belonging to the clip (.logger.json, .xmp, .cdl) is moved to follow the media in the same operation, keyed to where the file actually landed. Independently, the index re-homes metadata by content key (a begin/middle/end content hash plus size), so even a rename done outside ClipLogger reconnects to its metadata the next time the file is seen. Renaming on disk is exactly why names survive into every other app.
Because the filename is the one field every application reads. A display-name template can title clips inside ClipLogger without touching disk; the written-file-name template bakes your scheme into the files themselves, so Premiere, Resolve, Finder, and a stranger's machine all see 72_TD_Johnson_A001C012.MOV. Each project's palette carries both templates, and the Rename tab defaults to the active project's scheme.
Yes. "Parse Names → Metadata" reads your template against existing filenames and writes the recovered field values back through the normal logging resolver. A confirmation shows exactly what will be written before it happens. It's the recovery path for footage that was named by convention before it was ever logged.
14Search & filtering
Every confirmed value is a facet. The filter panel covers native metadata (rating, flag, color, keywords, notes), tech (codec, resolution, frame rate, duration, drop-frame), AI evidence (has transcript, has on-screen text, has faces, has numbers, framing, people-in-frame count, in-motion, quality score, cull candidates), ingest state (ingested, verified copies ≥ N, safe to wipe, has MHL, online/offline), review state, and your own log fields with live value lists. Filters combine, and each shows as a removable chip.
Yes, two ways. The Log status facet is a tri-state (Unlogged, AI-suggested, Confirmed), so "show me everything still waiting on review" is one click. And every reasoning result carries provenance (local / your API / Rush), so cloud-derived values are identifiable per clip via the provenance badge.
Yes. The box takes free text plus typed predicates: key:value equality, numeric and range comparisons on any recognised facet, and has: presence checks, all lowered into safe SQL. Free text matches names, titles, notes, transcripts (full-text), and on-screen text. Alongside it there is image-similarity search: pick a clip and find visually similar ones from on-device embeddings.
Sort the grid by Quality (best shot), which is the on-device aesthetics score, or filter on the quality-score range and the cull-candidates flag to sweep the junk the other way. Combine with your own flags and ratings; the AI score is a lens, your flag is the decision.
Yes, as smart bins. A smart bin is a project-hosted saved query that evaluates live on each machine; pin clips into it to keep them regardless of the query, or exclude ones that match but don't belong. Because bins are query views, a saved search never moves or copies a file.
16Rush & accounts
Rush is ClipLogger's own cloud batch lane: submit a set of clips and they are analysed in parallel on hosted frontier models, with zero configuration. No API keys, no model shopping, no GPU. Results flow back into the exact same suggestion-and-confirm review as a local run, marked with Rush provenance so you always know where a value came from. It exists for the moments deadlines beat hardware: a card comes in at lunch, and the whole thing is logged, described, and searchable before you finish eating.
Two reasons: speed and depth. Your Mac analyses one clip at a time on a model sized to fit in laptop memory. Rush fans the batch out across many workers running far larger models, so a few hundred clips finish in roughly the time a handful would, and your Mac stays free for editing instead of pinned at full fan. The bigger models also read harder frames better: small on-screen text, jersey numbers at distance, busy multi-subject scenes, and denser, more specific descriptions. The trade is simple and honest. Local is free and private by construction; Rush is metered and fast. Both land in the same review, and you confirm either before a word is written.
The batch runs in parallel, so total time is set by your upload and the longest clips, not by the count. A batch that would occupy your Mac for an afternoon typically comes back in minutes. The app shows per-clip progress as results stream in, you can start reviewing the first clips while the rest are still processing, and if you relaunch mid-job the app picks the results back up from the server.
One credit analyses one clip. Flat: no per-minute or per-token math, no quality tiers. A 300-clip batch costs 300 credits, and the app shows you the line "N clips → N credits · you have M" before anything is submitted; nothing runs until you confirm the spend.
Up to 500 clips per job, and up to 15 minutes per clip (a clip at exactly 15:00 is eligible). Anything over the cap is excluded by name, with the reason, in the pre-submit disclosure rather than silently dropped. A duplicate selection of the same clip is de-duplicated so it can't burn two credits. Long files aren't stranded: promote the sections that matter into sub-clips and submit those; each range is its own clip and its own credit. There is also a small per-account concurrent-job limit, and the server tells you plainly if you hit it.
You are never charged for work that didn't happen. Credits are reserved at submission and settled when the job finishes: processed clips burn their credit, failed clips burn nothing, and the difference is refunded automatically. Cancelling stops undispatched clips (their credits refund) while clips already mid-analysis finish and settle normally. Settlement can never charge more than the reservation you confirmed.
Free includes the full local app forever plus a one-time 25-credit Rush trial, enough to feel what a cloud pass does to a real card. It is deliberately a trial, not a recurring free tier. Pro is $20/month with 150 credits included monthly; Studio is $49 per seat/month with 500 credits per seat pooled across the team. Top-up packs: 100 credits for $12, 500 for $50, 1,000 for $90; purchased packs don't expire. (Current pricing lives at cliplogger.com/pricing.)
Only for Rush and for cross-machine sync. Sign-in lives in Settings ▸ Account; offload, browsing, logging, local AI, your-own-key cloud AI, and every export work with no account at all.
Studio seats share a pooled balance, and viewer seats can see work but cannot spend. The server refuses viewer submissions, and the app hides the Rush option for viewers rather than offering a button that would fail.
17More questions people ask
Two places. Beside your footage, each managed volume gets a .cliplogger folder holding the on-volume index, project documents, a lock file, and derivative caches; that folder is what makes a drive self-describing when it mounts elsewhere. On your Mac, ~/Library/Application Support/ClipLogger holds app-folder projects, the project mirror (offline listings), downloaded AI models, whisper models, and playback proxy caches. The SQLite index is a rebuildable cache by design: deleting it costs a re-scan, never data, because every confirmed decision lives in the sidecars. The big disk items are downloaded models (gigabytes each, removable from Settings ▸ AI) and cached proxies.
Your media, the sidecar files beside it, and the .cliplogger/projects folders (plus ~/Library/Application Support/ClipLogger/projects if you keep app-folder projects). That set reconstructs everything: the index rebuilds from media plus sidecars, proxies regenerate, and palettes travel inside project documents. If you back up footage folders whole, the sidecars and on-volume projects come along automatically.
Yes, with one honest constraint: the on-volume index accepts one writer at a time. A lock file beside the index carries the holder's identity and heartbeat; a second machine that cannot get the lease works against its own local cache instead of risking corruption, and every ambiguous case resolves to denial rather than a dual write. Project documents are built to merge: two machines curating the same project union their changes, newest edit wins per entry, and deletions cannot resurrect. Confirmed metadata meets in the sidecars, and on a JuiceMount volume the computed AI is shared through the server so the second machine does not recompute it.
Deletion goes through a recycle bin with a deliberate order: every item is preflighted first (so the count on the button is the count that will move), the file operations run, and the index is then updated from what actually happened, never from what was requested. The result reports both numbers when they differ. Nothing is ever auto-purged: there is no retention timer, no size trigger, and no deletion as a side effect of offload, reject, or project delete, and a file is never removed unless its identity still matches what was binned.
Yes. Mark the range as a segment, then promote it to a virtual clip: it gets its own browse row, its own name, and its own analysis lane, while the range itself is stored in the parent's sidecar as an ordinary segment, so nothing is copied or transcoded and any build round-trips it. This is the intended path for a six-minute interview with three usable sections, or a 25 GB slow-mo clip where a few seconds matter. Each virtual clip counts as its own clip for Rush.
Yes, loupe-cli, the headless counterpart for pipeline work. It scans and indexes folders, verifies destinations against their ascmhl manifests (mhl-verify), re-exports sidecars for a whole tree (export-sidecars), and runs AI indexing without the app open. It reads and writes the same index and sidecars as the app, so the two never disagree about state.
Keep it open through submission and the evidence upload; after that the batch runs server-side. Jobs still in flight when you quit are persisted, and on relaunch the app resumes polling them and ingests the finished results into the normal review flow. Cancelling from the Rush panel stops undispatched clips and refunds their credits.
The default whisper model the app offers is English-only (the base English model, about 150 MB). The recommended upgrade, Whisper Large v3 Turbo (about 1.6 GB, downloaded with the same verified downloader as the AI models), is multilingual and noticeably more accurate; your current model stays the default until you explicitly pick the new one. For multichannel audio where people talk over each other, turn on per-channel transcription in AI ▸ Advanced tuning.
Yes. Turn off "Read text and speech automatically" in Settings ▸ AI and leave "Let AI suggest what's in a clip" off, and no analysis runs at all; with no engine configured there is no cloud to fall back to by construction. Offload, browsing, playback, projects, manual logging with the full palette and keyboard, renaming, search over your own metadata, and every export work without any model.
Every reasoning attempt is stored with its request shape, model ID, provider, timestamp, and status, and the AI log shows the full exchange per attempt, including the tool-loop transcript when the agentic loop ran. Token and cost telemetry is recorded per run, provenance is stamped per result, and all of it rides the .logger.json sidecar, so the audit trail travels with the footage. If an attempt looks wrong, Re-reason reruns just that clip without touching your confirmed values.
You choose the scope (the current view, a folder, or the whole volume) and the criteria: file size, name (optionally ignoring the extension), tech metadata (codec, resolution, frame rate, bitrate), duration, timecode, transcript similarity, and content hash, which is definitive when it matches. Groups are presented for review with a keeper rule (newest by default) suggesting which copy to keep; nothing is deleted without going through the same recycle-bin flow as any other deletion.
The Jobs popover in the toolbar. Every long-running task is a job with progress and a stop control: subject scans, Prepare batches, duplicate scans, pre-caching, and Rush submissions each show there, and the Artifacts section controls background derivative work like deep pre-caching. Job status lines also surface inline near the feature that started them.
Help ▸ Keyboard Shortcuts opens a window listing the app-wide keys (seek, cull, ratings, markers, mode switching). Your logging keys are separate by design: they belong to the palette, so the palette editor is where you see and change what each key stamps, layer by layer. Typing in any text field always wins over shortcut keys.
Three things, each visible and each optional. The updater checks the release feed for new versions. If a volume you browse is backed by a JuiceMount server, the two sharing switches (on by default, in Settings ▸ Sharing & Privacy) exchange computed metadata with that server, and turning the master off stops it. And any cloud engine you configured yourself sends frames only when you run it. With no JuiceMount volume, no keys, and no sign-in, footage and metadata do not leave the Mac; only the update check remains.
ClipLogger updates itself with the standard Sparkle mechanism: it checks the feed, offers the new version, and installs on relaunch. Updates are code-signed and notarized, and the app verifies the update's signature before installing. Nothing about an update touches your index, sidecars, or projects; format changes are additive, and an older build reading newer metadata degrades politely rather than failing.
There is no NLE-project importer. The two import paths that exist are spreadsheets and filenames: any code-to-value CSV becomes a lookup table (and a roster CSV seeds the cast), and "Parse Names → Metadata" reads your naming template against existing filenames and writes the recovered field values back as real metadata, with a confirmation first. Round-tripping an NLE's own metadata back into ClipLogger would need a founder-decided mapping per NLE.
18Troubleshooting
AVFoundation can't open several broadcast MXF flavors (Canon XF-AVC, XAVC-class H.264 4:2:2 10-bit intra, DNxHR in MXF). ClipLogger routes those to its bundled ffmpeg, which builds a one-time H.264 proxy: proxy-grade by design, cached, source untouched. For native-quality hardware playback of MXF camera formats, install Apple's free Pro Video Formats package; Help ▸ Setup Check shows whether it, the bundled ffmpeg, and the local AI model are present on this Mac.
Local clip reasoning needs a one-time model download (the default is Qwen2.5-VL 7B, fetched with a resumable, hash-verified downloader). Run the Built-in AI setup wizard from Settings ▸ AI: hardware check, model choice, download, verify, first load. Until a local engine (or a key, or Rush) exists, analysis still runs; OCR, transcription, faces, embeddings, and aesthetics are all Apple-framework on-device. You just don't get full clip reasoning.
That's a pending suggestion: proposed, not confirmed. Pending values are local-only by design: they never enter sidecars, exports, search facets, or filenames until you accept them. Open the clip in the Logging tab (or the review surfaces) and accept or reject; ⌘Return confirms the whole clip.
It shouldn't anymore. Detection reads are deadline-bounded, so a stalled or yanked card fails fast with a "stopped responding, reconnect to check again" message instead of hanging the queue. If a physically failing card wedges the OS itself (bad exFAT media can put the reader into uninterruptible kernel I/O, which stalls Finder system-wide on modern macOS), that is below any app's reach: unplug the reader, and treat the card as suspect. ClipLogger's own checks are built to end fast and never emit a verdict from a half-read card.
That's the offline badge: the clip's file isn't reachable right now because its volume is unmounted, the file moved, or the project arrived via sync onto a machine that never had the media. Its metadata still displays from the index, and nothing is deleted; reconnect the volume (or restore the file) and it comes back live. An unmounted drive is never treated as a deletion.
The clip was analysed before per-clip provenance existed, so whether its frames stayed local wasn't recorded, and the badge refuses to guess rather than claim "local" without a stored fact. Re-reason the clip and the new result records its provenance.
Only .logger.json is on by default; XMP, Resolve CSV, FCPXML, and ALE are opt-in per format in Settings ▸ Sharing & Privacy. You can turn .logger.json off too, but with it off your AI evidence no longer travels with the files, and another machine would have to recompute everything. For deliveries, prefer copying media without sidecars over disabling the format.
Both are exact server answers, not generic errors: the first tells you exactly how many credits you have and need (top up, or trim the batch), the second means your account's concurrent-job limit is reached; wait for a running job to finish. The pre-submit disclosure shows your balance before you confirm, so the first case normally surfaces before a submit, not after.
It reconnects on its own: metadata is keyed to the file's content (begin/middle/end hash + size), so the next time the renamed file is scanned it re-homes to its existing record. Keep sidecars beside files when you move them by hand, or do renames in ClipLogger's Rename tab, which moves every sidecar with the file and offers a one-click undo.
Nothing matches that. Try a shorter word.
