What changed across Social Archiver

The macOS CLI archives now carry the Apple Intelligence helper (social-archiver-applefm). Run social-archiver executor on an Apple silicon Mac with macOS 26 or newer and Apple Intelligence on, and apple shows up among the providers: summaries, key points, glossary, reformat, translation, tag suggestions and place extraction run on the model inside the Mac — no account, no credits, nothing leaves the machine. Fact check and transcript translation stay with the cloud providers. The model holds 4,096 tokens, so a post that is too long is refused up front. Homebrew (brew upgrade social-archiver-cli), npm and the install script all place the helper beside the CLI. It is the same helper the desktop app bundles, so it behaves the same.

• social-archiver executor can run on Apple Intelligence (macOS 26+, Apple silicon): on the Mac, no account, no credits.
• social-archiver executor --providers lists apple, with the reason when it is not ready (model downloading, Apple Intelligence off, and so on).
• Fact check and transcript translation are excluded; a post over 4,096 tokens is refused up front.
• The helper must sit beside the CLI. Homebrew, npm and the install script do that; for a manual install keep both files in one folder.
• Nothing changes for the Windows and Linux builds.

When the CLI runs as an executor and Codex (ChatGPT) refuses a request, all you got was "AI action failed." Codex writes its reason to its JSON output rather than the error stream, so the reason was dropped. The CLI now reads that line and reports it as a model problem, so when you ask for a model your account can no longer use, you see what went wrong. The outage itself — since about September 8, Codex on a ChatGPT account no longer offers gpt-5.4-mini, so every summary failed — was fixed on the server by defaulting to gpt-5.5, so summaries work again even before you update.

• A refusal now carries the reason Codex printed.
• Asking for a model you can no longer use is classified as a model problem.
• The failing-summaries outage was already fixed on the server.

When you run the CLI as an executor, AI comments are generated right on your machine. But if you picked a model by alias — "sonnet" — only that alias was kept, so later there was no way to tell which version actually wrote the answer. The CLI now reads the real model name the provider reports while running and stores it alongside the comment. Ask for "sonnet" and the result keeps "Sonnet 4.5", the version that truly ran, and the same name shows up wherever you open it — mobile, desktop, or a shared page. The alias you chose is kept too, so both what you asked for and what ran are on record. Applies to comments generated from this version on.

• Comments keep the real model name even when you requested an alias.
• Both the alias you asked for and the model that ran are recorded.
• The same name appears on mobile, desktop, and shared pages.

`social-archiver executor --watch` asked the server three separate questions every 15 seconds to find out whether any work was waiting — even though an executor spends most of its time simply idling. While idle it now asks once and gets all three answers together, and only falls back to the per-kind checks when there is actually work. How jobs are claimed and run is unchanged, so nothing behaves differently — there are just fewer check-in requests. If the server cannot answer the combined check, or the answer looks off, it quietly runs the old checks instead, so no job is missed.

• The idle check-in went from three requests every 15 seconds to one. Nothing about running jobs changed.
• When work is actually waiting, the per-kind checks and the run path proceed exactly as before.
• If the combined check is unavailable or the answer looks off, it falls back to the old checks on its own.

Two fixes. First, on Windows `executor --watch` crashed with a runtime panic right after CLI detection — resolved by changing how tool version checks spawn subprocesses. Second, we found the real reason AI summary jobs failed with PROVIDER_MISSING while detection looked perfectly healthy: the job details the executor fetched from the server were missing which AI to use (the provider). The server is fixed alongside this release, so already-installed 0.1.9/0.1.10 and the desktop app work again without updating.

• Fixed executor --watch crashing right after detection on Windows — watch mode now runs to completion.
• AI jobs no longer arrive from the server without their provider — fixed server-side too, so existing installs recover immediately.
• The executor now sends its client ID when fetching job details, so it always receives the complete job.

The executor could report an installed Claude, Gemini or Codex CLI as "not installed", and AI summary jobs then failed with PROVIDER_MISSING. The cause: it only checked a few well-known install locations — native installers, nvm, volta and scoop put the CLI elsewhere, which is exactly what hit Claude Code and Codex on Windows. Now, if the command runs in your terminal, the executor finds it too. Alongside that, an AI job that fails on one machine is no longer dead: another executor on your account (the Obsidian plugin or the desktop app) can pick it up and finish it.

• AI CLI detection now resolves commands the same way your terminal does — native installers, npm, nvm/volta/fnm and scoop layouts are all recognized.
• Fixes Claude Code and Codex going undetected on Windows, where previously only npm installs were recognized.
• An AI summary or translation job that fails on one executor is no longer terminal — another executor picks it up shortly after and completes it.
• Retries stay bounded by the server, so when no executor can handle a job it still fails clearly.

Until now the CLI could only create a subscription. Pausing one, listing them, or working out why new posts stopped arriving meant opening the app. All of that now works from the terminal, and the run history shows what each run saved, what it cost, and — when it failed — why. The same commands were added to the Obsidian plugin CLI in 4.6.6, so both behave the same way.

• List your subscriptions, pause or resume one, run it on the spot, or delete it when it has served its purpose.
• Diagnose it yourself from the run history — per-run saved counts and credits, plus the reason when a run failed.
• Pausing keeps its place, so resuming does not skip the posts from while it was off.
• Deleting requires an explicit confirmation flag, and the archives it already saved stay put.
• The Obsidian plugin CLI gained the same commands, plus place-candidate review and bulk Inbox triage (plugin 4.6.6).

A standalone tool for archiving, finding, and organizing from a terminal. It runs on Windows, macOS, and Linux with no desktop app and no Node.js required. With 0.1.5 the Microsoft Store listing completes the set of install routes, and exports now carry each archive's places and product details. The CLI guide documents every command.

• One line to install, anywhere: Microsoft Store or winget on Windows, Homebrew on macOS, a checksum-verified installer on macOS and Linux, and npm wherever Node.js already lives. No desktop app required.
• Archive and find: archive a URL, search your whole archive server-side, move posts between Inbox and Archived, and subscribe to public profiles.
• Organize locally: export archives to Markdown, grep them, add tags and notes, then push the edits back. After one export, searching costs no further server calls.
• New in 0.1.5 — exported Markdown carries places (name, address, coordinates, category) and product details (price, currency, availability, brand, rating), and the new places command reviews extracted candidates with their evidence so you can confirm or detach them.
• AI work stays in the terminal: request AI comments, run them yourself with a local AI tool through the executor, and transcribe video and audio archives.
• Built with coding agents in mind: every command answers in the same JSON shape, and an installable skill bundle teaches Claude Code, Codex, and OpenCode to drive it safely.