Open-Source Sky Camera: Claude Code Automatically Catches Meteors, Spotting 17 in One Night

Title

Open-Source Sky Camera: Claude Code Automatically Catches Meteors, Spotting 17 in One Night

Meta Description

Open-source sky camera openskycam lets Claude Code autonomously run a nighttime meteor detection pipeline: auto frame extraction, classifying meteors vs. planes, retraining the model to cut star false positives from about half to 7%, catching 17 meteors in one night and auto-pushing results.

Article Content

A developer built an open-source sky camera system called openskycam and handed the entire pipeline—from detection to classification—over to Claude Code. On a Saturday night, the system caught 17 meteors and had everything organized before its owner woke up. The idea behind it: instead of manually scrubbing through hours of nighttime footage, let AI handle the tedious filtering and model iteration.

From Manual Labeling to Autonomous AI Iteration

The traditional meteor detection workflow is quite inefficient: watch the whole night's video, manually extract frames, label them, retrain the model, and then start over because the model tags every star as a flying object. The goal of openskycam's design is to hand this loop to Claude.

The system records 4K sky footage 24/7, with all material stored on a local disk. The workflow handles frame extraction, runs the detection model, links detections into tracks to distinguish moving from stationary targets, and then sorts the hits into three buckets: meteors, planes, and fixed light sources. Every feature on the website is also an API call, and with the built-in MCP server, Claude Code can directly drive the entire system.

What Claude Code Actually Did

According to the author, Claude's work spanned the entire overnight process:

• It built the nightly workflow, which runs automatically whenever new footage arrives;
• It reviewed every frame's detections, accepting or rejecting each one;
• When the model kept misclassifying stars as flying objects, it built a dataset from the author-approved detections and retrained the model. On nights of data it had never been trained on, the star false positive rate dropped from about half to 7%, while still catching 90% of meteors;
• Every morning it discards invalid results and pushes only valuable meteors to the phone; on cloudy nights it silently sends nothing.

The performance numbers here are worth noting: the false positive rate dropped sharply while high recall was maintained, showing that model iteration didn't come at the cost of detection capability. This is the key signal that the automated loop is truly working.

MCP (Model Context Protocol) is an open protocol introduced by Anthropic in late 2024 for letting AI models invoke external tools and data sources in a standardized way. You can think of it as a "USB interface" between AI and software systems: the server side declares which tools, resources, and prompt templates it has, and the client (such as Claude Code) can automatically discover and call them, with no need to write glue code for each project. An MCP server is essentially a process that follows the protocol, communicating with clients over stdio or HTTP. In openskycam, the author wraps capabilities like frame extraction, detection, and classification as MCP tools, so Claude can "see" which operations the system offers and learn the correct usage from the guides and skills the server provides. This design puts both capability exposure and behavioral constraints on the server side, a common engineering pattern for reliably having AI drive complex pipelines.

False positive rate and recall are two core metrics for evaluating a detection system. The false positive rate refers to the proportion of samples incorrectly labeled as targets, while recall refers to the proportion of real targets that are successfully detected. The two usually trade off against each other: tightening the decision threshold can lower false positives but will miss real meteors; loosening it does the opposite. The author's report of "star false positives dropping from about half to 7% while still catching 90% of meteors" means the model substantially improved precision while maintaining high recall, showing that retraining brought a genuine improvement in discriminative ability rather than simply tightening the threshold. Using "nights of data it had never been trained on" for evaluation is also crucial—this is an out-of-sample test that prevents the model from merely memorizing the star patterns in the training set, and it's the standard way to judge a model's generalization ability.

Why Claude Code Can Reliably Drive It

The biggest risk in having AI operate hardware and data pipelines is a lack of control. This project's approach is to put constraints on the server side rather than relying on prompts:

• The MCP server ships with its own guides and skills (build-a-workflow, find-detections, verify-changes); Claude learns the rules from the server instead of guessing from the author's verbal instructions;
• Guardrails are enforced by the server: no key can create new keys, delete operations show a preview first and require confirmation, and edit operations fail outright rather than overwrite when they encounter a newer version;
• Installation can run unattended: npm run setup -- --yes reads all configuration from .env, and stops and points out the missing item if something isn't set; however, the Cloudflare tunnel, login app, and API keys still need to be created manually;
• Architecture checks make make check fail when Claude puts code at the wrong layer.

This design conveys a clear viewpoint: the reliability of AI automation comes from system boundaries, not from the model's self-discipline.

Guardrails, in the context of AI automation, refer to safety constraints enforced by the system independently of the model itself. Compared with prompt-based constraints, guardrails don't rely on the model "obeying"; instead, they architecturally make dangerous operations impossible or require confirmation. Common forms include: permission tiers (certain keys or roles cannot derive new keys), two-step confirmation for destructive operations (preview first, then execute), optimistic concurrency control (if the data has already been updated during an edit, fail outright rather than silently overwrite), and static checks (such as make check reporting an error when code is placed at the wrong layer). This "defense in depth" approach comes from traditional security engineering: assume the AI will make mistakes, and push correctness guarantees down into the server and the build process. For systems that run unattended, guardrails also provide auditability—every rejection and confirmation leaves a clear boundary, making after-the-fact troubleshooting easier.

Hardware and Deployment Requirements

Running this system requires an RTSP camera, a Raspberry Pi, a machine with a large-capacity disk (macOS or Linux; the model can also run on that machine, with GPU optional), and a Cloudflare account with a domain name. A single command handles installation and guides configuration, and the trained nighttime model is already included in the repository.

There are two repositories involved: openskycam handles the camera, detection, and the tools Claude uses, while edmund-harness handles the iMessage messaging channel.

RTSP (Real Time Streaming Protocol) is a real-time streaming protocol widely supported by surveillance cameras, typically on port 554. It only handles control of the stream session (play, pause, parameter negotiation), while the actual audio and video data is mostly carried by RTP. It matters in a sky camera project because most network cameras natively output RTSP streams, so a Raspberry Pi or host can pull and record the stream directly without relying on the vendor's cloud service. This also means the entire system can run fully locally, with footage never leaving the home. At 4K resolution the bitrate is high, which places demands on disk write bandwidth and storage capacity—hence the author's emphasis on needing a machine with a large-capacity disk. If a camera only supports a vendor's proprietary protocol, you usually need to remux it to RTSP first or integrate via its SDK.

Output and a Bit of Dry Humor

The system's daily video runs from 9:30 PM to 6 PM the next day: at night, every meteor and plane comes with actual footage from the 4K camera; during the day, every identified bird is marked with a pink dot, and every 10 detections includes a close-up of a real bird. The video ends with a single-frame overview of the entire run and several charts.

The author mentions that some version of the system has been watching his sky since 2024, and the UFO count remains zero—lots of meteors, even more planes, and enough bird false positives that he nearly joined his local Audubon Society. Behind this self-deprecation is a pragmatic conclusion: the value of a detection system isn't zero false positives, but that false positives can be cleared in bulk and real events don't get drowned out.

If you're also building a similar automation project for astronomy or nature observation, this "server-side guardrails + self-training loop" approach is worth borrowing from.

One-line Summary

A developer used Claude Code to drive an open-source sky camera via MCP, automatically detecting meteors and retraining the model to recognize them.

Paragraph Summary

openskycam is an open-source sky camera system that records 4K sky footage 24/7, exposes frame extraction, detection, track linking, and classification as APIs, and uses a built-in MCP server to let Claude Code directly drive the entire nighttime pipeline. Claude automatically builds workflows, reviews detection results frame by frame, and when the model misclassifies stars as flying objects, builds a dataset from approved samples and retrains the model, cutting the star false positive rate from about half to 7% while maintaining a 90% meteor capture rate. The system's reliability doesn't depend on prompts but on guardrails enforced by the server: keys can't self-create, deletes require preview and confirmation, edit conflicts fail immediately, and architecture checks make code at the wrong layer fail the build. The hardware requirements are an RTSP camera, a Raspberry Pi, and a machine with a large disk, and installation can be completed unattended. The author has run a similar system since 2024, with a UFO count of zero and birds as the main source of false positives.