Abstract
A small Python script that recursively scans a directory, extracts readable file content, and sends each file to a configurable OpenAI-compatible local LLM endpoint with a custom analysis prompt. The design separates scanning logic from the analysis instruction, making it a reusable local-first triage pipeline rather than a one-off experiment.
1. What This Is
A deliberately minimal tool for experimenting with local LLM integration. It walks a target directory, reads supported file content, and applies a user-defined prompt to each file via a standard chat/completion API. The model name and server URL are parameters, so the script is not locked to a single provider — LM Studio was the example backend in the repository, but any OpenAI-compatible endpoint works.
2. How It Works
The pipeline is a straight five-step loop with no branching. Each file is processed independently; there is no cross-file context or aggregation step.
| # | Stage | Input | Tool | Output |
|---|---|---|---|---|
| 01 | Directory scan | Target path | Python filesystem walk | File list |
| 02 | Content extraction | File list | Python file I/O | Per-file text |
| 03 | Prompt assembly | File text + instruction | String concatenation | API payload |
| 04 | Model inference | API payload | OpenAI-compatible endpoint (LM Studio) | Analysis response |
| 05 | Result collection | Responses | Python | Per-file output for review |
3. Implementation Notes
3.1 Configurable endpoint
The model identifier and server URL are runtime parameters, not hardcoded constants. Pointing the script at a different OpenAI-compatible server requires only a config change, no code edit.
3.2 Prompt separation
The analysis instruction is a standalone string passed into the loop, not embedded in the scanning logic. Swapping the prompt changes the task — classification, summarization, flagging — without touching the pipeline code. This is the pattern I later reused in repository-understanding and agent tooling projects.
3.3 Local-first design
No cloud dependency by default. Files stay on the machine unless the user explicitly configures a remote endpoint. This made it useful for learning the OpenAI-compatible API surface without incurring per-token costs or sending sensitive file contents to a third party.
4. Constraints
-
Sequential, no batching
Each file is sent individually with no concurrency. A directory of 200 files means 200 serial API calls; wall-clock time scales linearly with file count.
-
Text-only extraction
The script reads supported text content. Binary formats such as PDFs, images, or spreadsheets are skipped; there is no format-detection or parsing layer.
-
Free-form output
The LLM response is unstructured text. There is no JSON schema, validation, or parsing step, so downstream automation would need an extra layer.
-
No caching or resume
Re-running the script re-processes every file from scratch. For large directories or expensive local inference, this wastes compute on unchanged files.
5. Next
- a. Add concurrent requests via a thread pool so large directories do not serialize on the model.
- b. Introduce a lightweight JSON output schema so downstream scripts can consume triage results without regex.
- c. Add file-type filters and a dry-run mode to preview which files would be sent before hitting the endpoint.
— end of report —