I Used Claude to Build a Tool So I'd Stop Using Claude

I had a small but clarifying moment this week.

I was about to type “can you rename all these files by replacing the spaces with underscores” into Claude — and I caught myself. That's a terrible use of a frontier model. It's like calling a senior consultant to move boxes. The capability is there, but the cost-to-task ratio makes no sense.

So I did something different. I asked Claude to help me build a tool that I'd never have to ask Claude again.

The Problem With Asking Claude to Rename Files Every time you send a message to Claude, you're spending tokens. For simple, repetitive file operations — renaming, reorganising, cleaning up — that's wasteful. Claude's real value is in reasoning, writing, and building things. Not shuffling filenames.

What I wanted was a local tool I could run from anywhere, that understood plain English, and that didn't phone home to any cloud service every time I needed to clean up a folder.

What I Built The tool is called Ollama File Renamer. Here's how it works:

You type a plain English instruction — “replace all spaces and dashes with underscores” or “add today's date before the extension”

It sends that instruction plus your file list to a local LLM running on Ollama You get a preview table showing exactly what will change. You confirm, and it executes.

No cloud. No API costs. No data leaving your machine. And critically — no Claude involved at runtime.

I used Claude to write the code once. Now Ollama and a local model handle every rename job after that. That's the right division of labour.

The Key Idea: Build Once, Run Locally Forever This is something I'm thinking about more deliberately. Claude — or any frontier model — is genuinely useful for the building phase. Reasoning through architecture, writing clean code, debugging edge cases, drafting documentation. That's where the reasoning capability earns its cost. But for execution of repetitive tasks? Local models on Ollama are fast, private, and free to run as many times as you want. The right move is to use the expensive model to create the tool, then hand off the actual work to something local.

It's a small mindset shift, but it changes how you think about AI in your workflow. You stop treating Claude like a command line and start treating it like an architect.

It's Not Perfect Yet

The tool has a known quirk: if you ask it to add “today's date,” smaller models sometimes return a literal placeholder like _YYYY-MM-DD instead of the actual date. I'm working on a fix that injects the real date into the prompt before it reaches the model — so it gets a concrete instruction, not an ambiguous one.

The code and full setup instructions are on GitHub: Ollama File Renamer

You'll need Ollama installed and any model pulled locally. One line in the config to point it at whichever model you're running. That's it.

What Model Should You Use? I've been running it on gemma4:e2b. It's fast and handles straightforward rename instructions well. For more complex or ambiguous instructions, a larger model like gemma3:27b or qwen2.5:14b will give you more reliable structured output.

I'm curious — how are you currently deciding which tasks go to a frontier model versus a local one? I'm still building out my own mental model for where the line sits.