analyze_log_file does the whole chain in one call — filter, deduplicate, analyse, write, file — and hands back a job id, because the model work takes minutes rather than seconds. Run it in preview mode first: it shows you the issues it would open before your repository gets them.
A server that reads a log file on your disk, filters it down to its errors, groups the repeats, has a locally-run model write up each distinct failure, and files those write-ups as issues in a repository you nominate.
- A large log file cut down to its error lines before any model sees it
- Repeated events fingerprinted and deduplicated, so one recurring failure becomes one issue rather than hundreds
- Analysis against a model running on your own machine — raw log content stays on it
- Issues written with a root cause and a suggested fix, filed into your repository, with ones that already exist skipped
- A preview mode that composes the issues and shows them to you without filing anything
- Long runs handled as background jobs: the call returns a job id straight away and you poll it
- Classification rules kept as plain-English files you can edit, so the analysis learns your own stack's error patterns
A GitHub personal access token with repository scope for the account whose repo receives the issues, a local model runtime with the model already pulled, and ripgrep. It documents macOS on Apple Silicon and wants a machine with plenty of memory, since the model runs beside your work. Setup is clone-and-build: make a Python virtual environment, install the dependencies, then point your client at the server script.