I went looking for a reason to use Ollama

I tried to find a place for Ollama in my automation stack. I wanted two things: a lower Anthropic bill, and Ollama running somewhere in my workflows. The first reason didn’t survive contact with the data.

The number

I have a workflow that pulls my Anthropic cost report every morning and posts it to Discord and my Craft daily note. So I checked it.

Thirty days, 56 workflows, every LLM call I make: $7.48. Twenty-five cents a day, already down 60% over that window.

Moving everything off Claude would save about $90 a year. Keeping Claude for work where quality matters brings that closer to thirty.

I standardized most of my stack on Haiku months ago. That’s where the savings already went. I went looking to cut a bill that was already at its floor, because reducing API costs sounds like good engineering whether or not the number supports it.

Ollama Cloud costs more than I spend

Two things I had confused: open-weight models and locally-hosted models are separate choices. I don’t want models running on my Mac. That’s not an argument against open models — Ollama Cloud runs them on their hardware behind a normal API. I’d even set up the credentials back in December and forgotten.

But Ollama Cloud doesn’t bill per token. It’s a flat subscription metered by GPU time, with session limits every five hours and weekly limits every seven days. Pro is $20 a month — nearly three times my current bill, for smaller models.

The free tier might cover my volume. I can’t confirm that, because Ollama has no account usage endpoint. Checking your quota means logging into the web dashboard. Several open feature requests ask for an API; none have shipped. You find out you’re near the ceiling when they email you at 90%.

I went looking to reduce a cost I track with a daily automated report, and the alternative can’t be tracked with one.

The reason that holds up

Cost is out. Privacy doesn’t apply — I’m summarizing my own RSS feeds and my own billing data.

What’s left: I don’t know which of my workflows actually need a frontier model.

I have a dozen-plus workflows making LLM calls. Some summarize articles or pull signal out of a week of notes. Others do arithmetic and pattern-matching dressed up as reasoning. I’ve never tested the difference. Everything points at the same model because at twenty-five cents a day there was no reason to check.

An open model is a cheap way to test that. Not to replace Claude — to find out where the line is. Any task where a small open model matches Haiku is a task I’ve been over-provisioning.

The experiment

I picked the most mechanical node I have: the one that asks four questions about thirty numbers. Trend, spikes, projection. 570 tokens in, no nuance required.

Both models now run in parallel from the same prompt, joined by a merge node so the message builder doesn’t fire twice and double-post. Both answers print back to back, labelled with their model. The Ollama arm fails soft — a rate limit on the test shouldn’t break the report.

One thing I nearly got wrong: I reached for the largest open model first, because it was the name I recognized from the docs. Wrong instrument. A big model will obviously handle a trend summary, and confirming that tells me nothing. If you’re looking for the floor, start at the floor.

If you’re considering the same thing

Spending real money on inference? Do the migration. The math works.

Bill is a rounding error? Then cost isn’t your reason and privacy probably isn’t either. The useful question is which of your automations need a frontier model and which ones you’re over-provisioning out of habit.

I’ll report back either way.