Faster and Cheaper: What I Actually Changed in My Recent Projects

I used to think speed and cost were things you fix at the end. Ship first, optimise later. After a few projects I've stopped believing that. By the time "later" comes, the slow and expensive parts are holding everything else up.

So this is a write-up of the changes that actually made a difference in my last few builds. Nothing clever. Most of it comes down to one question: does this request really need to go to the expensive thing?

AgyLite: stop paying for context you don't use

AgyLite started because my own coding-agent setup was getting heavy. I had several plugins installed, and every one of them loaded its instructions on every single turn, whether that turn needed them or not. The model then had to read all of it and guess which one applied.

I measured it. With five plugins installed, each turn carried around 32,000 tokens of context before I'd even typed anything. That's slow, and on a paid model it's money spent on nothing.

The change was to stop letting the model choose. AgyLite routes each request with plain rules first, then loads only the few skills that request needs. Per-turn context went down to roughly 900 tokens, and the routing step got all 26 of my test scenarios right, at a 95th-percentile time of 0.46 ms. That's not the model getting smarter. It's just a lot less to read.

What I took from it: if a decision can be made with rules, don't pay a model to make it.

Techie Mind: small and local first, big model only when unsure

Techie Mind is a browser agent I built for Smart India Hackathon 2026. You tell it something like "search laptops under ₹50,000 on Flipkart" and it does it in the browser.

The obvious version sends every command to a big vision model. That's slow, it costs money if the model is in the cloud, and it sends whatever's on your screen somewhere else.

Instead it works in steps:

• Plain code tries to understand the command first. Most commands are simple, and this costs nothing.
• If that's not sure, a small local model called Laya decides. Warm, that takes about 34 ms.
• Only if Laya is unsure does it go to Qwen 2.5-VL 7B, which also runs locally through Ollama.

The big model is still there for hard cases. It just isn't the first thing every request hits. And because it's all local, there's no per-request bill and the page content stays on your machine.

The AuricVista assistant: answer the easy stuff without AI at all

For AuricVista I built a chatbot that answers questions about the company, its student stays and its travel experiences. When I looked at what people actually type into a chatbot, a big chunk is "hi", "hello", or something that has nothing to do with the business.

Sending those to a model is pure waste. So they get handled before the model, with an instant reply that needs no network call at all. Only real questions go to Gemini.

Two other changes mattered more than I expected:

• **A hard time limit.** The Gemini call gets 3.5 seconds. If it hasn't answered by then, a built-in knowledge engine answers from the company's own content instead. A slightly plainer answer now beats a perfect one that never arrives.
• **Cold starts.** On Render's free tier the server goes to sleep after 15 minutes without traffic, and the next visitor waits 50 to 70 seconds for it to wake up. That's long enough for someone to close the tab. I added a health endpoint with a keep-alive ping, and Vercel's serverless setup is the recommended option because it doesn't have that spin-down problem.

This website: fewer database calls, and content that doesn't wait for JavaScript

This portfolio runs on Vercel with Supabase behind it. A few changes here:

• **One row instead of many queries.** All the editable site content lives in a single row, so loading the home page is one read, not one query per section.
• **Caching public reads.** Things like the project list and blog posts are cached in memory and at Vercel's edge for a few minutes. If a post gets shared and a lot of people open it at once, Supabase still sees about one request per page every few minutes. Any edit I make in the admin clears the cache, so changes still show up quickly.
• **Removing what nobody needed.** The old version polled for recent visitors. It looked nice and cost a database call on a timer for no real reason. It's gone.
• **Content in the HTML.** Projects, services, the FAQ and blog posts are now written into the page at build time. Visitors see content straight away instead of waiting for a script to fetch it, and search engines and AI tools that don't run JavaScript can read everything.
• **Caching that doesn't break things.** I once had browsers mixing new HTML with week-old JavaScript, which broke pages. Now each script and stylesheet link carries a fingerprint of its content, so files can be cached for days and a new deploy is still picked up immediately.

The chatbot on this site, and the limit I learned about the hard way

The "Ask me" button on this site is also an AI assistant, and I built it with cost in mind from day one:

• Questions are checked before any model call. Messages are capped at 500 characters, there's a tighter rate limit on the chat endpoint, and obvious off-topic or prompt-injection attempts get a fixed reply without touching the model.
• Only the last four turns of the conversation are sent, not the whole history.
• The site knowledge it answers from is built once and cached for five minutes, instead of being rebuilt for every question.
• If the newest model is overloaded or slow, the next one answers.

And then I found the one thing I hadn't planned for. I ran a 64-question test set against it and the results were garbage, because the free Gemini tier allows 20 requests per day per model. The test was hitting the limit, not testing the bot. The lesson isn't really about Gemini. Check the quota before you design the test, and before you put something in front of real traffic.

What I'd tell anyone building something similar

• Before calling a model, ask whether a rule could answer it. Often it can.
• Use the cheapest thing that works first, and escalate only when it's unsure.
• Put a time limit on anything slow, and decide what happens when it's hit.
• Cache public data, and make sure your own edits clear the cache.
• Read the free-tier limits before you build on them, not after.

None of this is new. It's just easy to skip when you're excited to ship. If you want help making something you've built faster or cheaper to run, send me what you have. The projects mentioned here are AgyLite, Techie Mind and Auric Vista.