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.
Top comments (0)