Anurag Singh replaced five Python scripts (backup, organizer, renamer, cleaner, watchdog) with a local LLM agent, which made errors the scripts didn't (wrong directories, skipped steps, false success reports).Each of the original scripts followed explicit rules through a scheduler; the agent instead added a longer inference chain (inspect, interpret, choose a tool, build a command, execute, review) to tasks that fixed logic already described completely, while also holding a loaded model in memory between runs.
- AutomationBench scores for frontier models remain well under 20%: GPT-5.6 Sol 18.1%, GPT-5.5 12.9%, Claude Opus 4.8 15.5%, Gemini 3.5 Flash 14.5%
- Granting an LLM system-level access creates a prompt-injection vector: a malicious file on disk could carry instructions the agent interprets as commands
- Singh's proposed fix: let the agent classify and route ambiguous requests, then hand off to a validator + fixed script for the actual filesystem action
- The five original scripts covered photo backup, extension-based Downloads sorting, file renaming, app-cache clearing, and a disk-threshold alert
- AutomationBench scores for frontier models remain well under 20%: GPT-5.6 Sol 18.1%, GPT-5.5 12.9%, Claude Opus 4.8 15.5%, Gemini 3.5 Flash 14.5%
- Granting an LLM system-level access creates a prompt-injection vector: a malicious file on disk could carry instructions the agent interprets as commands
- Singh's proposed fix: let the agent classify and route ambiguous requests, then hand off to a validator + fixed script for the actual filesystem action
- The five original scripts covered photo backup, extension-based Downloads sorting, file renaming, app-cache clearing, and a disk-threshold alert
Anurag Singh replaced his home lab cron scripts with Qwen3.5 9B using an agent harness with shell access. He expected contextual reasoning to be superior to rigid automation. The local model succeeded in identifying ballooned directories or judging if a container restart was needed, but it failed more often, sometimes stalling or silently skipping checks.He concluded that deterministic scripts remain the more dependable choice for routine tasks and pointed to n8n as a sensible middle ground when the friction is writing and maintaining code rather than the logic itself.
- A 9-billion-parameter local model needs several GB of RAM just to load weights, which is painful on a home server already running Docker, DNS, and other services.
- Singh's specific hardware ceiling: roughly 14B parameters on a 16 GB MacBook, maybe 32B on an M5 Pro, beyond which you need a dedicated rig.
- His suggested hybrid: let the local model read an error log and draft a short explanation, then have n8n relay that summary without granting the model permission to restart or modify anything.
The model's failure mode was not wrong commands but an inconsistent process—the same prompt and the same system state, yet different execution paths on successive runs.
- A 9-billion-parameter local model needs several GB of RAM just to load weights, which is painful on a home server already running Docker, DNS, and other services.
- Singh's specific hardware ceiling: roughly 14B parameters on a 16 GB MacBook, maybe 32B on an M5 Pro, beyond which you need a dedicated rig.
- His suggested hybrid: let the local model read an error log and draft a short explanation, then have n8n relay that summary without granting the model permission to restart or modify anything.
The model's failure mode was not wrong commands but an inconsistent process—the same prompt and the same system state, yet different execution paths on successive runs.
This XDA Developers article by Anurag Singh explains how a **CLAUDE.md** file at the root of a repository solves the problem of Claude Code repeatedly asking the same setup questions in every new session.
**The problem:** Each Claude Code session starts with a fresh context window, so it has no memory of previous conversations. It must re-inspect the repo and re-infer project conventions (package manager, test commands, directory rules, etc.), wasting time and tokens—and sometimes reaching different conclusions.
**The solution:** A `CLAUDE.md` file that Claude Code automatically loads at the start of every session. It acts as a persistent onboarding document containing:
- **Commands** (e.g., "Use pnpm," "Run `pnpm test` before completing a task")
- **Project structure rules** (e.g., "Reusable components go in `src/components/`," "Do not edit `src/generated/`")
- **Working rules** (e.g., "Reuse existing components," "Ask before installing a dependency," "Make the smallest change required")
**How to create it:** Either write it manually or run `/init` inside Claude Code, which auto-generates a starting file from the repo. If one already exists, `/init` suggests changes rather than overwriting.
**Best practices:**
- Keep it under ~200 lines (treat as a ceiling, not a target).
- Be specific—avoid vague instructions like "write clean code."
- Don't duplicate content Claude can discover by reading the repo (don't make it another README).
- Watch for conflicting rules across multiple instruction files.
**File hierarchy:**
| File | Scope |
|---|---|
| `~/.claude/CLAUDE.md` | Global, all projects |
| `CLAUDE.md` (repo root) | Project-level, commit to version control |
| `CLAUDE.local.md` | Personal, add to `.gitignore` |
The author notes that Claude Code's built-in "auto memory" is unreliable for critical rules because Claude decides what to save there; a hand-written CLAUDE.md is exact and shareable.
**The problem:** Each Claude Code session starts with a fresh context window, so it has no memory of previous conversations. It must re-inspect the repo and re-infer project conventions (package manager, test commands, directory rules, etc.), wasting time and tokens—and sometimes reaching different conclusions.
**The solution:** A `CLAUDE.md` file that Claude Code automatically loads at the start of every session. It acts as a persistent onboarding document containing:
- **Commands** (e.g., "Use pnpm," "Run `pnpm test` before completing a task")
- **Project structure rules** (e.g., "Reusable components go in `src/components/`," "Do not edit `src/generated/`")
- **Working rules** (e.g., "Reuse existing components," "Ask before installing a dependency," "Make the smallest change required")
**How to create it:** Either write it manually or run `/init` inside Claude Code, which auto-generates a starting file from the repo. If one already exists, `/init` suggests changes rather than overwriting.
**Best practices:**
- Keep it under ~200 lines (treat as a ceiling, not a target).
- Be specific—avoid vague instructions like "write clean code."
- Don't duplicate content Claude can discover by reading the repo (don't make it another README).
- Watch for conflicting rules across multiple instruction files.
**File hierarchy:**
| File | Scope |
|---|---|
| `~/.claude/CLAUDE.md` | Global, all projects |
| `CLAUDE.md` (repo root) | Project-level, commit to version control |
| `CLAUDE.local.md` | Personal, add to `.gitignore` |
The author notes that Claude Code's built-in "auto memory" is unreliable for critical rules because Claude decides what to save there; a hand-written CLAUDE.md is exact and shareable.
Anurag Singh details seven small Python scripts designed to automate common tasks and improve productivity on both Mac and Windows machines:
**Script Name** | **Purpose** | **Key Features/Notes** |
|---|---|---|
| **Inbox Cleaner** | Cleans email inbox | Archives or deletes emails older than a specified number of days. Works with IMAP, compatible with most email providers. |
| **S3 Backup** | Backs up files to cloud storage | Uploads files to an S3-compatible storage provider. Minimalist, suitable for daily/weekly backups. |
| **Screenshot Sorter** | Organizes screenshots | Finds screenshots, sorts them by date into a tidy folder structure. Includes a dry-run mode. |
| **Bulk Rename** | Renames multiple files | Renames files using patterns or sequentially. Uses regular expressions for advanced renaming. |
| **Arrange It** | Organizes files into folders | Moves files into categorized folders based on their extension (Images, Docs, Spreadsheets, etc.). |
| **Clipboard Save** | Saves clipboard history | Saves every new clipboard item to a daily text file. Creates a personal history of copied text. |
**Script Name** | **Purpose** | **Key Features/Notes** |
|---|---|---|
| **Inbox Cleaner** | Cleans email inbox | Archives or deletes emails older than a specified number of days. Works with IMAP, compatible with most email providers. |
| **S3 Backup** | Backs up files to cloud storage | Uploads files to an S3-compatible storage provider. Minimalist, suitable for daily/weekly backups. |
| **Screenshot Sorter** | Organizes screenshots | Finds screenshots, sorts them by date into a tidy folder structure. Includes a dry-run mode. |
| **Bulk Rename** | Renames multiple files | Renames files using patterns or sequentially. Uses regular expressions for advanced renaming. |
| **Arrange It** | Organizes files into folders | Moves files into categorized folders based on their extension (Images, Docs, Spreadsheets, etc.). |
| **Clipboard Save** | Saves clipboard history | Saves every new clipboard item to a daily text file. Creates a personal history of copied text. |
