[zzerbzz]

What

Adds a local Ollama usage provider, following the exact pattern of the existing local providers (LocalClaudeProvider, LocalCodexProvider, …):

• LocalOllamaUsageProvider.swift — LocalOllamaProvider: UsageProvider (id "ollama", displayName "Ollama", reportsCost = false, since local inference is free). It reads a JSONL ledger and reuses LocalUsageReader for daily totals, active-block, and week/month enrichment — no new counting logic.
• UsageStore.swift — registers LocalOllamaProvider() in the provider list.
• CustomScanRoots.swift — adds the "ollama" case so the existing Additional scan folders feature works for Ollama too.
• OllamaUsageTests.swift — unit tests for the reader/parser.

Where the data comes from (the honest caveat)

Ollama reports exact prompt_tokens / completion_tokens on its final response object, but does not persist a usage ledger of its own. This provider reads NDJSON written under ~/.ollama/usage/YYYY-MM-DD.jsonl by a small transparent logging proxy that sits in front of the Ollama daemon and records each completed request, e.g.:

{"ts":"2026-08-27T10:25:57+00:00","source":"ollama","endpoint":"/api/chat","model":"qwen3.6:35b","prompt_tokens":35065,"completion_tokens":172,"total_tokens":35237}

The provider is intentionally decoupled from the proxy — it just treats that directory as a local usage source, and shows nothing if the ledger is absent (no crash, no error). Users who don't run such a proxy simply see no Ollama data, like any other provider whose logs aren't present.

Open question for the maintainer: how would you like the proxy dependency handled? (a) document the expected ~/.ollama/usage NDJSON format in the README and leave the proxy to the user; (b) I can contribute a tiny reference proxy in a follow-up; (c) if Ollama adds native usage persistence later, the provider can point at that with no interface change. Happy to go whichever way fits the project.

Notes

• No dependency changes; matches existing provider conventions and the local-day/totalTokens accounting used across providers.
• Tested locally against a real ~/.ollama/usage ledger; the app builds clean via scripts/build-app.sh.

[chattymin]

Thanks for this, and for stating the proxy dependency plainly instead of burying it — that's what made the decision straightforward.

I'm closing it, but I want to point at a different shape rather than just say no.

Why not this one. Every other provider in the app reads logs the tool itself writes; that's what lets the README promise "no external CLI needed". This one reads a ledger produced by a proxy the project doesn't ship, so a user would have to install and run an extra daemon before any data appears. And for local inference there isn't much to show even then: no cost and no quota, so two of the app's three surfaces (spend, official limits) are empty by definition, leaving only token counts feeding the companion.

The shape I would take. Ollama Cloud, not local inference. It has plan tiers, session and weekly quota windows, and reset timestamps — which is exactly the "official limits" model the app already implements for Claude, Codex and Antigravity. It also has a real credential: an API key from ollama.com/settings/keys, which is issued and revocable, rather than a scraped file.

Worth knowing before you start: the documented API doesn't appear to expose the quota windows, so the usage bars may need a browser session cookie. The app just took that tradeoff for Claude in #241, so it isn't disqualifying here, but it should be a deliberate part of the design rather than a surprise at the end.

Of your three options, (c) is closest to where I land: if Ollama adds native usage persistence for local inference, the provider can point at it with no interface change. Until then, the Cloud side is the part with something to show.

If you want to take a run at that, I'll review it.