DEV Community: Kirill Isachenko

Local AI file renaming with Ollama or LM Studio: what to check before using it

Kirill Isachenko — Fri, 11 Sep 2026 01:04:45 +0000

To rename files locally with Zush, download a compatible model, start its local server and select that server in Zush Settings. A successful connection means the server is reachable. You still need to check whether the model can read your files and produce useful names.

I build Zush. This setup guide follows the product documentation. It includes a test you can run, but reports no local-model benchmark or network audit. The separate eight-file Zush pilot used Cloud AI and does not establish local-model performance.

Pick a model for the input

If analysis depends on screenshots, scans or page previews, use a vision-capable model. A text-only model is not a substitute simply because it produces good answers in chat.

Also check memory and disk requirements. The file extension alone does not establish that a given model and application pipeline can interpret its contents well. Test the types you actually receive.

Zush's Ollama setup documentation lists qwen2.5vl:3b as one starting option. That is a setup example, not a claim that it is the best or fastest model for every machine.

Connect Ollama

Install Ollama and download the chosen local model while online. For the documented example:

ollama pull qwen2.5vl:3b
ollama list

If the server is not already running, start it with ollama serve. In Zush, open Settings → AI Modes, choose Ollama, refresh the model list, select the installed model and run Test. The documented default host is http://127.0.0.1:11434.

Ollama also offers cloud models, as its quickstart shows. For this workflow, deliberately select a downloaded local model; using the Ollama interface by itself is not proof of local inference.

Connect LM Studio

Download a vision-capable model in LM Studio and start its server from the Developer tab. LM Studio documents that server operation in its local API server guide.

In Zush Settings → AI Modes, choose LM Studio. Confirm the host, refresh the models, choose the model and run Test. Zush's documented default is http://127.0.0.1:1234; its LM Studio guide also explains model discovery and troubleshooting.

A loopback address points to this computer. A server hosted on another machine is a different deployment, even if its API is compatible. Record the endpoint you actually use.

Test naming quality separately from connectivity

Create a small folder of copies containing a clear screenshot, a text PDF, an image-only scan and an ambiguous document. Before analysis, write down the minimum fields each filename needs.

Record:

OS and hardware:
Zush version:
Runtime version:
Exact model identifier and quantization, if available:
Endpoint:
Template and output language:
Input file types:
Original suggestions:
Manual corrections:
Unsupported files or failures:

Leave unknown values marked unknown. Do not fill them with plausible model names.

Compare the proposed names with the source files. Check whether the scan's vendor is correct, whether a date was confused with another date and whether similar files remain distinguishable. Keep the raw proposals before editing them. Note which fields you had to correct.

Check the workflow without a network connection

Download models and finish setup before disconnecting. With the local mode selected, repeat a supported-file test without a network connection and record what succeeds or fails.

That test can show whether the observed workflow works disconnected. It does not, by itself, establish that the application never makes any network request when connected. That stronger claim needs separate observation.

Zush documents supported analysis through its local modes without silent fallback to cloud analysis. BYOK is a separate option that uses a cloud provider key. The local AI overview explains the distinction.

Only enable folder monitoring after the manual batch produces useful, reviewable names. Record unsupported files and uncertain fields alongside the successful names.

What an eight-file AI renaming pilot taught us about useful filenames

Kirill Isachenko — Thu, 10 Sep 2026 05:01:35 +0000

An AI-generated filename is useful when it identifies the file, preserves the details needed to distinguish it and avoids unsupported information. In our eight-file Zush pilot, some names captured useful identifiers, while one contract title left out details we would need in a larger archive.

I build Zush. This was our own small application check, run on September 5, 2026, on macOS 26.5.2 with Apple Silicon. It was not an independent review or a representative accuracy benchmark.

What we ran

The set contained three text PDFs, an image-only receipt PDF, two text-based PNGs, a synthetic spoken WAV and an existing Zush demo MP4. The documents used fictional content.

Zush 3.11.0 (165) ran with Cloud AI and the existing Smart Title Name template. Its configured output language was Russian. We applied eight suggestions to isolated copies; SHA-256 checks confirmed that all eight files retained their original contents.

The table below contains all eight Zush outputs from the saved test record. This account evaluates those results without ranking products.

Where the names helped

For file_001.pdf, Zush applied Счет NS-1042 От Northstar Studio.pdf. In English, that means an invoice from Northstar Studio with the identifier NS-1042. It captured two useful retrieval fields: vendor and invoice number. The recorded name did not include the date.

For the image-only receipt, file_004.pdf became Чек Pine Street Cafe.pdf. The cafe name came through in the result even though the PDF had no selectable text and carried the generic metadata title "Benchmark fixture." We recorded the resulting name, not the internal processing steps.

The WAV became Обсуждение Осеннего Запуска Продукта.wav, describing a discussion of an autumn product launch. The MP4 became Демонстрация Работы Приложения AI Rename.mp4, describing an AI Rename application demonstration. These English explanations are translations for the reader; the Cyrillic strings are the recorded filenames.

Where a correct title was still incomplete

The service agreement became Соглашение Об Оказании Услуг.pdf, meaning "Service Agreement." That identifies the document type, but leaves out the parties and draft status.

In a folder containing a single agreement, it may be enough. In a client archive with twenty agreements, it is unlikely to distinguish the one you need. To evaluate the name, first decide which agreement someone needs to find.

For this file, a future test could require the parties and draft status explicitly, then check whether the configured workflow supplies them correctly. We did not run that test here.

What this pilot does not establish

Eight applied names are not an accuracy percentage. This was one pass with a small controlled set. It did not test Windows, local models, large files, naming collisions, repeated-run consistency or undo. Backend model IDs were not exposed in the observed UI.

Custom AI Blocks were not tested either. Zush documents configurable naming fields, but that capability should not be presented as a result of this run.

The content-hash check has a similarly narrow meaning: file bytes stayed unchanged for these eight applied renames. It does not establish how every downstream project would respond to changed paths.

How to make the next check more useful

Before running another batch, define the required fields for each file. Preserve the unedited proposals. Record missing fields, unsupported details, manual corrections and operational failures separately. Align templates and output languages when comparing applications.

The complete recorded Zush outputs

The following names are transcribed from the saved September 5 test record. They are the original Russian outputs, not rewritten English examples. All eight suggestions were applied to test copies.

Input	Applied filename
file_001.pdf	Счет NS-1042 От Northstar Studio.pdf
file_002.pdf	Соглашение Об Оказании Услуг.pdf
file_003.pdf	Протокол Встречи Autumn Product Launch.pdf
file_004.pdf	Чек Pine Street Cafe.pdf
file_005.png	Чек-Лист Доступности Веб-Сайта.png
file_006.png	Статистика Ежемесячных Запросов В Поддержку.png
file_007.wav	Обсуждение Осеннего Запуска Продукта.wav
file_008.mp4	Демонстрация Работы Приложения AI Rename.mp4

Source: Zush's local pilot record, ai-file-renamer-pilot-2026-09-05, including the saved application outputs and setup notes. The standalone evidence-file URL was unavailable when this article was prepared, so this table reports the recorded observations directly. The public Zush methodology provides general evaluation context; it is not the raw dataset for this particular run.

For the next run, I would check whether someone can find the requested file from its new name. Recording a rename for every input does not answer that question.

I Don’t Know Swift. I Shipped a macOS App Anyway.

Kirill Isachenko — Thu, 02 Apr 2026 12:39:00 +0000

I’m a designer. I’ve never written Swift before this year. And I now have a native macOS app on the App Store that people pay for.

This is not a flex. It’s an observation about what’s possible right now, and what’s still hard.

Update — August 2026

A lot has changed since I wrote this. Zush is now a native AI file renamer for Mac and Windows, with support for 104 file formats.

The naming system is much more flexible now. You can build reusable templates from 145+ Naming Blocks, add Custom AI Blocks for fields you want to extract, and combine them with dates, counters, metadata, separators, and case styles.

Every batch can be reviewed before applying it. If the result does not work, the original filenames can be restored from Activity history.

There are three processing options: managed Cloud AI built into the app, BYOK with your own Gemini, Groq, OpenAI, or Claude API key, and Offline AI with a local Ollama model for supported files.

The free version includes 50 renames across all three modes. Current Mac and Windows builds are available at zushapp.com.

The problem

I had a folder with 2,000 screenshots named Screenshot 2024-11-03 at 14.22.57.png. My photo library was all IMG_4382.jpg. I wanted an app that would look at these files, understand what's in them, and rename them to something searchable.

Apps like this exist. I tried all of them. They all look like they were designed in 2009. But the worse part wasn’t even the design — it was the speed. I’d drag in 10 files and wait. And wait. Some tools took seconds per file. I genuinely couldn’t understand how people were paying for this. If your AI-powered renamer is slower than me renaming files by hand, something has gone wrong.

So I decided to build my own.

The app is called Zush. It uses AI to analyze supported file content and metadata, then proposes descriptive filenames. On Mac it can add Finder tags and Spotlight metadata, and folder monitoring can process new files as they arrive. The Mac app is native Swift/SwiftUI; the Windows version is a separate native app.

Vibe-coding is real, but incomplete

The app was largely vibe-coded. Claude Code and Codex wrote most of the Swift. I shaped the UX and made sure everything felt native.

This worked surprisingly well for about 80% of the work. The last 20% is where it gets interesting.

AI can scaffold a networking layer in minutes. It cannot debug why your folder monitoring feature renames the same file 47 times because of a race condition. It doesn’t understand that a subtle layout shift on Sonoma doesn’t happen on Sequoia. These are the things you still have to reason about yourself.

The path of least resistance problem applies here too. The model will happily fix a symptom in the UI when the root cause is three layers deeper. You have to know enough to ask the right questions. “Fix this bug” and “find the root cause of this bug” produce very different results.

Still — a designer with zero Swift experience shipping a native macOS app in about two months. That’s new. The tools made it possible.

From one cloud provider to three processing modes

At launch, the managed cloud path used Groq with Llama models because speed and cost mattered for batch renaming. That was the right starting point, but it was too narrow as a long-term setup.

Zush now offers three processing modes: managed Cloud AI built into the app, BYOK with Gemini, Groq, OpenAI, or Claude, and Offline AI with a local Ollama model for supported files.

BYOK gives users control over the provider and model they pay for. Offline AI is for supported workflows that should stay on the machine. Both are available within the same 50-rename free allowance; PRO removes the rename limit across every mode.

Flexible naming rules, templates, and Custom AI Blocks

One feature I’m particularly happy with is the naming system. Instead of accepting a rigid AI-generated title, users can build reusable Templates from 145+ Naming Blocks: dates, counters, metadata, original filename elements, separators, case styles, and other structured fields.

Custom AI Blocks cover the details that are not already available as metadata. You describe the field you want Zush to extract, then reuse that block inside any Template.

A photographer can combine the date, camera model, and an AI-generated description. An accountant can extract a vendor or invoice number. A legal team can include a document type, party, or date. The same app follows a different naming convention for each workflow.

Pricing changed as the product changed

The first version of this post described an earlier one-time pricing experiment. That pricing is no longer current.

The free version now includes 50 renames shared across managed Cloud AI, BYOK, and Offline AI. Zush PRO costs $10 per month or $48 as a one-time lifetime purchase. Both PRO options remove the rename limit across all three processing modes.

I kept the one-time option because many utility users prefer to buy a tool once. The monthly option is there for people who prefer a lower upfront cost.

Automating releases as a solo dev

When you’re one person, you’re the entire company. Every manual process is a tax on your time.

I fully automated the release pipeline for both the direct download and the App Store. Push a git tag, CI builds, signs, notarizes, and ships. The App Store version goes through TestFlight. The direct build updates via Sparkle with delta updates.

I push a tag and make tea. By the time it’s ready, both versions are live. This took significant effort to set up, but the ROI is immediate when you’re shipping updates weekly.

Design as competitive advantage

Every competitor I evaluated treats design as an afterthought. This makes sense — they’re built by developers optimizing for functionality.

But on macOS, users expect things to feel native. Smooth animations, proper spacing, keyboard shortcuts that behave like every other Mac app. The difference between “this works” and “this feels right” is measurable in retention, even if it’s hard to quantify upfront.

I spent more time on how drag-and-drop feels than on some entire features. That’s a luxury of being a designer who also ships the product. You don’t have to convince anyone that the animation curve matters. You just fix it.

Photographers turned out to be the most excited audience. Zush now supports 104 file formats in total, including common RAW camera formats, and naming templates can include EXIF and other metadata fields. The niche within the niche was the real market.

What came next

The Windows version shipped. It is a separate native Windows app rather than a wrapper around the Mac build.

The models keep getting faster and cheaper. What used to require a larger team and significant infrastructure is now practical in a desktop tool built by a solo developer.

I don’t think this is unique to me. The tools are there for anyone with domain expertise and a problem worth solving. The hard part was never only the code. It was knowing what the product should feel like.

Zush is available for Mac and Windows at zushapp.com.