zlacker

Tell HN: I cut Claude API costs from $70/month to pennies

submitted by ok_orc+(OP) on 2026-01-26 00:34:17 | 40 points 30 comments
[source] [links] [go to bottom]

The first time I pulled usage costs after running Chatter.Plus - a tool I'm building that aggregates community feedback from Discord/GitHub/forums - for a day hours, I saw $2.30. Did the math. $70/month. $840/year. For one instance. Felt sick.

I'd done napkin math beforehand, so I knew it was probably a bug, but still. Turns out it was only partially a bug. The rest was me needing to rethink how I built this thing. Spent the next couple days ripping it apart. Making tweaks, testing with live data, checking results, trying again. What I found was I was sending API requests too often and not optimizing what I was sending and receiving.

Here's what moved the needle, roughly big to small (besides that bug that was costin me a buck a day alone):

- Dropped Claude Sonnet entirely - tested both models on the same data, Haiku actually performed better at a third of the cost

- Started batching everything - hourly calls were a money fire

- Filter before the AI - "lol" and "thanks" are a lot of online chatter. I was paying AI to tell me that's not feedback. That said, I still process agreements like "+1" and "me too."

- Shorter outputs - "H/M/L" instead of "high/medium/low", 40-char title recommendation

- Strip code snippets before processing - just reiterating the issue and bloating the call

End of the week: pennies a day. Same quality.

I'm not building a VC-backed app that can run at a loss for years. I'm unemployed, trying to build something that might also pay rent. The math has to work from day one.

The upside: these savings let me 3x my pricing tier limits and add intermittent quality checks. Headroom I wouldn't have had otherwise.

Happy to answer questions.

replies(9): >>arthur+k >>dezgeg+2A >>gandal+eB >>LTL_FT+mC >>44za12+rC >>joshri+ND >>DeathA+bG >>deepsu+kL >>toxic7+384
1. arthur+k[view] [source] 2026-01-26 00:37:11
>>ok_orc+(OP)
Can you discuss a bit more of the architecture?
replies(1): >>ok_orc+E2
◧◩
2. ok_orc+E2[view] [source] [discussion] 2026-01-26 00:55:02
>>arthur+k
Pretty straightforward. Sources dump into a queue throughout the day, regex filters the obvious junk ("lol", "thanks", bot messages never hit the LLM), then everything gets batched overnight through Anthropic's Batch API for classification. Feedback gets clustered against existing pain points or creates new ones.

Most of the cost savings came from not sending stuff to the LLM that didn't need to go there, plus the batch API is half the price of real-time calls.

3. dezgeg+2A[view] [source] 2026-01-26 06:39:15
>>ok_orc+(OP)
Are you also adding the proper prompt cache control attributes? I think Anthropic API still doesn't do it automatically
replies(1): >>ok_orc+1a8
4. gandal+eB[view] [source] 2026-01-26 06:50:10
>>ok_orc+(OP)
Consider using z.ai as model provider to further lower your costs.
replies(5): >>tehlik+NC >>DANmod+cD >>virapt+gE >>ok_orc+rm2 >>andai+aHm
5. LTL_FT+mC[view] [source] 2026-01-26 07:03:37
>>ok_orc+(OP)
It sounds like you don’t need immediate llm responses and can batch process your data nightly? Have you considered running a local llm? May not need to pay for api calls. Today’s local models are quite good. I started off with cpu and even that was fine for my pipelines.
replies(4): >>queenk+PL >>kreetx+TV >>ydu1a2+9i1 >>ok_orc+om2
6. 44za12+rC[view] [source] 2026-01-26 07:03:53
>>ok_orc+(OP)
This is the way. I actually mapped out the decision tree for this exact process and more here:

https://github.com/NehmeAILabs/llm-sanity-checks

replies(2): >>homeon+Bd1 >>andai+vHm
◧◩
7. tehlik+NC[view] [source] [discussion] 2026-01-26 07:08:09
>>gandal+eB
This is what i was going to suggest too.
◧◩
8. DANmod+cD[view] [source] [discussion] 2026-01-26 07:12:37
>>gandal+eB
Do they or any other providers offer any improvements on the often-chronicled variability of quality/effort from the major two services e.g. during peak hours?
9. joshri+ND[view] [source] 2026-01-26 07:19:12
>>ok_orc+(OP)
Have you looked into https://maartengr.github.io/BERTopic/index.html ?
◧◩
10. virapt+gE[view] [source] [discussion] 2026-01-26 07:23:30
>>gandal+eB
Or minimax - m2.1 release didn't make a big splash in the news, but it's really capable.
11. DeathA+bG[view] [source] 2026-01-26 07:47:13
>>ok_orc+(OP)
You also can try to use cheaper models like GLM, Deepseek, Qwen,at least partially.
12. deepsu+kL[view] [source] 2026-01-26 08:38:31
>>ok_orc+(OP)
As much as I like the Claude models, they are expensive. I wouldn't use them to process large volumes of data. Gemini 2.5 Flash-Lite is $0.10 per million tokens. Grok 4.1 Fast is really good and only $0.20. They will work just as well for most simple tasks.
◧◩
13. queenk+PL[view] [source] [discussion] 2026-01-26 08:44:17
>>LTL_FT+mC
Agreed, I'm pretty amazed at what I'm able to do locally just with an AMD 6700XT and 32GB of RAM. It's slow, but if you've got all night...
◧◩
14. kreetx+TV[view] [source] [discussion] 2026-01-26 10:20:51
>>LTL_FT+mC
Though haven't done any extensive testing then I personally could easily get by with current local models. The only reason I don't is that the hosted ones all have free tiers.
◧◩
15. homeon+Bd1[view] [source] [discussion] 2026-01-26 12:45:24
>>44za12+rC
That's interesting. Is there any kind of mapping to these respective models somewhere?
replies(1): >>44za12+sj1
◧◩
16. ydu1a2+9i1[view] [source] [discussion] 2026-01-26 13:15:24
>>LTL_FT+mC
Can you suggest any good llms for cpu?
replies(2): >>R_D_Ol+dK1 >>LTL_FT+TR9
◧◩◪
17. 44za12+sj1[view] [source] [discussion] 2026-01-26 13:24:03
>>homeon+Bd1
Yes, I included a 'Model Selection Cheat Sheet' in the README (scroll down a bit).

I map them by task type:

Tiny (<3B): Gemma 3 1B (could try 4B as well), Phi-4-mini (Good for classification). Small (8B-17B): Qwen 3 8B, Llama 4 Scout (Good for RAG/Extraction). Frontier: GPT-5, Llama 4 Maverick, GLM, Kimi

Is that what you meant?

replies(1): >>hyuuu+W4i
◧◩◪
18. R_D_Ol+dK1[view] [source] [discussion] 2026-01-26 15:41:08
>>ydu1a2+9i1
Following.
replies(2): >>LTL_FT+JS9 >>Aerbil+jJk
◧◩
19. ok_orc+om2[view] [source] [discussion] 2026-01-26 18:16:02
>>LTL_FT+mC
I haven't thought about that, but really want to dig in more now. Any places you recommend starting?
replies(1): >>LTL_FT+xS9
◧◩
20. ok_orc+rm2[view] [source] [discussion] 2026-01-26 18:16:14
>>gandal+eB
Will take a look!
21. toxic7+384[view] [source] 2026-01-27 06:19:01
>>ok_orc+(OP)
consider this for addtl cost savings if local doesnt interest you - https://docs.cloud.google.com/vertex-ai/generative-ai/docs/m...
◧◩
22. ok_orc+1a8[view] [source] [discussion] 2026-01-28 06:05:40
>>dezgeg+2A
No I need to look into this!
◧◩◪
23. LTL_FT+TR9[view] [source] [discussion] 2026-01-28 17:11:15
>>ydu1a2+9i1
I started off using gpt-oss-120b on cpu. It uses about 60-65gb of memory or so but my workstation has 128gb of ram. If I had less ram, I would start off with the gpt-oss-20b model and go from there. Look for MoE models as they are more efficient to run.
◧◩◪
24. LTL_FT+xS9[view] [source] [discussion] 2026-01-28 17:13:26
>>ok_orc+om2
I started off using gpt-oss-120b on cpu. It uses about 60-65gb of memory or so but my workstation has 128gb of ram. If I had less ram, I would start off with the gpt-oss-20b model and go from there. Look for MoE models as they are more efficient to run.

My old threadripper pro was seeing about 15tps, which was quite acceptable for the background tasks I was running.

◧◩◪◨
25. LTL_FT+JS9[view] [source] [discussion] 2026-01-28 17:14:00
>>R_D_Ol+dK1
I started off using gpt-oss-120b on cpu. It uses about 60-65gb of memory or so but my workstation has 128gb of ram. If I had less ram, I would start off with the gpt-oss-20b model and go from there. Look for MoE models as they are more efficient to run.
◧◩◪◨
26. hyuuu+W4i[view] [source] [discussion] 2026-01-30 20:58:21
>>44za12+sj1
at the sake of being obvious, do you have a tiny llm gating this decision and classifying and directing the task to its appropriate solution?
◧◩◪◨
27. Aerbil+jJk[view] [source] [discussion] 2026-01-31 19:36:16
>>R_D_Ol+dK1
Hey Olivaw, saw a comment of yours asking about planners. Wanted to reply but it’s expired. Check out bullet journalling.
replies(1): >>R_D_Ol+n1t
◧◩
28. andai+aHm[view] [source] [discussion] 2026-02-01 17:03:06
>>gandal+eB
Do you mean with the coding plan?

I haven't tested it extensively but I found that when I used Claude Code with it, it was reasonably fast (but actual Claude was way faster), but when I tried to use the API itself manually, it would be super slow.

My guess would be think they're filtering the traffic and prioritizing certain types. On my own script, I ran into a rate limit after 7 requests!

◧◩
29. andai+vHm[view] [source] [discussion] 2026-02-01 17:05:40
>>44za12+rC
>Before you reach for a frontier model, ask yourself: does this actually need a trillion-parameter model?

>Most tasks don't. This repo helps you figure out which ones.

About a year ago I was testing Gemini 2.5 Pro and Gemini 2.5 Flash for agentic coding. I found they could both do the same task, but Gemini Pro was way slower and more expensive.

This blew my mind because I'd previously been obsessed with "best/smartest model", and suddenly realized what I actually wanted was "fastest/dumbest/cheapest model that can handle my task!"

◧◩◪◨⬒
30. R_D_Ol+n1t[view] [source] [discussion] 2026-02-03 15:04:38
>>Aerbil+jJk
Thanks for the reply!

Bullet journaling is neat, but I'm far too whacky with my notes to stick to that kind of structure.

I have various other structures I implement, but they're just hodge podges of things.

[go to top]