Tuesday, May 19, 2026

FinOps Beyond Cloud: Flagging Which LLM Path Runs

 

It’s 2026, and I’ve been spending less time pretending engineering stops at the IDE. The roadmap still matters—but so do unit economics, vendor quirks, and the quiet ways money leaks out of a system once real traffic shows up. This post is a relaxed tour of one slice of that: treating cloud and model spend as something you design for, not something you discover on the invoice.


1. What a product-minded engineer is actually optimizing

Shipping the feature is rarely the whole story anymore. The interesting question is often about margin: if we 10× this, or a bunch of users land on the free tier, or ARPU is thin—does this path still feel sane?

Someone in a product-minded headspace is trying to build things where:

  • Cost and revenue nudge behavior, not just quarterly slides.
  • The cheapest good-enough path is the default; saving the fancy model or crawl for when it’s actually worth it.
  • Guardrails and metrics are just part of the product—so you’re not one recursive “fix it again” loop away from funding a typo correction with a flagship SKU.

Below is a small Node API that mirrors that attitude: one place where report spellcheck and executive-summary work can stay offline or go to Gemini, with a flag and a sample benchmark you can project to more users and more AI-shaped features. Section 6 spells out what that sample is, what it proves, and how it scales—so the savings story stays honest.


2. The product decision: a profitability-aware seam

The pattern I’m pointing at is cost-aware feature flagging. Not only “is this feature on?” but something closer to: for this customer and this task, is this spend okay right now?

Roughly:

  • On the way in: stuff from FinOps land—AWS Cost ExplorerOpenCost, whatever tells you what things actually cost, plus quota signals and subscription / ARPU if you have it. Not just is_beta_user.
  • On the way out: the same user-facing capability, but tiered—local lib, Flash/Lite, Pro, batch, “come back later”—instead of one path that always burns the same fuel.

You can think of it like auth: a consistent gate before the expensive bit runs, except the dimension is margin as well as permission.


3. Models don’t negotiate your budget (fair critique)

Someone will ask: Hey, aren’t these models smart enough to route things and save us money?

They’re great at doing the task; they’re not sitting in your finance tools. A Gemini 3.0 or GPT-5-class endpoint doesn’t ship with a budget dial for your app. You pointed it at a tier; it tries to do well on that tier. If you aim a big SKU at a tiny task, it’ll usually still answer—and you still pay for what you invoked, not for how “hard” the task felt.

So the savings story stays yours: routing, backoff, when to stop retrying. Don’t expect the model to politely refuse your money.


4. TCO: monitoring is cheap noise; the wrong LLM path isn’t

TCO (total cost of ownership) here includes the boring stuff—wrong model tier, stuck loops, “one more generation” after a weird answer.

A bit of instrumentation (which route, how many tokens, quotas) feels like extra work until you compare it to one stray Pro-style call or a runaway loop. Ballpark order of magnitude (depends on pricing, tokens, caching; don’t quote me to procurement): pushing a trivial thing through an LLM stack can be on the rough scale of 250× to 25,000× pricier than the small amount of code and metrics that would have caught it.

So yeah: spend a smidge on visibility so you don’t accidentally fund nonsense paths.


5. How to implement the seam (naive → production)

Toy version: one handler with taskspellcheck vs summarize, and a flag like COST_OPTIMIZATION_ENABLED. When it’s on, a long report can get full-document Typo.js cleanup plus a cheap extractive exec summary; when it’s off, gemini-2.5-flash (or whatever you configure) does both with richer behavior.

Closer to prod: swap the rule for a router (small model, classifier, “needs nuance?” heuristics) and wire the same FinOps + subscription signals you’d use anywhere else—just with margin in the decision, not only permissions.


6. Sampling experiment: methodology, results, and projections

This section is intentionally split into what I sampledwhat I saw, and how to extrapolate—so the cost-saving argument reads as evidence + model, not as “my laptop proved FinOps.”

6.1 What this experiment is (and is not)

What it is: a controlled bench. One synthetic multi-section report (~290 words), two HTTP calls in a fixed order—spellcheck then summarize—implemented in Express as POST /v1/check with JSON { text, task }. A single env flag, COST_OPTIMIZATION_ENABLED, switches both tasks to offline implementations (full-document Typo.js + extractive executive bullets) or both to gemini-2.5-flash via @google/genai (this run). The script scripts/benchmark-check.js replays that pair and prints latency plus placeholder session costs.

What it is not: production traffic, A/B on real users, or a mixed routing policy. It is a slice: “for this document shape (here, a sectioned narrative) and these two capabilities, how many model calls disappear if you accept the cheap path?”

How to use it anyway: treat the bench as a sampler. In real life you’ll mix routes; the useful invariant is:

Avoided model opex (for a capability slice) ≈ (cloud calls you would have made − cloud calls you actually made) × realistic $/call,

which scales about linearly with how often that pipeline runsinitial drafts, edit rounds, audit re-runs, refactors of the same body, or “per user” if each user drives those passes—as long as calls per run stays stable. The bench pins two POSTs per run (spellcheck then summarize) and avoided-call fraction for one storyboard so you can plug in your volume.

6.2 Head-to-head results (the sample)

MetricOptimization ONOptimization OFF
Requests22
Offline routes20
Cloud (Gemini)02
Avg latency (ms)~2378~4788
Placeholder session total$0.000000$0.000230

The session total is only the demo knobs COST_CLOUD_SPELLCHECK + COST_CLOUD_SUMMARY in server.js—fine for a workshop, not a bill.

Plain-language takeaway for this slice: optimization on skipped every Gemini invocation that off made for these two tasks (0 vs 2 calls → 100% avoidance for this pair only). Tradeoff: extractive bullets and a full-file dictionary pass are cheap, but the spell step can land around a few seconds on a long draft (~4.7s on the first spellcheck request in my run), while the offline summary stayed single-digit ms.

6.3 Projecting to volume (drafts, edits, audits, refactors)

Illustrative token sketch—same Flash-style guesses baked into the benchmark (~2200 / 2000 in/out for the long corrective pass, ~2200 / 450 for exec summary, $0.15/M in and $0.60/M out; verify Gemini pricing). Think of a run as one time you execute spellcheck + summarize on a body—e.g. a new draft, a heavy edit, an audit pass that re-queues the pair, or a refactor that rewrites a section and re-runs the tooling.

ItemOptimization ON (this demo)Optimization OFF (all Gemini for these two tasks)
Cloud calls / month @ 5k runs (2 POSTs per run)010,000
Order-of-magnitude API $ / month~$0~$10.65
Avoided vs all-cloud at that volume (token model only)~$10.65

Scale the numerator: at 50k runs/month—stacking draft cycles, revision rounds, audit and compliance re-checks, refactors, anything that replays this two-step cloud path—the same all-cloud token math lands near ~$106/month for that slice alone—before you add any new AI feature. The cost-aware pattern is convincing here because the growth lever is obvious: more passes through the pipeline ⇒ more invocations ⇒ the same percentage of avoided calls buys proportionally more dollars as activity grows.

6.4 Where product growth quietly multiplies cost (features, not just users)

Users rarely stop at “spellcheck + summary.” Roadmaps add adjacent model tasks: e.g. AI glossary (“explain this acronym for a non-security exec”), keyword callouts next to the summary, a risk-language nudgeemail-ready rewrite, or second-pass tightening. If each is implemented as another always-on Gemini call, you get multiplication: two cloud tasks become three, four, five—each time someone runs the flow—while routing stays an afterthought.

A cost-aware seam doesn’t mean shipping worse product; it means deciding per task (plan tier, cache, template, small model, batch, human review) instead of defaulting “new AI affordance ⇒ new flagship invocation.” The bench only models two tasks, but the projection mental model extends: every new task is a coefficient on monthly variable spend unless you fold it into the same router.

6.5 Why this is still a convincing case for the approach

  1. The sample isolates mechanism: you can see exactly which HTTP paths hit the model when the flag flips—no mystery meat in “optimization.”
  2. Volume makes small per-call numbers real: ~$0.00107/POST on the all-cloud token estimate at 10k calls/month is easy to shrug off until draft/edit/audit/refactor volume (and features) push you to 100k+ calls.
  3. Feature creep is the hidden multiplier: routing discipline is how you ship more AI-shaped surface area without linear-to-cloud spend on every new button.

7. What to ship next

  1. Line up tenant → revenue or plan next to what each route costs.
  2. Pipe in billing / OpenCost / whatever so flags react to data, not vibes.
  3. Write down an escalation ladder (local → Flash/Lite → Pro) and cap retries / quotas.
  4. Treat the router like real product: when SKUs or prices move, this layer moves too.
  5. When you add a model task (e.g. exec glossarykeyword explainers), add a benchmark row and a $/task assumption—otherwise “one more feature” won’t show up in FinOps until the invoice does.


Please note: The playground code for server.js is at the bottom of this post. The post treats that run as a sample you can scale with your own monthly pipeline volume—how often teams hit spellcheck + summarize across drafts, edits, audits, refactors, and so on—and your task list. Dollar figures mix placeholder session costs and illustrative token mathabsolute savings scale with users, calls per run, model tier, and how many new AI features stay cloud-default—plug in real metering before treating any number as financial guidance.


require('dotenv').config();
const express = require('express');
const { GoogleGenAI, ApiError } = require('@google/genai');
const Typo = require('typo-js');

const app = express();
app.use(express.json());

const dictionary = new Typo('en_US');

const genai = new GoogleGenAI({
    apiKey: process.env.GEMINI_API_KEY,
});

/** Placeholder $ per cloud call (tune for FinOps demos; real bills use metering). */
const COST_CLOUD_SPELLCHECK = Number(process.env.COST_CLOUD_SPELLCHECK) || 0.00005;
const COST_CLOUD_SUMMARY = Number(process.env.COST_CLOUD_SUMMARY) || 0.00018;

/** Correct spelling per word; preserves whitespace and punctuation (en_US). */
function correctWithTypo(text) {
    return text.replace(/\b[\w']+\b/g, (word) => {
        if (dictionary.check(word)) return word;
        const suggestion = dictionary.suggest(word)[0];
        return suggestion || word;
    });
}

/** Cheap path: lead sentences + pseudo-bullets (no API). */
function extractiveExecutiveSummary(text) {
    const t = text.trim().replace(/\s+/g, ' ');
    const sentences = t.split(/(?<=[.!?])\s+/).filter((s) => s.length > 15);
    const head = sentences.slice(0, 4).join(' ');
    const base =
        head.length >= 200 ? head : t.slice(0, Math.min(1200, t.length)) + (t.length > 1200 ? '…' : '');
    const lines = base
        .split(/(?<=[.!?])\s+/)
        .filter(Boolean)
        .slice(0, 5)
        .map((s) => `- ${s.trim()}`);
    return lines.join('\n');
}

let sessionTotalCost = 0;

function isTruthyEnv(name) {
    const v = process.env[name];
    if (v == null) return false;
    return /^(1|true|yes)$/i.test(String(v).trim());
}

/** Pull a readable message out of SDK errors (often `message` is stringified JSON). */
function geminiErrorDetail(err) {
    const msg = err && typeof err.message === 'string' ? err.message : String(err);
    try {
        const parsed = JSON.parse(msg);
        const inner = parsed && parsed.error ? parsed.error : parsed;
        if (inner && typeof inner.message === 'string') {
            return { summary: inner.message, code: inner.code, status: inner.status };
        }
    } catch (_) {
        /* use raw */
    }
    return { summary: msg };
}

app.post('/v1/check', async (req, res) => {
    const { text, task } = req.body ?? {};
    if (typeof text !== 'string' || !text.trim()) {
        return res.status(400).json({ error: 'Body must include non-empty string `text`.' });
    }
    if (task !== 'spellcheck' && task !== 'summarize') {
        return res.status(400).json({
            error: 'Body must include `task`: "spellcheck" | "summarize".',
        });
    }

    const isOptimizationOn = isTruthyEnv('COST_OPTIMIZATION_ENABLED');
    const words = text.trim().split(/\s+/);

    let output = '';
    let engine = '';
    let cost = 0;

    try {
        if (task === 'spellcheck') {
            if (isOptimizationOn) {
                if (words.length <= 5) {
                    output = correctWithTypo(text);
                    engine = 'Offline (Typo.js)';
                } else {
                    output = correctWithTypo(text);
                    engine = 'Offline (Typo.js full document)';
                }
                cost = 0;
            } else {
                const model = process.env.GEMINI_MODEL || 'gemini-2.5-flash';
                const response = await genai.models.generateContent({
                    model,
                    contents: [
                        'You correct spelling and obvious typos only. Preserve structure, headings, and meaning. Reply with the full corrected text only—no preamble or quotes.',
                        `Document:\n${text}`,
                    ].join('\n\n'),
                });
                const raw = response.text;
                if (raw == null || !String(raw).trim()) {
                    throw new Error('Empty response from model');
                }
                output = String(raw).trim();
                engine = `Cloud spellcheck (${model})`;
                cost = COST_CLOUD_SPELLCHECK;
            }
        } else {
            // summarize → executive summary
            if (isOptimizationOn) {
                output = extractiveExecutiveSummary(text);
                engine = 'Offline (extractive executive summary)';
                cost = 0;
            } else {
                const model = process.env.GEMINI_MODEL || 'gemini-2.5-flash';
                const response = await genai.models.generateContent({
                    model,
                    contents: [
                        'Condense the report into an executive summary for leadership: 3–5 bullet points, plain text, each line starting with "- ". Be factual; do not invent risks or metrics.',
                        `Report:\n${text}`,
                    ].join('\n\n'),
                });
                const raw = response.text;
                if (raw == null || !String(raw).trim()) {
                    throw new Error('Empty response from model');
                }
                output = String(raw).trim();
                engine = `Cloud summary (${model})`;
                cost = COST_CLOUD_SUMMARY;
            }
        }

        sessionTotalCost += cost;
        console.log(`[${new Date().toISOString()}] task=${task} Engine: ${engine} | Cost: $${cost}`);

        res.json({
            task,
            output,
            engine,
            stats: { sessionTotal: sessionTotalCost.toFixed(6) },
        });
    } catch (error) {
        if (error instanceof ApiError) {
            const { summary, code, status: bodyStatus } = geminiErrorDetail(error);
            const httpStatus =
                typeof error.status === 'number' && error.status >= 400 && error.status <= 599
                    ? error.status
                    : 502;
            console.error('[Gemini ApiError]', httpStatus, summary);
            const label =
                httpStatus === 429
                    ? 'Gemini quota or rate limit (check plan / AI Studio quotas)'
                    : 'Gemini API error';
            return res.status(httpStatus).json({
                error: label,
                details: summary,
                geminiCode: code,
                geminiStatus: bodyStatus,
            });
        }
        console.error('[Report pipeline]', error);
        res.status(500).json({ error: 'System Error', details: error.message });
    }
});

const PORT = Number(process.env.PORT) || 3000;

const server = app.listen(PORT);
server.once('listening', () => {
    console.log(`Report spellcheck + executive summary API on port ${PORT}`);
});
server.once('error', (err) => {
    console.error('Server failed to start:', err.code === 'EADDRINUSE' ? `port ${PORT} is already in use` : err.message);
    process.exit(1);
});



Monday, April 20, 2026

Local AI on an M1 Pro: From "Post-Apocalyptic" Slowness to a Functional Reality

We’ve all seen headlines like this: "The end of paid coding assistants!" or "Run your own private AI locally for free!" As someone who values privacy and hates the dependency on monthly subscriptions, I decided to see if my trusty MacBook Pro (M1 Pro, 32GB RAM) could become my trustworthy coding workstation.

My journey started with a massive failure, moved through a "thinking" loop, and finally landed on a configuration that actually works. Here is how I turned my Mac into a functional local coding station.

(Yeah... I’ve reached the stage where I won’t bother with perfect screenshots. If I need to show the output of my fun tinkering on an isolated machine, I’ll just take a blurry photo of the screen with my old phone. It’s much more relaxed that way.)



Phase 1: The "Heavyweight" Disaster with "Qwen 3.5 Coder Next"

I started ambitious. Installing Ollama was the simplest part. Then I pulled Qwen 3.5 Coder Next. I thought 32GB of RAM would be enough. I was wrong.

The Experience:

  • Initial 'Hi': 25 seconds.

  • Coding Task: 7+ minutes to generate just some initial instructions and start writing the variables section for an Arduino script.

  • The Culprit: My logs showed the model needed 51.3 GiB of memory. Since I only have 32GB, Ollama had to shove 26GB of the "brain" onto my CPU.


The long wait after a simple "Hi".

 

The painful 7+ minutes of waiting while watching the slow code generation and seeing my computer's memory heavily consumed.



Phase 2: The "Thinking" Trap with "Qwen 3.5 9B"

I pivoted to a smaller model: Qwen 3.5 9B. On paper, this should have been lightning fast. However, I ran into a new hurdle: Reasoning Loops.

Even with the smaller 9B model, the "Reasoning/Thinking" phase was taking forever—sometimes up to 7 minutes of "thinking" without a single line of code being written. At one point, it even got caught in a logical loop, and I had to restart the process.

A lot of thinking for 7+ minutes and no action but much less memory consumption.



Phase 3: The Breakthrough (The "Nothink" Secret)

The real "Aha!" moment came when I realized I didn't need the model to spend several minutes pondering the meaning of life for a simple Arduino script. I just needed the code.

I used a simple command to bypass the heavy reasoning phase: >>> /set nothink

The difference was huge:

  • Total Response Time: 2 minutes and 28 seconds for a complete, complex answer.

  • Content Quality: It wasn't just code. It gave me prerequisites, circuit wiring, full Arduino code, security tips, and even improvement ideas.

  • Memory Efficiency: The logs show this model is a perfect fit for the M1 Pro. It only used about 9.1 GiB of total memory, meaning 100% of the model layers (33/33) stayed on the GPU (Metal).

This time, with 'nothink', it was spitting out the answer much faster.



Technical Insights from the Logs

If you are troubleshooting your own local setup, here is what I learned from the Ollama server logs:

  1. Check your Offloading: In my successful 9B run, the logs said: offloaded 33/33 layers to GPU. This is the ideal case. If that number isn't 100%, your performance will be affected.

  2. Flash Attention is King: The logs confirmed enabling flash attention. This helps the Mac handle long conversations without slowing down.

  3. The "Unified" Advantage: My M1 Pro was able to allocate a recommendedMaxWorkingSetSize of ~26GB. By using the 9B model (which only needs ~9GB), I left plenty of room for my system to breathe.


The Verdict: Is it a "Free" Coding Assistant?

Is a "free" local coding assistant possible? Yes—but resources matters. If you try to run massive models on a 32GB Mac, you'll feel like you're back in the era of dial-up.

If this continues to feel this good, I’m considering the ultimate "pro" move: Using this Mac as a headless AI server. I can connect it to a secure network and put it away on a shelf and connect to its "brain" from my other computers for chatting or from within VS Code (with the suitable plugin's of course) or even my phone. My main coding machine stays cool and quiet, while the M1 Pro does all the heavy lifting in the background.

I hope that my little weekend experiment has helped you in any way with insights or inspiration to set on your own journey of finding your own AI independence.


Tuesday, April 7, 2026

The Rise of the Product Engineer: Title Trend or New Reality?

 

This career topic has been on my mind for a while, and I've been trying to collect more information about it for my own career's sake. And now I think I have an idea clear enough to be shared. I hope it benefits someone out there.

The "Product Engineer" title has exploded in popularity this year. This shift is happening for three main reasons:

  • AI-Assisted Coding: Since AI can now handle basic coding tasks, companies need engineers who can move "above" the code to control the requirements (inputs) and the architecture (outputs).

  • Flatter Teams: Tech companies are removing middle layers, requiring engineers to be more independent.

  • Faster Delivery: To move quickly, the line between "thinking about the product" and "writing the code" must disappear.

However, after talking to managers, recruiters, and "Product Engineers", I realized that not everyone defines this role the same way. Here are the three main types of "Product Engineers" I have observed:

1. The "Label Switch" (Product in Name Only)

In these companies, the title is just a marketing trick. They swapped the word "Software" for "Product," but nothing else changed.

  • The Reality: Whether you are a junior or a senior, your job is the same as a traditional "heads-down" coder.

  • The Hiring Process: The interview is 100% technical. They don't assess your business knowledge or how you think about users.

  • The Day-to-Day: You receive a ticket, you code it, and you move on. The "product" part is just a fancy new sticker on your LinkedIn profile. You might negotiate the requirements or the sequence of shipping things with your PM, but that's the same thing as the past decades in any small to medium startup. Nothing new.

2. The Product-Minded Engineer

This is a more mature approach, often seen in tech companies with a transparent and flexible management style. Here, the engineer is a partner to the Product Manager (PM).

  • The Reality: Mid-level and senior engineers are expected to help improve requirements, not just follow them. There is a heavy focus on customer value over "tech talk."

  • The Hiring Process: Interviews include a specific section to discuss how you’ve solved user problems, how you collaborate with designers, and how you interact with the PMs in earlier stages.

  • The Day-to-Day: About 10% of your time is spent on product strategy. You are a pragmatist who knows when to choose a "good enough" technical solution to help the user faster. However, the PM still holds the final accountability for the roadmap.

3. The "Part-Time PM" Engineer

This is the most intense version of the role and the unicorn of that job title. These companies need someone who can lead a project from a blank page to a finished product.

  • The Reality: You are essentially a Product Manager who also writes code. You are responsible for the "Why" and the "How."

  • The Hiring Process: Be prepared for deep questions about product frameworks, data analysis, and user research. They want to see if you can lead a squad of engineers.

  • The Day-to-Day: You participate in ideation, talk to stakeholders, and conduct user interviews. You shape the work for the rest of the team and ensure the technical output matches the business goals perfectly. Expect extra accountabilities with this version.


Conclusion

The software industry is moving away from "coding as a service" toward "problem-solving as a service." Depending on the company, a Product Engineer can be a simple developer or a business leader. If you are looking for this role, make sure to ask during the interview: "How much influence do I actually have over the 'Why' of the product? And am I actually accountable for any decision made?"