This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.
What I Built
I have scheduled jobs that occasionally print alarming lines and then recover. Reading the whole log the next morning is work; treating every WARN or ERROR as an alert is even more work.
quietline is a tiny Python CLI that reads only newly appended log lines and tries to wake me only for failures that still need attention. A cheap local filter finds signal words. An open-weight model reads those lines with nearby context and marks each one wake or sleep. The CLI checks that every decision refers to an actual line number, then prints the original evidence beside any alert.
The sample log has three signals: a storage API returns 429 and succeeds on retry, a site build cannot create its output directory and exits with code 1, and a cache miss is followed by HTTP 200. The model should sleep through the two recoveries and flag the failed build. On my captured run, it did exactly that. This is a synthetic test log, not a claim that quietline is already monitoring a production system.
Demo
Watch the 15-second CLI demo · See the release and recording details
The video renders the output of three actual CLI invocations against a temporary copy of the sample log. The first call used NVIDIA's hosted Nemotron 3.5 Lightning model; the next two did not call a model. Here is the first result (the model's wording varies between runs):
Read 9 new lines; 3 signal lines; 1 need attention.
WAKE line 5: job exited with code 1; output directory not created
Evidence: 2026-10-23T01:01:05Z job=site-build ERROR output directory was not created
Next: investigate directory permissions and retry
The second run said Quiet: no new complete lines. Model calls: 0. After I appended a routine INFO line, the third said Quiet: 1 new lines, no error signals. Model calls: 0. That is the lazy payoff I can verify: unchanged or harmless input needs neither my attention nor an inference request. I have not measured time saved over weeks of real use.
Code
quietline
Sleep through recovered warnings; wake up for the failures that still need you.
I check automation logs after scheduled jobs. A retryable 429 and a failed build both contain alarming words, but only the failed build needs me. quietline reads new lines from one log file, sends only signal lines and nearby context to an open-weight NVIDIA Nemotron 3.5 Lightning model, and prints unresolved failures with line-numbered evidence. When the log has no new signals, it makes zero model calls.
The Python CLI is MIT-licensed and uses the standard library. The model weights are available from NVIDIA on Hugging Face; the default endpoint is NVIDIA's hosted NIM API, so this default setup sends redacted log excerpts to NVIDIA. You can point --endpoint and --model at a compatible service for an on-premises setup. Model availability and provider rate limits can change.
Try it
Python 3.10+ and an…
The repository was created during this challenge window. It contains the MIT-licensed CLI, the synthetic log, a script that captures and renders the demo, and three focused tests for cursor handling, secret redaction, and rejecting invented line numbers. The CLI itself has no package dependencies.
export NVIDIA_API_KEY=...
python quietline.py demo/sample.log --state .quietline-state.json
python quietline.py demo/sample.log --state .quietline-state.json
How I Built It
The program stores a byte offset and a hash of the log prefix. It waits for a complete line; if the file is rewritten or rotated, it reads from the beginning. Only new lines matching words such as error, warning, timeout, or 429 go to the model, along with neighboring lines. That context is essential: a 429 followed by a successful retry is a different incident from a 429 followed by a failed job.
The model is NVIDIA Nemotron 3.5 Lightning 30B A3B, an open-weight model. I called it through NVIDIA NIM for this demo. The model's role is semantic triage: a regex can find an error word, but it cannot reliably decide whether later lines show recovery. Code handles the cursor, evidence, and output checks. If the API fails or the model returns invalid JSON, the cursor is not advanced, so the same lines can be retried.
I first tried an older model ID from a previous project; the endpoint returned 404. The listed Gemma 4 endpoint timed out during a probe. Nemotron 3.5 Lightning returned a useful result once I disabled its reasoning output for this short JSON task. This is a practical reason to keep the model ID and endpoint configurable rather than hiding them in the code.
Why Does Open Innovation Matter?
The project needs a model that can read the meaning of a short log sequence, not just match a token. Using open weights means the triage logic is not tied to this hosted API: someone with the hardware can serve the model themselves and keep log excerpts on their own infrastructure. My demo uses NVIDIA's hosted endpoint, so I do not claim that the demo was offline or private.
The CLI redacts common token and password patterns before sending excerpts, but that filter is best effort. I would review any sensitive logs before using a hosted endpoint. I also would not replace exit-code monitoring with this tool: the signal filter can miss unusual failures, and the model can misclassify one. quietline is a calmer digest, not a guarantee that a job is healthy.
Top comments (0)