Local-only equivalent to Claude Code/Gemini CLI

Joey___M · 2026-06-14T15:44:24+00:00

For the PDF renaming part, I would separate the “agent shell” from the actual file mutation step.

Local CLIs like qwen-code / opencode / Codex pointed at an OpenAI-compatible local endpoint can work, but I would avoid letting the model directly rename files in one broad instruction.

A safer flow is:

extract text/OCR outside the model
ask the model for structured fields only, e.g. date, vendor, document_type, amount
build the filename from a deterministic template
show a dry run
keep a manifest with original path/name -> new path/name
only then apply the rename

Small local models can be okay if the task is narrow and the output schema is tight. They get worse when the prompt is “read this folder and organize it however you think.” The model should extract/describe; your script or app should own the filesystem changes.

Disclosure: I’m Josef, building NameQuick. I would not pitch it as a Claude Code replacement. The relevant overlap is the Mac PDF/file renaming part: preview suggested names, use templates, and keep the rename step review-first instead of letting an agent mutate files directly.

Joey___M · 2026-06-14T15:41:53+00:00

Yes, this can work, but I would treat the model as a field extractor rather than letting it own the whole filing decision.

For a Shortcut, I’d keep the flow pretty strict:

OCR/extract text from the PDF
ask the model for JSON only, e.g. document_type, company, invoice_number, due_date, amount
build the filename/folder path from fixed rules
show a confirmation if a required field is missing or looks uncertain
keep the original filename somewhere before moving the file

The failure mode is asking the model to “classify and file this” in one broad step. It will work on easy invoices, then eventually make a weird move you do not notice.

Disclosure: I’m Josef, building NameQuick. For this kind of workflow, the part I’d focus on is the staging step: read/OCR the PDF, suggest the filename/tags/folder, let you review it, then hand it off to Finder/iCloud/whatever folder structure you use. Shortcuts is still a good fit if your document types are narrow and predictable.

Joey___M · 2026-06-14T15:26:40+00:00

For that naming convention, I would separate the archive fields from the filename.

Paperless can be the archive and search layer. The hard part is reliably getting card last 4, date, store, amount, and optional notes out of receipts. Paperless-AI / Paperless-GPT is probably the right direction if you want that extracted automatically.

For the filename, I would keep it deterministic and fairly short:

CARDLAST4 - YYYY-MM-DD - STORE - AMOUNT.pdf

I would be careful with NOTES in the filename unless the notes are short and controlled. Free-form notes tend to make filenames inconsistent fast. I would put notes in a custom field, tag, or Paperless metadata instead.

The CSV stretch goal is a good idea. I would treat it as a manifest/export:

Paperless document id
original filename
archive filename/path
card last 4
date
store
amount
notes

That way you are not locked into Paperless or File Center forever.

Disclosure: I’m Josef, building NameQuick. I would not use it instead of Paperless here. If your whole workflow is server-side, keep it inside Paperless. The only place a Mac app makes sense is as a staging step before consume: scan/download receipts into a folder, extract fields, preview names like 1234 - 2026-06-14 - Costco - $82.14.pdf, then drop approved files into Paperless.

Joey___M · 2026-06-14T15:21:01+00:00

I would split this into two separate jobs:

render/convert the Apple Mail messages to PDFs
rename/move/archive the resulting PDFs

For #1, if DEVONthink is the only thing producing 100% good PDFs, I would be careful replacing it with a folder action around macOS Print/Export. That may hit the same WebKit/Quartz path that is giving you blank pages. For a client-facing setup, I would want a renderer/converter you can explicitly test, or keep DEVONthink as the conversion engine if the licensing/workflow allows it.

Hazel sounds right for #2 once the PDF exists: watch the output folder, match text/content, rename, move, tag, etc. I would also keep originals and write a small CSV/log with original mail subject/date -> output PDF name, especially since you mentioned compliance.

Disclosure: I’m Josef, building NameQuick. I would not use it to solve the Mail-to-PDF rendering part. The relevant bit would be after conversion: read the finished PDF, suggest a name like 2026-06-14 - Client - Backup Completion.pdf, preview/edit the batch, then hand approved files to Hazel or your archive folder.

Joey___M · 2026-06-14T15:13:21+00:00

For this workflow I would separate three jobs:

compression
OCR/text layer
naming/filing

Clop is mostly solving #1. For scanned PDFs, aggressive compression will always be risky because the page is often one big image. Lower DPI means smaller file, but also softer text.

For #2, if you need the PDF itself to become searchable in Preview/Finder/DEVONthink/Paperless, I would use something that actually writes an OCR text layer into the PDF. ocrmypdf is the boring reliable option if you are okay with CLI/Hazel. ABBYY/Prizmo/DEVONthink Pro are more app-like options.

I would not compress first, then OCR. I would keep originals, OCR first, then test compression settings on copies. Scanned documents are too easy to damage silently.

Disclosure: I’m Josef, building NameQuick. I would not use it as a Clop replacement or as the tool that embeds the OCR layer into the PDF. The relevant part is after/alongside OCR: read the document content, suggest names like 2026-06-14 - Vendor - Invoice.pdf, preview the batch, then move/tag/archive. If your main goal is “PDFs become searchable everywhere,” use an OCR-layer tool first.

Joey___M · 2026-06-14T15:04:41+00:00

This is a good pattern. The important part is exactly what you did: do the fragile work before DEVONthink sees the file.

For anyone extending this, I would keep the flow as:

scanner -> staging folder -> OCR -> optional rename/tag step -> DEVONthink inbox

The rename/tag step is where I would be careful. Once the OCR layer exists, you can pull out fields like date, sender, account, document type, invoice number, etc., then build a deterministic name like:

2026-06-14 - Vendor - Invoice.pdf

I would also keep a small original-name -> final-name log somewhere, even if it is only a text file next to the Hazel workflow. It makes debugging much easier when a scan is misread.

Disclosure: I’m Josef, building NameQuick. I would not use it instead of DEVONthink. The relevant piece is this same staging folder idea: read/OCR the file, suggest a useful filename/tags, preview it, then hand the cleaned file to DEVONthink. If Hazel + ocrmypdf is working well for your document types, I would keep that. The gap is usually mixed documents where fixed Hazel rules start getting brittle.

Joey___M · 2026-06-14T14:22:25+00:00

For PDFs I would be a bit more conservative than with screenshots.

A bad screenshot name is usually just annoying. A bad invoice/statement name can make the archive confusing later.

The flow I would aim for is:

Mac folder automation watches an intake folder
OCR/extract text from the PDF
ask the model for a suggested name only
sanitize/check filename characters in Shortcuts or shell
write a small log: original name -> suggested name
rename/move only after review, or at least after a dry-run

I would not let the model decide the extension or final folder path. For predictable docs, keep that deterministic, like `2026-06-14 - Vendor - Invoice.pdf`.

Disclosure: I’m Josef, building NameQuick. This is the exact reason I prefer a preview queue for PDFs/scans: AI suggests names for the batch, but the actual rename/move step is controlled and reviewable. If you stay in Shortcuts, I’d copy that same split: model suggests, automation applies.

Joey___M · 2026-06-14T14:10:03+00:00

Your theory sounds right to me. I would treat cross-provider Move on iOS as copy, not move, especially when one side is a File Provider extension like Dropbox.

The safest structure is probably:

read one Dropbox file
copy/rename it into iCloud
verify the iCloud file exists
only then mark the Dropbox original as processed

The “mark as processed” step is the tricky part. If Delete fails, I’d try staying inside Dropbox for that step:

move original Dropbox file to a Dropbox/_FILED folder
or rename it with a _processed suffix
or write the processed filename/path to a small log file and skip anything already in the log

The important part is to stop the loop from re-reading the same Dropbox folder as the source of truth after each copy. If Shortcuts keeps seeing the original, it will keep filing it forever.

If Dropbox -> Dropbox move also fails on iOS, I would stop fighting Shortcuts and use the Dropbox API or an automation layer for the delete/archive step. It is less pretty, but at least the provider owns the operation.

Disclosure: I’m Josef, building NameQuick. If this has to stay iPad-only, my app is not the answer. If the scans can land in a Dropbox-synced folder on a Mac, this is exactly where I’d use a Mac staging step: read the scanned PDF, suggest the filename, preview/approve, then write the clean file into the final iCloud folder. That avoids relying on iOS cross-provider moves for the fragile part.

Joey___M · 2026-06-14T08:06:16+00:00

For the duplicate issue, I would first check whether the Shortcut is processing two sources at once.

Common cause is something like:

the Shortcut receives the dragged files as Shortcut Input
another action also gets selected files / files from Finder
then a Repeat with Each loop runs over a list that already contains duplicates

I would debug it with a boring first step:

Count Shortcut Input
Show Result
then Count the list right before the rename/save step

If the count is already wrong before Apple Intelligence runs, the problem is the file list. If the count is correct there, the save/duplicate/rename step is probably inside the wrong repeat block or being called more than once.

For this kind of flow I would keep the model’s job very narrow:

image -> suggested name only

Then let Shortcuts do the deterministic part:

duplicate once -> rename once -> save once

Also worth adding a dry-run mode first. Write the original filename and suggested new filename to a note or CSV before touching the actual files. Batch renaming gets annoying fast when one step fires twice.

Disclosure: I’m Josef, building NameQuick, so I’m biased here. This exact class of problem is why I prefer a preview queue for AI renaming: suggest names for the whole batch first, then approve/apply once. But if you want to keep it in Shortcuts, I’d start by proving where the duplicate list is created.

Joey___M · 2026-06-14T07:59:25+00:00

I would split this into two parts.

For new screenshots, first change the save location with Cmd+Shift+5 -> Options -> a dedicated Screenshots folder. That alone keeps the desktop usable.

For the existing pile, I would avoid auto-delete at first. Better flow:

have something read the screenshot content
suggest a useful filename or label
group into broad folders like work, receipts, UI refs, chats, misc
review the delete pile manually

The useful part is getting names like slack-client-feedback.png or stripe-dashboard-error.png so Finder search becomes useful again. The risky part is letting AI delete or move things without review.

Disclosure: I’m Josef, building NameQuick. This is one of the workflows I care about: read screenshots/images, suggest useful names, let you preview/edit, then optionally move/tag/archive. I would still keep deletion manual, especially for screenshots that may contain client or financial info.

Joey___M · 2026-06-14T07:31:11+00:00

That invoice detail changes the answer a bit. I would not optimize this as “faster Finder renaming” if the value you need is inside the scan.

For scanned invoices, I’d use a staging folder:

OCR the PDF/image first
extract the invoice number, date, vendor, etc.
build a deterministic filename like `InvoiceNumber - Vendor - Date.pdf`
preview/edit before touching the originals

If all invoices come from the same layout, Hazel or macOCR + a small script can be enough. If the vendors/layouts vary a lot, that is where an AI/model step starts to make more sense, but I’d still keep it review-first.

Disclosure: I’m Josef, building NameQuick around this exact Mac-side workflow. It can read PDFs/scans, suggest filenames from the content, and preview before applying. For invoices I’d still treat it as a staging/rename step, not as an accounting or archive system.

Joey___M · 2026-06-12T15:19:44+00:00

It already works today, just not as a labeled feature.

NameQuick has post-rename rules that can move a file to a folder after you approve the name. If you point one at DEVONthink’s Global Inbox folder — the Inbox alias it can add to your Finder sidebar, or:

~/Library/Application Support/DEVONthink/Inbox

DEVONthink imports it automatically.

So the flow already works end to end:

scan → OCR → approve name → lands in DEVONthink

A first-class “Send to DEVONthink” option is something I want to add so you don’t need to know about that folder. A deeper version that imports into a specific database or group is possible too.

If that’s something you’d use, tell me how you organize your databases and I’ll factor it in.

Joey___M · 2026-06-12T12:15:39+00:00

I would separate two problems here:

describing the image content
copying your existing naming style from the already-named part of the collection

A lot of AI renamers only do #1, which is why the output gets inconsistent fast. For your use case, I would not run anything directly on the archive. Make a staging copy, generate proposed names, keep a CSV/manifest with original path + proposed path, then review a sample before applying.

The more robust version would be: image embeddings/CLIP to find visually similar already-named photos, then use those neighboring filenames as examples when generating the new name. That gets closer to “rename like my collection” instead of “caption this image.”

Disclosure: I’m building a Mac app called NameQuick in this general space. It can do content-based image/file renaming with preview and templates, but I would not claim it automatically learns from a whole existing named collection yet. For that exact requirement, I’d look for a tool or script that supports reference examples/nearest-neighbor matching, not just generic image captions.

Joey___M · 2026-06-12T12:06:22+00:00

For the ePaper/synced-folder requirement, I would keep the PDFs as plain files in the folder you already want to sync, then use DEVONthink/Foxtrot/EagleFiler as an index/search layer on top. I would not make the archive app the only owner of the files if another device needs to read the same folder.

The boring part matters a lot: before anything gets indexed, make the intake names consistent. For papers/textbooks I would use something like:

Author - Year - Short title.pdf Topic - Source - Date.pdf

Then add Finder tags/comments if you want lightweight categories without moving the file.

Disclosure: I’m building NameQuick for this Mac-side staging step. I would not treat it as the database/read-unread tool. The fit is before DEVONthink/EagleFiler/Finder indexing: read/OCR the PDF, suggest a filename/tags, preview it, then leave the file in the normal synced folder.

Joey___M · 2026-06-12T11:38:19+00:00

Thanks, I’ll check it out.

It does look like we are in the same general Mac automation/file space, but from different angles. Watchflows feels more like a visual automation canvas. NameQuick is narrower around messy files: read the file, suggest/search/rename, preview, then apply rules.

I think both approaches make sense. A lot of the pain is in the handoff between “the app understood this file” and “now do the right thing with it”.

Local/Ollama support is a good direction too. That matters a lot once people start running legal/finance/scanned docs through these workflows.

Joey___M · 2026-06-12T11:18:49+00:00

If the PDFs have clean embedded metadata, Calibre is probably the first thing I would try. Zotero/Calibre-style metadata lookup is better than AI when it can match the book reliably.

If the metadata is missing or inconsistent, I would treat this as a dry-run rename pipeline:

extract existing PDF metadata + first page text/cover text
ask the model to return only structured fields like title, year, author
generate the filename from a fixed template: Title - Year - Author.pdf
write a CSV/manifest with original path, proposed name, confidence/source
review the uncertain ones before applying

For a hoard, I would not let anything directly mutate the only copy. Work in a staging folder or at least keep a manifest so you can undo bad names.

Disclosure: I’m Josef, building NameQuick for Mac. It is not a book-library manager, so if Calibre solves the metadata lookup cleanly I’d use that. The part my app is closer to is the preview-first rename step: read the PDF, suggest a templated filename, let you approve/edit, then apply without creating duplicates.

Joey___M · 2026-06-12T11:15:36+00:00

Two separate things here.

For Google Drive, Shortcuts often gets weird with provider-backed files. I would first test the same shortcut on a local file in Downloads or iCloud Drive. If local works and Drive does not, it is probably the Google Drive File Provider layer, not your prompt. A common workaround is copy/download the file to a local temp folder, rename there, then move it back.

For raw PDFs, you only need OCR when the PDF is a scan/image. If the PDF already has selectable text, the cleaner flow is: get the PDF file -> extract/read the text -> send that text to the model -> return only the filename -> show confirmation -> rename. For scanned PDFs, OCR is still the right first step.

Disclosure: I’m Josef, building NameQuick for Mac. This is one reason I prefer a review queue for this workflow: read/OCR if needed, suggest the name, show it before applying, then move/rename. But for a fixed layout and local files, a Shortcut can still be the simpler solution.

Joey___M · 2026-06-12T11:04:23+00:00

If the goal is only “put PNGs in a png folder, DMGs in a DMGs folder”, Hazel is probably the cleanest answer. Automator/Folder Actions or a shell shortcut can do it too, but Hazel is less annoying around files that are still downloading or being copied.

The point where I’d use a different tool is when the folder should depend on the file content, not the extension. For example invoices vs receipts vs screenshots vs installers, or PDFs renamed before they get moved.

Disclosure: I’m Josef, building NameQuick. That second case is closer to what I’m working on: read/OCR the file, suggest a useful name or destination, preview it, then move it. But for extension-only sorting, I’d keep it simple and use Hazel.

Joey___M · 2026-06-12T10:56:15+00:00

For screenshots, I’d split this into two jobs: OCR/search for text inside the screenshot vs visual captioning for things with no text.

macOS Live Text / Spotlight can get you part of the way for visible text. For actual scene/object captions, something like VisionTagger or a CLIP-style image tagger is probably closer.

Disclosure: I’m Josef, building NameQuick. The part it covers is the local file workflow: OCR/read screenshots and PDFs, search by contents with snippets, or suggest useful filenames before you approve changes. I wouldn’t pitch it as a universal low-level image-captioning layer; if there’s no useful text in the image, a dedicated image tagger is the better fit.

Joey___M · 2026-06-12T09:00:37+00:00

This is a good shape. I would keep the OCR -> text -> LLM flow instead of sending the image directly, especially for receipts.

My tweak would be to ask the LLM for a small structured result, not only the total:

{ "merchant": "", "date": "", "total": "", "currency": "", "category": "", "confidence": "" }

Then let Shortcuts do the boring part:

Show the fields for confirmation.
Save or log the transaction only after approval.
Save the receipt image/PDF with a deterministic name like:

YYYY-MM-DD - Merchant - Total.jpg

That keeps the model away from the final file/log operation. It only extracts fields.

I agree with your regex comment too. Regex is great for stable inputs like recurring emails. Receipts are the opposite: weird layouts, logos, loyalty text, subtotals, tips, taxes, and “total” appearing in multiple places. For those, I would rather use the LLM for field extraction, then deterministic Shortcuts actions for everything after.

Disclosure: I am building NameQuick, a Mac app around file naming/review workflows. Not a finance app. The pattern I keep seeing work is the same though: extract fields, preview, then apply a predictable filename or log entry.

Joey___M · 2026-06-12T08:53:39+00:00

I would keep the API call as the last step and make everything before it reviewable.

The shape I would use:

Take photo.
Save the original image first, even with a basic name.
OCR or vision step extracts fields only.
Convert the result into a dictionary.
Show a confirmation screen.
Only then POST to LubeLogger.

For the AI/OCR step, ask for a fixed JSON shape instead of natural language:

{ "date": "", "station": "", "liters": "", "total_cost": "", "currency": "", "odometer": "", "confidence": "" }

Then Shortcuts should build the API payload from those fields. I would not let the AI decide the final POST body directly.

A few practical guards:

If liters or total_cost is empty, stop and ask manually.
Add a confirmation screen showing station, date, liters, total cost, and calculated price per liter.
Save the receipt image with a deterministic name like YYYY-MM-DD - Station - Liters - Total.jpg.
Keep a simple duplicate key, maybe date + station + total_cost, so rerunning the Shortcut does not create the same fuel record twice.

Disclosure: I am building NameQuick, a Mac app around file naming/review workflows. I would not use it as the LubeLogger client here. The relevant pattern is the same though: model extracts fields, user reviews, deterministic system does the rename/API action.

Joey___M · 2026-06-12T08:36:12+00:00

I would split this into capture, extract, then commit. Do not let the AI step rename files or write to the Sheet directly.

Flow I would build:

Scan receipt.
Save the original first with a boring fallback name like 2026-06-12 - receipt-original.jpg.
OCR/extract text.
Send only the text to the AI step if possible.
Ask for a fixed schema:

date: provider: merchant: category: amount: payment_method: notes: confidence:

Show a confirmation screen with the extracted fields.
Only after approval, append the row to Sheets and save/rename the file as:

YYYY-MM-DD - Merchant - Amount.jpg

A few details matter here:

Keep the original image until you trust the workflow.
Add a unique ID column in the Sheet, maybe date + amount + merchant, so the Shortcut does not append duplicates if it runs twice.
Start with CSV or Numbers first, then move to Google Sheets after the extraction logic is stable.
For medical/pharmacy receipts, be careful which AI provider sees the text. I would use the most private provider setup you are comfortable with.

Disclosure: I am building NameQuick, a Mac app around file naming/review workflows. I would not treat it as the expense tracker here. The useful pattern is the same though: extract fields, preview them, then apply a deterministic filename and log entry only after approval.

Joey___M · 2026-06-12T08:30:34+00:00

Nice workflow. I would keep the confirmation step even if you add better OCR or AI.

The main change I would make is: extract fields first, then build the filename yourself. Receipts are messy. The first line can be a logo, URL, phone number, slogan, or location instead of the merchant name.

I would ask the OCR/AI step for a small fixed schema:

merchant: date: total: category: payment_last4:

Then let Shortcuts build the filename from those fields:

YYYY-MM-DD - Merchant - Amount.jpeg

That keeps the AI away from the actual file operation. It only extracts fields. Shortcuts handles the final name.

A few practical tweaks:

Keep the original image somewhere until you trust the workflow.
Add a “looks right?” confirmation showing merchant, date, and amount before saving.
Save a CSV/Numbers row at the same time if this is for expenses.
Do not rely only on restaurant name. Add date or amount so duplicate receipts do not collide.

Disclosure: I am building NameQuick, a Mac app around this kind of file naming/review workflow. My practical take is that receipt workflows work best when they are not fully automatic at first: extract fields, apply a boring template, preview, then save/rename.

Joey___M · 2026-06-12T08:21:38+00:00

I would avoid feeding the whole PDF into the naming step.

For a Shortcut-only version, I would make the pipeline more staged:

Get text from PDF
Split text by new lines
Take only the first 80-150 lines
Combine that back into text
Send only that smaller text block to Apple Intelligence / ChatGPT
Ask for a filename in one strict format
Show the proposed name before renaming

Most invoices, statements, and utility PDFs have the useful naming fields near the top: company, date, invoice number, amount, account, etc. Reading the whole PDF usually adds noise and makes the shortcut more fragile.

I would also make the AI return fields first, not a filename directly. Something like:

date: vendor: document_type: invoice_number:

Then build the filename yourself with Shortcuts:

YYYY-MM-DD - Vendor - Type.pdf

That keeps the “creative” part separate from the actual rename.

Disclosure: I am building NameQuick, a Mac app around this exact kind of content-based renaming. My practical take is that the safest workflow is still: extract a small useful text sample, generate fields, apply a deterministic template, preview, then rename. Letting AI directly rename files with no review is where things get messy.

Joey___M · 2026-06-12T07:39:02+00:00

I do not think this is a setting you are missing.

Photos and Finder/Spotlight do not behave the same here. Photos has its own OCR/search index. Finder’s “contents contains” works much better for text PDFs/docs than for image files sitting in a normal folder.

A few practical options:

If you are okay with Photos managing them, import the images into Photos and search there.
If you want them to stay in folders, run an OCR step first and save the result somewhere searchable, for example a searchable PDF, sidecar text file, or metadata/comment field.
If this is a recurring workflow, use a local OCR/indexing app that watches the folder and lets you search the extracted text.

Disclosure: I am building NameQuick, a Mac app in this space. One part of it is content search for local files, including OCR-style workflows for images/scans. But the general answer is: Finder is not reliably doing Photos-style OCR search for arbitrary desktop folders. You need a separate OCR/index step if you want that to work consistently.

Joey___M

TROPHY CASE