Homelab AI Agent Costs Down 60% with Ollama Quantized Models

by

My homelab AI agent setup was costing $42/month in API calls alone — until I switched to local quantized models.

That number came straight from my OpenRouter billing dashboard for April 2026: 350,000 tokens across Claude 3 Haiku and Mistral Small, mostly from my personal agent that checks GitHub notifications, drafts tweets, and summarizes my daily reading. At $0.00012 per 1K tokens for Haiku and $0.00006 for Mistral, the math added up fast. I’d told myself local LLMs weren’t ready for prime time — too slow, too finicky, too much VRAM — until I hit a psychological wall: paying for something I could run myself felt like renting a bicycle when I owned a garage full of parts.

I decided to fix it. Over three weekends, I rebuilt my agent pipeline around Ollama, quantized Llama 3 models, and deliberate GPU time-slicing. The result? My monthly LLM API spend dropped to $0. building practical AI agents for real-world automation — My agent still handles the same tasks — sometimes faster, sometimes slower, but consistently useful. Along the way I learned concrete lessons about optimizing AI agent performance with structured prompts, quantization tradeoffs, containerized GPU sharing, and why “local first” doesn’t mean “local only.”

Here’s exactly what I did, what I measured, and what broke along the way.

Read more

gRPC vs REST: When to Use Which

by

Most “gRPC vs REST” articles pick a side. gRPC is the future. REST is simpler. The reality is more nuanced: the right choice depends on who calls the API, how often, and what the consumers can actually debug at 2 AM. This article compares the two protocols side by side and walks through three production cases where the choice was not obvious from the start.

Read more

What Responsible AI Actually Means for Builders

by
Abstract dark code terminal representing AI guardrails and responsible deployment

Most “responsible AI” content reads like it was written by a policy team that has never deployed an agent to production. The checklists are long. The principles are abstract. And none of them tell you what to do when your agent starts hallucinating customer data at 3 AM and the on-call engineer is asleep.

I have been building AI agents for about a year now. Not research. Not demos. Actual agents that touch real data, make real decisions, and occasionally break things in ways I did not anticipate. Here is what responsible AI looks like from the builder’s side — not the policy side.

—

Read more

By the Passage of Time

by
Susiloharjo

Lately I have been feeling like twenty-four hours is not enough. Not because I have too much work, but because every single hour seems to bring something new I want to learn. A new framework. A new tool. A new piece of research. A new opinion from someone I respect. By the time I close one tab, three more have opened in my head. I catch myself doing the math in the shower — sleep seven, work eight, pray and eat and commute, that leaves maybe three or four hours of focused time. Not a lot when the input keeps multiplying.

GROW coaching framework

And yet most people I know are not running out of time. They are running out of attention. They have all the time in the world, and they spend it on things that, if we are being honest, do not move the needle. Endless scrolling on TikTok. Reels until the battery dies. Mobile games that reset every morning. I am not pointing at anyone else here. I have been that person. Sometimes I still am.

So the question I keep coming back to is simple: how do we handle so much information in an era that keeps producing more of it than any one human can absorb, and how do we make sure the time we do have is spent on things that actually matter?

Read more

Recruitment App With AI: A Design Thinking Case Study

by
Abstract dark code editor screen representing a recruitment app interface

Last month I built a recruitment portal from scratch learn the 20% of design thinking that actually works — request form, approval flow, candidate filtering with AI, the whole nine yards. Before I wrote a single line of code, I sat through fifteen hours of interviews with HR managers, hiring managers, and candidates who had just been rejected understand requirements the way stakeholders see them.

That is the part most articles about building products skip. They jump straight to the whiteboard sketch or the workshop exercise. Those are the easy parts. The hard part is being willing to throw away your first idea after you have heard the third interview say, “that is not actually how I do my job.”

This is the story of how I actually built that portal — the conversations I had before writing code, the assumptions I had to throw out, and the things that broke in the first week. The portal handles request forms, multi-level approval, job posting, candidate registration, AI-assisted filtering, interview scheduling, psychological tests, salary offers, MCU (medical check-up), and onboarding logistics. I will show what survived and what I deleted.

Read more

The Best Feature I Ever Shipped Was a One-Page Procedure

by
Susiloharjo

Last year a client asked for an AI agent to automate their customer complaint triage. Forty hours of scoping done, two weeks of build time blocked. I was three days from opening the IDE when I sat next to the customer service team for two hours and watched.

I expected to see overwhelmed agents drowning in tickets. What I saw was three CS staff handling 12 complaints a day each, perfectly fine, with one exception — they refused to escalate anything to the operations team. Not because escalations were hard. Because the SOP for escalation was 11 steps long, contradicted itself in steps 4 and 7, and the last person who escalated “incorrectly” got a written warning.

The complaint volume was not the problem. The fear of escalation was. The triage agent I was about to build would have processed tickets faster into a system the team was already afraid to use.

I killed the project. Rewrote the escalation SOP from 11 steps to 4. Ran a 30-minute training. Two weeks later, complaints were down 60%. Zero lines of code shipped. The client saved 40 hours of dev time and $8K of cloud budget.

Since then I have had the same conversation five more times. Different industry, different “we need an app” request, same ending: a procedure nobody had bothered to write down clearly was doing the work that 200 hours of engineering could not.

This is the part of design thinking nobody talks about. Most of the time, the right output of the empathy stage is not a prototype. It is a one-page procedure that everyone can read, agree on, and follow. The build comes later — if it comes at all.

Read more