DEV Community: Abhishek Sharma

The AI Price War Just Got Real: GPT-5.6 Drops 80% as ChatGPT Hits 1B Weekly Users

Abhishek Sharma — Mon, 31 Aug 2026 09:39:08 +0000

OpenAI cut GPT-5.6 Luna pricing by 80% this week, down to $0.20 per million input tokens, the same week it crossed 1 billion weekly active users and 2 million business customers. Layer on this: AI agent usage among professionals is now at 80.8% daily-or-more, up from 47.3% a year ago.

This isn't a capability story anymore, it's a cost-curve story. When inference gets this cheap, use cases that were previously too expensive to justify start to pencil out:

Always-on agents that poll and react continuously instead of running on a schedule
Batch processing large document sets that used to get sampled instead of fully processed
Embedding an LLM call into every step of a workflow instead of reserving it for the "hard" steps

Why this matters for what you're building

If your architecture still treats an LLM call as a scarce, rationed resource, gated behind caching layers and strict rate limits, it's worth revisiting that assumption this quarter. The unit economics that justified those guardrails six months ago may no longer hold.

The interesting engineering question isn't "can we afford to call the model here" anymore. It's "what breaks if we call it ten times more than we do today, and is that actually a good idea."

Curious what others are seeing: has this pricing shift already changed anything in your stack, or is the calculus still catching up to the sticker price?

The AI Price War Just Got Real: 11 Models Shipped in 20 Days

Abhishek Sharma — Mon, 24 Aug 2026 07:17:58 +0000

August 2026 set a record: 11 major AI models shipped in 20 days from five-plus providers, including GLM-5.2 Turbo from Z.AI, Qwen3.8-Max from Alibaba, Grok Imagine 2.0 from xAI, and Seedance 2.5 from ByteDance. Cost per intelligence unit dropped roughly 50% across tiers in the process.

The distribution war, not the model war

For a while, the story in AI was "who has the best model." That's no longer the interesting question. When 11 frontier-adjacent models ship in three weeks and prices are cut in half, raw capability stops being a differentiator fast. If your product's pitch was "we have model access," that pitch doesn't hold up anymore.

Security is becoming the new battleground

In the same window, both OpenAI (expanding its Daybreak program) and Anthropic (with its Mythos model) shipped dedicated cyber-defense models. That's not a coincidence. As the model layer commoditizes, the labs seem to be betting that trust, safety, and security are where the next round of differentiation happens, not benchmark scores.

What this means if you're building on top of models

A few practical takeaways:

Evaluate on total cost of ownership, not sticker price. Tokenizer changes and usage-based credit systems can eat into the "cheaper" pricing headlines fast.

Don't build a moat on access alone. If a competitor can get comparable output from a different provider at half the cost next month, access was never the moat.

Watch where labs are investing outside pure capability. Cyber-defense features, agentic tooling, and enterprise trust layers are early signals of where the next competitive line is being drawn.

The model war looks mostly won by commoditization. The next fight is over distribution, trust, and what gets built on top.

This week in AI + Indian markets: a zero-click exploit, an open-weight frontier, and a losing streak that snapped

Abhishek Sharma — Fri, 21 Aug 2026 04:52:07 +0000

Three stories this week span cybersecurity, model economics, and market structure — and they're more connected than they look. An AI coding agent turned a routine git clone into a full remote code execution. An open-weight model closed the gap with the world's best proprietary systems. And India's stock market found out that a seven-day losing streak looks very different when the people buying the dip are institutions with a decade-long mandate rather than traders chasing headlines.

Your IDE is now an attack surface

Cursor's AI coding agent shipped with a zero-click remote code execution flaw, tracked as CVE-2026-26268. The mechanics are simple, and that's what makes it dangerous: an attacker crafts a malicious Git repository, the victim's Cursor agent touches it (even just to index or review it), and a Git hook fires arbitrary code on the developer's machine. No click, no approval prompt, no user action beyond letting the agent do its job.

This wasn't an isolated bug. The same month, AWS Kiro was found rewriting its own MCP server configuration after reading hidden instructions embedded in a webpage, and GitHub's Agentic Workflows read private repository contents and posted them as a public comment. A separate deeplink flaw let an attacker get Cursor to install a malicious MCP server outright. The common thread is a feature interaction nobody flagged: once an agent starts autonomously executing operations — Git commands, config edits, tool calls — inside a repository or webpage it doesn't control, that surface becomes exploitable. Security teams have spent years hardening APIs, auth flows, and user inputs. The development environment itself, running with a developer's full local permissions, was never treated as something an outside party could reach into. CVE-2026-26268 is the clearest evidence yet that assumption doesn't hold anymore.

Open weights just caught the frontier

Moonshot AI's Kimi K3 landed at #3 on Artificial Analysis's Intelligence Index this week, beaten only by Claude Fable 5 and GPT-5.6 Sol Max — and it's fully open weight. The model runs 2.8 trillion total parameters with 104 billion active per token across 896 experts, handles a 1,048,576-token context window, and works natively across text, images, and video. On BrowseComp, a benchmark for real-world research and browsing tasks, it scores 91.2 against Claude Fable 5's 88.0 and GPT-5.6 Sol's 90.4.

What matters here isn't the leaderboard position, it's what it does to the buy decision. For most of this AI cycle, capability and openness moved together but pointed different directions: the best models were closed, and the open ones were a tier behind. That gap is now small enough that choosing a model is closer to a procurement decision than a capability one — weigh per-token cost, self-hosting control, and vendor lock-in against a few points of benchmark difference, rather than treating closed frontier models as the only serious option. A sensible architecture for a lot of production use cases: route the hard, judgment-heavy fraction of requests to a frontier closed model, and let an open-weight model handle the rest at a fraction of the cost.

Nifty snapped its losing streak. Retail didn't blink.

The Nifty fell for seven straight sessions before snapping the streak on Thursday, August 20, when the Sensex jumped 628 points and the Nifty reclaimed the 24,200 level, closing at 24,232. Crude oil, rising US bond yields, and geopolitical tension had driven the pullback; a stabilisation in global bond markets and gains in IT and financial stocks drove the rebound.

What's more interesting than the one-day bounce is what held steady through the drawdown. Domestic institutional investors kept buying every single day of the seven-session slide, even as FIIs sold. That's not a coincidence — monthly SIP inflows have stayed above ₹31,000 crore, and total mutual fund assets under management have crossed ₹80 lakh crore, both driven by retail money going in on autopilot through systematic investment plans. That flow doesn't care about crude oil prices, US bond yields, or a week of bad headlines; it shows up on the same date every month regardless. The old trading heuristic — watch FII flows, trade the direction — has lost a lot of its predictive power because DII buying, powered by SIPs, now offsets it more often than not. That's genuinely good for volatility. It's also worth sitting with the flip side: retail investors, via their mutual funds, are increasingly the marginal buyer holding the market up. That's a different risk profile than a market driven by foreign capital, and it's one worth understanding rather than assuming away.

The thread connecting all three: capability and control are being redistributed faster than the institutions built to manage them can adjust. AI agents now execute code with a developer's full permissions, and security models built for a slower, more supervised era haven't caught up. Open-weight models now sit a hair behind the closed frontier, and buying decisions built around "pay for the best" haven't caught up either. And retail capital, moving through SIPs on autopilot, now absorbs shocks that used to be FII-driven, and market narratives built around foreign flows haven't caught up. In all three cases, the tools moved first. The frameworks for thinking about them are still catching up.

I built two small Claude Code plugins this week - here's what I learned about hooks

Abhishek Sharma — Mon, 17 Aug 2026 08:01:47 +0000

I use Claude Code daily as a Software Engineer at Citrix, and two small frictions kept showing up in long agentic sessions:

I was reading every diff and tool-call output just to know if the agent was stuck, even though 90% of it was routine.
On long sessions, the original goal I gave the agent would quietly drift as the conversation went on.

Claude Code plugins can hook into lifecycle events (Stop, Notification, UserPromptSubmit, etc.) with a single command, so I built one plugin for each problem.

earshot — narrates instead of reading

earshot hooks Stop and Notification. Instead of reading the agent's full response, it narrates a short spoken summary — and by default says nothing at all unless the agent is asking a question, blocked, or failed.

That "silent by default" behavior wasn't my first instinct — it came from reading two peer-reviewed studies on blind and low-vision developers using AI coding tools. Both found the core problem was auditory overload, not silence. Developers already running a screen reader don't want a second voice narrating the same text.

waypoint — a goal that doesn't get lost

waypoint hooks UserPromptSubmit. You set a goal once:

/goal-set Fix the login bug on the checkout page

From then on, every prompt you send silently carries a one-line reminder of that goal as injected context — until you clear it with /goal-done. No manual re-explaining 40 messages into a session that's drifted.

$ /goal-status
Active goal (set 2h 15m ago): Fix the login bug on the checkout page

What I'd tell someone building their first plugin

Hooks are just a CLI you already know how to write. Read stdin, maybe write JSON to stdout, exit 0. No SDK, no framework — I used zero npm dependencies for both (pure Node fs/os/path).
Silence is a feature. For anything that fires on every prompt or every response, decide explicitly when it says nothing — a hook that's chatty by default gets disabled fast.
State lives in ~/.claude/<plugin>/, plain JSON, no database needed for something this small.
Test the hook path directly by piping sample JSON into it via stdin before you ever load the plugin — it's the fastest feedback loop.

Both plugins are MIT-licensed and install in one command:

/plugin marketplace add absep98/earshot
/plugin marketplace add absep98/waypoint

Repos: github.com/absep98/earshot · github.com/absep98/waypoint

Happy to answer questions about the hook lifecycle or plugin structure in the comments.

This week in AI + Indian markets: a safety pause, a price war, and a pullback that isn't what it looks like

Abhishek Sharma — Mon, 17 Aug 2026 05:00:06 +0000

Three stories from the past week worth more than a scroll-past — one about how close AI safety came to a real test, one about what's happening to the economics of building with AI, and one about what's actually driving the Nifty right now.

1. OpenAI paused a model — not for what it said, but for what it could do

OpenAI halted internal work on its unreleased "Astra" model after internal testing found it could potentially develop zero-day exploits autonomously — without a human in the loop. That's not a hypothetical: Astra is the first model in the nearly three-year history of OpenAI's Preparedness Framework to trigger the "Critical" cybersecurity threshold, the point at which a system is treated as capable of causing severe harm if misused.

In response, OpenAI put Astra under isolated testing environments, restricted network and tool access, encrypted model weights, sandboxed execution, and real-time chain-of-thought monitoring that can interrupt high-risk activity as it happens.

Why it matters: AI safety discourse has largely lived in papers, frameworks, and hypotheticals. This is a frontier lab making a real product decision — delaying a model — because of what it demonstrated it could do, not what it said. For security teams and engineering leaders, it's worth understanding what "autonomous zero-day development" actually means in practice, and what containment looks like when it happens at a lab you don't control.

Source: Bloomberg, OpenAI

2. The AI price war just got real — 80% off

While one part of OpenAI was hitting the brakes on safety grounds, another part was cutting prices hard. GPT-5.6 Luna's API pricing dropped 80%, down to $0.20 per million input tokens, with GPT-5.6 Terra cut 20% — a direct response to pressure from DeepSeek V4 and other Chinese competitors undercutting on cost. The cut instantly pushed Luna into the "most attractive" tier of intelligence-per-dollar rankings from research firm Artificial Analysis.

Why it matters: Model intelligence is commoditizing faster than most roadmaps assumed. For anyone building AI-powered products, the competitive question is shifting from "which model is smartest" to "which model gives the most capability per dollar" — and that number is moving fast enough that architecture decisions made six months ago may already be outdated.

Source: CNBC, VentureBeat

3. Nifty broke its winning streak — but the buyers didn't leave

Indian equities snapped a two-week winning streak in the week of August 10–14: the Nifty 50 fell 0.83% to 24,366, and the Sensex dropped 0.62% to 78,009. Rising crude oil prices and renewed Middle East tensions were the drag, overshadowing resilient corporate earnings.

Here's the detail that matters more than the headline: institutional flows didn't turn negative. FIIs were net buyers of ₹508 crore and DIIs net buyers of ₹356 crore in the cash segment on August 14. The 24,200–24,300 zone is holding as support, backed by the 50-day EMA, while a decisive move above 24,700 could reopen the path to 25,000–25,200.

Why it matters: A pullback driven by external shocks (oil, geopolitics) with institutions still net buying reads very differently from a pullback driven by institutional selling. The first usually resolves as consolidation; the second is often the start of something worse.

Source: Goodreturns

The through-line this week: capability, cost, and confidence are all moving independently right now — a model got too capable for its own safety framework, the price of capability is collapsing, and market confidence is being tested by external shocks rather than fundamentals. Worth tracking whether any of these three threads reverse next week.

AI Pricing This Week: DeepSeek Gets Cheaper, Claude Sonnet 5 Gets Pricier

Abhishek Sharma — Mon, 03 Aug 2026 05:07:13 +0000

Two pricing stories dropped this week that are worth a pause if you're building on LLM APIs.

DeepSeek V4 Flash exits preview — and undercuts its own flagship

DeepSeek V4 Flash left preview at $0.14 / $0.28 per million tokens (input/output) — and it's beating its own larger Pro model on agentic benchmarks, hitting 82.7% on Terminal-Bench. That's a smaller, cheaper model outperforming its own bigger sibling on agent tasks.

Claude Sonnet 5's introductory pricing ends September 1

Anthropic's introductory pricing for Claude Sonnet 5 ends September 1. The headline price rises from $2 to $3 per million tokens — but the bigger change is under the hood: a new tokenizer adds up to 35% more tokens for the same text. Combine the two and the real-world cost increase is closer to 2x, not 1.5x.

What this means if you're building

If your stack leans on frontier models by default, this is a good week to:

Re-benchmark smaller/cheaper models against your actual task, not just leaderboard scores
Audit token usage before the September 1 pricing change hits
Separate "frontier because it's necessary" from "frontier because it's the default"

Cheap isn't always what it looks like on the label, and expensive doesn't always show up as a sticker price change — sometimes it's a tokenizer.

Sources: llm-stats.com, aitoolsrecap.com

The AI Landscape This Week: New Models and the Rise of Vertical AI Tools

Abhishek Sharma — Mon, 27 Jul 2026 04:42:19 +0000

Three Models, One Week

Anthropic's Claude Sonnet 5, OpenAI's GPT-5.6 (shipped as three variants: Sol, Terra, and Luna), and xAI's Grok 4.5 all launched within weeks of each other this July. That's an unusual amount of frontier-model activity packed into a single month, even by 2026 standards.

But the more interesting story isn't the competition itself — it's the shift in strategy. Instead of chasing one model that does everything, providers are shipping deliberately specialized variants tuned for different jobs: speed vs. depth, cost vs. capability, latency vs. context length.

For developers, this changes the practical question. It's no longer "which model is best" in the abstract. It's "which model fits this specific use case, cost profile, and latency budget" — and that calculus can change per feature, not just per product.

The Quieter Trend: Vertical AI

Alongside the big model launches, a batch of narrower, vertical-specific AI tools shipped with a lot less noise:

Netchex's Mesh — an AI HR system built specifically for restaurants, hotels, and dealerships, handling payroll, compliance, and scheduling for deskless teams.
redSling's Zenith — a no-code agentic development platform for enterprises that want to build AI apps without giving up control of their data or models.
LALAL.AI's Lynx — a model built only for voice isolation and noise removal.
d1g1t's MCP server — connecting its wealth management platform directly into Claude, ChatGPT, and Copilot.

None of these are trying to be general-purpose. Each solves one operational problem well, for one industry.

Why This Matters for Builders

The pattern across both stories is the same: less "one model/tool to rule them all," more specialization. For teams building on top of AI, that suggests two practical takeaways:

Build a real evaluation framework for swapping models as new variants ship — don't hard-wire your stack to one provider's assumptions.
Look at narrow, painful workflows in your own industry. The teams shipping value right now aren't building another general chatbot — they're building the AI layer for one specific job.

What's a narrow workflow in your stack that a purpose-built model or agent could take off your plate? Curious what others are seeing in their own domains.

I got tired of running 4 browser extensions, so I built one

Abhishek Sharma — Mon, 20 Jul 2026 15:54:14 +0000

I had a website blocker, a Pomodoro timer, a tab suspender, and a time tracker installed at the same time — four separate extensions, four separate settings pages, none of them talking to each other. Starting a focus session meant manually turning on the blocker, then starting the timer, and neither knew the other existed. So I built TabInsights, which does all four and actually connects them.

What it does

Website blocker — block by domain, category, or schedule, with an optional typed "unblock challenge" for the days willpower isn't enough.

Pomodoro focus timer — one click starts a 15/25/45-minute sprint, which also auto-blocks distracting categories for the duration and unblocks them automatically when it ends. This is the part that actually solves my original problem — the timer and the blocker are the same feature, not two extensions coincidentally running at once.

Memory saver — auto-suspends tabs you haven't touched in a configurable window (15–60 min), freeing roughly 50MB of RAM each via chrome.tabs.discard(). Suspended tabs stay in your tab bar and reload exactly where you left off with one click.

Automatic time tracking — logs time per domain with no manual start/stop, and shows a daily focus score.

A few implementation notes

Manifest V3 removed persistent background pages, which meant every "ongoing" feature — sprint timers, the daily summary, auto-suspend checks, license re-validation — had to be rebuilt on chrome.alarms instead of a long-lived timer. The gotcha: Chrome clamps alarm intervals to a minimum of 1 minute in packaged (published) extensions, so anything needing finer granularity has to accept that floor rather than fight it.

The blocker uses declarativeNetRequest — you hand Chrome a set of match rules and it enforces them at the browser level. The extension never actually reads the blocked request; it can't, by design, which is also the honest answer any time someone asks whether a blocker "sees" their browsing.

The bigger architectural decision was privacy: the extension makes zero external network requests during normal use. That meant bundling the UI font locally instead of pulling from Google Fonts, using Chrome's on-device favicon cache instead of a favicon API, and replacing what used to be rotating Unsplash background photos with a CSS-only gradient. None of that needed a server to begin with — it was just easier to reach for one during early development, and ended up being worth ripping out.

Where it's early

This is genuinely early — first real push toward finding users happened this week, after building it primarily for myself. If you try it and something's missing or feels like four extensions wearing a trenchcoat instead of one, I'd like to hear it.

Free, with an optional one-time $4.99 Pro upgrade (site time limits, scheduled blocking, unlimited workspaces, cloud sync) — no subscription either way.

Chrome Web Store: https://chromewebstore.google.com/detail/jfnfcaeagpcloialnbhibiecbphohebm

I built a VS Code extension that reads your code aloud and narrates git diffs with AI

Abhishek Sharma — Mon, 13 Jul 2026 19:07:58 +0000

I do a lot of doc-heavy and review-heavy work, and I kept losing time re-reading dense markdown and PRs instead of just listening to them. "Just use a screen reader" doesn't really work for code — it reads asterisks and pound signs literally instead of understanding markdown structure. So I built Markdown TTS, a VS Code extension that actually parses the content first, then speaks it.

What it does

Two distinct modes:

1. Literal reading — strips markdown syntax properly (headings become "Heading level 2: ...", tables read as CSV, code blocks skipped, links keep their text) and reads it aloud via your OS's built-in voice — SAPI on Windows, say on macOS. Fully offline, no API key, no account. There's also an optional Microsoft Edge neural voice mode if you want higher quality and don't mind the request leaving your machine.

2. AI narration (bring your own key) — instead of reading a file verbatim, an LLM explains what it does in plain English, then narrates that explanation. There's also a command that runs git diff locally and speaks an AI summary of your uncommitted changes or last commit, which I now use as a last check before committing instead of re-reading a wall of red and green text. Works with OpenAI, Anthropic, or Groq (free tier, no card needed). Only these two commands ever contact an API — literal reading stays completely offline.

It also does voice input into Copilot Chat, triggering your OS's native dictation (Win+H on Windows, Start Dictation on macOS) instead of implementing its own speech recognition.

A few implementation details

Single-file extension, ~1100 lines, no framework
Windows local TTS is done by spawning PowerShell running System.Speech.Synthesis.SpeechSynthesizer. Pause/resume goes through a control file, since SAPI has no native pause primitive exposed from that surface
The Edge neural voice path splits text into ~1.5KB chunks and prefetches two chunks ahead over parallel WebSockets, so long files start speaking in seconds instead of blocking on a multi-minute synth job
Voice input triggers OS-native dictation rather than doing speech recognition itself — much simpler, and it means dictation quality is whatever your OS already gives you

One decision I'm fairly happy with: the extension ships no default keybindings. The obvious choice, Ctrl+Alt+<letter>, collides with AltGr on a lot of non-US keyboard layouts (Indian, German, French, Spanish, Nordic, and others), where the OS types an accented character instead of running the command. Rather than hijack keys that silently break for a large share of users, you bind exactly the ones you want yourself.

A use case I didn't originally plan for: reading agent skill files

A lot of AI coding tools now configure their behavior entirely through markdown — Claude Code's SKILL.md files, CLAUDE.md project instructions, Cursor's .cursor/rules files, and similar formats elsewhere. These are exactly the kind of structured markdown — nested headings, bullet lists, embedded code blocks — that this extension already handles well for docs and PRs. Pointing it at an agent skill file works the same way as pointing it at any other doc. Given how much of a developer's actual working files are turning into agent-config markdown instead of prose these days, this has quietly become one of the more practical everyday uses of it.

Where it's useful beyond the obvious

A few people who've tried it mentioned it's genuinely helpful for dyslexia and general screen-reader-adjacent use cases — that wasn't the original motivation (I built it for my own PR-review workflow), but it's turned out to matter more than I expected.

Current state

Free, 121 installs so far with basically zero marketing push until this week. Linux only gets the Edge voice path for now — no local TTS binary to shell out to there yet.

If you try it, I'd genuinely like to hear what's missing, or where it feels like a gimmick instead of something you'd actually keep in your workflow.

Marketplace: https://marketplace.visualstudio.com/items?itemName=AbhishekShr.markdown-tts

My Tests Required a Running Database. Interfaces Fixed That.

Abhishek Sharma — Wed, 03 Jun 2026 12:46:11 +0000

In Part 15, I deployed the backend to a real VPS. But there was a problem I'd been ignoring: the test suite needed a running PostgreSQL database and a Redis instance just to run. No database? Tests skip. No Redis? Panic.

That's not unit testing. That's integration testing pretending to be unit testing.

The Problem: Global Variables Everywhere

Every handler was a package-level function that reached directly into global state:

// Before — handlers called globals directly
func CreateEntry(w http.ResponseWriter, r *http.Request) {
    id, err := db.InsertEntry(r.Context(), userID, req.Text, req.Mood, req.Category)
    // ...
    cache.Delete(ctx, cacheKey)
}

db.InsertEntry called the global db.DB connection. cache.Delete called the global redis.Client. The handler was welded to its dependencies — no way to swap them out.

This meant:

Tests needed a running Postgres → slow, flaky, CI requires a database service
Tests needed Redis (or at least a non-nil client) → without it, cache.Delete panicked
Can't test a handler without testing the entire stack underneath it

The Fix: Interfaces + Dependency Injection

Step 1: Define What Handlers Need

Instead of importing db and calling db.InsertEntry, define an interface — "here's what I need, I don't care how you implement it":

// internal/handlers/handler.go
type Store interface {
    InsertEntry(ctx context.Context, userID int, text string, mood int, category string) (int64, error)
    GetEntryByID(ctx context.Context, entryID int, userID int64) (*models.Entry, error)
    GetAllEntriesPaginated(ctx context.Context, userID int64, limit int, offset int) ([]models.Entry, error)
    GetEntryCount(ctx context.Context, userID int64) (int, error)
    UpdateEntry(ctx context.Context, entryID int, userID int64, text string, mood int, category string) (int64, error)
    DeleteEntry(ctx context.Context, entryID int, userID int64) (int64, error)
    CreateUser(ctx context.Context, email string, passwordHash string) (int64, error)
    GetUserByEmail(ctx context.Context, email string) (int64, string, error)
}

type Cache interface {
    Set(ctx context.Context, key string, value interface{}, expiration time.Duration) error
    Get(ctx context.Context, key string) (string, error)
    Del(ctx context.Context, key string) error
}

type Handler struct {
    Store     Store
    Cache     Cache
    JWTSecret string
}

The Handler struct holds its dependencies. It doesn't know (or care) if Store is backed by Postgres, SQLite, or a fake in-memory map.

Step 2: Convert Functions to Methods

Every handler changed from a package-level function to a method on *Handler:

// Before — package-level function, calls global db directly
func CreateEntry(w http.ResponseWriter, r *http.Request) {
    id, err := db.InsertEntry(...)
}

// After — method on Handler, calls the injected Store
func (h *Handler) CreateEntry(w http.ResponseWriter, r *http.Request) {
    id, err := h.Store.InsertEntry(...)
}

One character changed in the function signature (h *Handler). Every db.Something() became h.Store.Something(). Every cache.Something() became h.Cache.Something().

The handler's logic didn't change at all. It still validates the request, calls the store, invalidates cache, returns JSON. It just doesn't know which store it's calling.

Step 3: Wire Real Dependencies in main.go

// main.go — production wiring
h := &handlers.Handler{
    Store:     &db.PostgresStore{},
    Cache:     redis.NewRedisCache(),
    JWTSecret: cfg.JWTSecret,
}

// Routes use h.Method instead of handlers.Function
http.HandleFunc("/register", middleware(h.Register))
http.HandleFunc("/login", middleware(h.Login))

db.PostgresStore already had methods like InsertEntry — they just needed to be on a struct instead of being standalone functions. Same with redis.RedisCache implementing Set/Get/Del.

Step 4: Build FakeStore for Tests

This is where it pays off. A FakeStore that satisfies the Store interface with zero infrastructure:

// fake_store_test.go — only exists in test files
type FakeStore struct {
    InsertEntryFn func() (int64, error)
    users         map[string]struct {
        id           int64
        passwordHash string
    }
}

func (f *FakeStore) InsertEntry(ctx context.Context, userID int, text string, mood int, category string) (int64, error) {
    return f.InsertEntryFn()  // returns whatever the test tells it to
}

func (f *FakeStore) CreateUser(ctx context.Context, email string, passwordHash string) (int64, error) {
    if _, exists := f.users[email]; exists {
        return 0, &pq.Error{Code: "23505"}  // simulate duplicate email
    }
    id := int64(len(f.users) + 1)
    f.users[email] = struct{ id int64; passwordHash string }{id, passwordHash}
    return id, nil
}

type FakeCache struct{}
func (f *FakeCache) Set(ctx context.Context, key string, value interface{}, expiration time.Duration) error { return nil }
func (f *FakeCache) Get(ctx context.Context, key string) (string, error) { return "", fmt.Errorf("cache miss") }
func (f *FakeCache) Del(ctx context.Context, key string) error { return nil }

FakeCache always returns "cache miss." FakeStore returns whatever the test configures via InsertEntryFn. No database. No Redis. No network calls. Tests run in milliseconds.

Step 5: Tests That Don't Need Infrastructure

func TestCreateEntry(t *testing.T) {
    h := &Handler{
        Store: &FakeStore{InsertEntryFn: func() (int64, error) {
            return 1, nil  // simulate successful insert
        }},
        Cache: &FakeCache{},
    }

    body := strings.NewReader(`{"text":"feeling good","mood":8,"category":"mood"}`)
    req := httptest.NewRequest(http.MethodPost, "/entries", body)
    ctx := context.WithValue(req.Context(), userIDKey, int64(1))
    req = req.WithContext(ctx)
    rec := httptest.NewRecorder()

    h.CreateEntry(rec, req)

    if rec.Code != http.StatusCreated {
        t.Errorf("expected 201, got %d", rec.Code)
    }
}

Three lines to set up the handler. No TestMain initializing a database. No env vars. No cleanup. go test runs instantly with zero external dependencies.

Token Refresh: Fixing the 24-Hour Session Problem

While refactoring handlers, I also fixed the authentication model. The old system issued a single JWT valid for 24 hours. If it leaked, an attacker had access for an entire day.

The new model:

Access token: JWT, 15 minutes, stateless (server doesn't store it)
Refresh token: UUID, 7 days, stored in Redis (server can revoke it)

Login Now Returns Two Tokens

// Access token — short-lived, for API calls
claims := jwt.MapClaims{
    "user_id": userID,
    "exp":     time.Now().Add(15 * time.Minute).Unix(),
}
tokenString, _ := token.SignedString([]byte(secret))

// Refresh token — long-lived, stored in Redis
refreshUUID := uuid.New().String()
key := "refresh_token:" + refreshUUID
redis.Client.Set(ctx, key, fmt.Sprintf("%d", userID), 7*24*time.Hour)

// Return both
json.NewEncoder(w).Encode(LoginResponse{
    AccessToken:  tokenString,
    RefreshToken: refreshUUID,
})

POST /refresh — Rotate Tokens

When the access token expires, the client sends the refresh token:

func Refresh(w http.ResponseWriter, r *http.Request) {
    key := "refresh_token:" + req.RefreshToken
    val, err := redis.Client.Get(ctx, key).Result()
    if err != nil {
        // Invalid or expired → force re-login
        errorResponse(w, http.StatusUnauthorized, "Invalid or expired refresh token")
        return
    }
    userID, _ := strconv.ParseInt(val, 10, 64)

    // Delete the old refresh token (one-time use)
    redis.Client.Del(ctx, key)

    // Issue new access token + new refresh token
    // ... (same JWT creation as login)
}

The old refresh token is deleted immediately — each refresh token is single-use. If an attacker steals a refresh token and the real user uses it first, the attacker's stolen token is already invalidated.

POST /logout — Server-Side Revocation

redis.Client.Del(ctx, "refresh_token:" + req.RefreshToken)

One line. Delete the refresh token from Redis. The access token will expire in ≤15 minutes naturally. No token blacklist needed.

Per-User Rate Limiting

The existing rate limiter tracked by IP address. Problem: behind a shared network (office, university), hundreds of users share one IP. One heavy user triggers the limit for everyone.

The fix is simple once you have authenticated users with user IDs in context:

func UserRateLimitMiddleware(next http.HandlerFunc) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        userID, ok := r.Context().Value(userIDKey).(int64)
        if !ok {
            errorResponse(w, http.StatusUnauthorized, "User not authenticated")
            return
        }

        key := fmt.Sprintf("user:%d", userID)

        if !IsAllowed(key, UserRateLimitRequests, UserRateLimitWindow) {
            http.Error(w, "Rate limit exceeded. Try again later.", http.StatusTooManyRequests)
            return
        }

        next(w, r)
    }
}

The Redis key changed from the IP address to user:123. Same IsAllowed function, same fixed-window algorithm, different key. The global rate limiter still exists on unauthenticated routes (/login, /register) — it runs before AuthMiddleware. The per-user limiter runs after, on protected routes.

Two layers:

IP-based → blocks brute-force login attempts
User-based → blocks individual users who abuse the API

What Changed Under the Hood

The middleware chain in main.go tells the full story:

// Unauthenticated routes — IP rate limiting
http.HandleFunc("/login", RateLimitMiddleware(LoggingMiddleware(h.Login)))

// Authenticated routes — IP + user rate limiting
http.HandleFunc("/entries", RateLimitMiddleware(AuthMiddleware(
    UserRateLimitMiddleware(h.CreateEntry),
)))

Request hits IP rate limit first → then auth middleware extracts user_id → then per-user rate limit checks against that user's quota → then the handler runs with injected dependencies.

What I Learned

Interfaces in Go aren't for abstraction — they're for testability. I didn't define Store because I might switch databases. I defined it because my tests shouldn't need a database to verify that a handler returns 400 on invalid input.

The _test.go suffix is powerful. FakeStore lives in fake_store_test.go. Go only compiles _test.go files during go test. The fakes don't ship in the production binary — zero runtime cost.

Token refresh isn't optional. A 24-hour JWT means a leaked token is valid for a full day. A 15-minute access token with a revocable refresh token means you can kill any session immediately via /logout.

Rate limiting changes meaning after authentication. Before auth, you're limiting IPs (blunt). After auth, you're limiting users (precise). Both are necessary — they protect against different attack vectors.

I Deployed My Go Backend to a Real VPS. Here's Exactly What Happened.

Abhishek Sharma — Fri, 29 May 2026 12:36:26 +0000

In Part 14, I finished HMAC webhook signing. The backend was complete — JWT auth, PostgreSQL, Redis caching, rate limiting, circuit breaker, worker pool, webhook delivery, migrations, Docker. All running locally.

But "runs on my machine" isn't a portfolio project. It's a homework assignment.

Time to ship it.

The Stack Being Deployed

Go backend — ~15MB Docker image (multi-stage build, CGO_ENABLED=0)
PostgreSQL 16 — with golang-migrate running schema migrations on startup
Redis — for caching, rate limiting, and refresh token storage
Oracle Cloud Free Tier — 1GB RAM, 45GB disk, already provisioned

Everything wired together with docker-compose.yml. One command to start the entire stack.

Step 1: The VM Was Fine, Actually

I was worried about the free tier specs. Turned out the "1GB" in the tier name refers to RAM, not disk. The actual disk is 45GB — plenty.

free -h    # 954MB RAM, 552MB available
df -h      # 45GB disk, 41GB free

The real constraint: no swap. Go's compiler is memory-hungry. Without swap, building the Docker image on the VM would exhaust RAM and kill the process. More on this in a moment.

Step 2: Install Docker

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker ubuntu
newgrp docker

The official install script handles everything — Docker Engine, containerd, Docker Compose plugin. One command, done.

Step 3: Clone the Repo

The repo is private. Created a fine-grained GitHub personal access token with Contents: Read-only permission. Used it to clone:

git clone https://TOKEN@github.com/absep98/Go_learn.git

Security note: never paste tokens in chat, email, or anywhere visible. Type them directly into the terminal. Tokens in chat history are compromised tokens.

Step 4: Create the .env File

The .env from my local machine needed two changes for Docker:

# LOCAL (wrong for Docker):
DB_HOST=localhost
REDIS_HOST=localhost

# DOCKER (correct):
DB_HOST=postgres    # ← service name in docker-compose.yml
REDIS_HOST=redis    # ← service name in docker-compose.yml

This is the Docker networking model: each container has its own localhost. The service names (postgres, redis) are DNS hostnames that Docker Compose registers automatically on the internal network. Containers talk to each other by service name, not by localhost.

Step 5: The OOM Problem

First build attempt:

docker compose up --build -d

The build ran for 30 minutes on the compile step, then the VM became unresponsive. SSH wouldn't connect. Classic OOM kill — the kernel killed processes when RAM was exhausted during go build inside Docker.

The fix: add swap space before building.

sudo dd if=/dev/zero of=/swapfile bs=1M count=1024
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab  # persist across reboots

With 1GB swap added, the build completed in ~5 minutes. The Go compiler used swap when it needed more than physical RAM allowed.

Why does building inside Docker use more RAM than running the binary?

The multi-stage Dockerfile has two stages:

Stage 1 (builder): golang:1.25-alpine (~300MB) + Go compiler + all source code. The compiler is memory-hungry — it loads your entire dependency graph to type-check and optimize.
Stage 2 (runner): alpine:latest (~5MB) + just the compiled binary (~10MB)

The builder stage is thrown away after compilation. But during the build, both stages are in memory simultaneously. On a 1GB machine with no swap, this is tight.

Step 6: The Firewall

Containers started. Tried hitting the health endpoint from my local machine:

Invoke-RestMethod : Unable to connect to the remote server

The app was running — docker compose ps showed all three containers up. The issue was Oracle Cloud's network security — a firewall layer outside the VM that blocks all ports by default except SSH (22).

Navigation path:

Compute → Instances → your instance → Networking tab
Click the Subnet link
Security tab → Default Security List
Add Ingress Rule: TCP, 0.0.0.0/0, port 8080

After adding the rule, immediate success:

Invoke-RestMethod -Uri http://140.245.202.129:8080/health

status  database  redis
------  --------  -----
healthy connected connected

Step 7: Full End-to-End Test

# Register
$body = @{email="test@example.com"; password="test123"} | ConvertTo-Json
Invoke-RestMethod -Uri http://140.245.202.129:8080/register -Method Post -Body $body -ContentType "application/json"
# → success: True, user_id: 1

# Login
$response = Invoke-RestMethod -Uri http://140.245.202.129:8080/login -Method Post -Body $body -ContentType "application/json"
$token = $response.access_token

# Create entry
$headers = @{Authorization = "Bearer $token"}
$body = @{text="First live entry!"; mood=9; category="milestone"} | ConvertTo-Json
Invoke-RestMethod -Uri http://140.245.202.129:8080/entries -Method Post -Headers $headers -Body $body -ContentType "application/json"
# → success: True, id: 1

Everything worked. The full stack — registration, JWT auth, PostgreSQL insert, Redis caching — running on a real public IP.

What the Multi-Stage Build Actually Does

This is worth understanding. The Dockerfile has two FROM lines:

# Stage 1: Heavy construction site (~300MB)
FROM golang:1.25-alpine AS builder
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o server ./cmd/server

# Stage 2: Clean delivery box (~15MB)
FROM alpine:latest
COPY --from=builder /app/server /app/server
CMD ["/app/server"]

Stage 1 builds the binary. Stage 2 takes only the binary — not the Go compiler, not the source code, not the build tools. The final image is ~15MB instead of ~300MB.

CGO_ENABLED=0 makes the binary fully static — it doesn't link against any C libraries from the OS. The binary runs on any Linux regardless of which C library it has. Copy it to a machine with no Go installed, it runs.

This is different from Java: a .class file needs the JVM to run. A Go binary is machine code — the CPU executes it directly with no runtime required.

What I'd Do Differently in Production

No HTTPS: The API is HTTP only. Production needs TLS — either via nginx as a reverse proxy terminating SSL, or Let's Encrypt directly. Anyone sniffing traffic can see the JWT tokens in plain text.

No domain name: 140.245.202.129:8080 works but isn't professional. A domain + HTTPS is the next step.

Secrets in .env on disk: The .env file sitting in the repo directory isn't ideal. Production would use Docker secrets, environment injection from a secrets manager, or at minimum ensure the file has restricted permissions.

Manual deployment: Every code change requires SSH + git pull + docker compose up --build. Production would have a CI/CD pipeline (GitHub Actions) that automatically builds and deploys on push.

No health monitoring: If the server crashes at 3am, nobody knows. Production needs uptime monitoring (UptimeRobot is free) and alerting.

These are real production concerns — but for a portfolio project demonstrating backend fundamentals, a live public IP with a working API is the right stopping point.

What's Live

http://140.245.202.129:8080

Endpoints:

GET /health — database + Redis status
POST /register — create account
POST /login — get JWT + refresh token
POST /refresh — rotate tokens
POST /logout — invalidate session
GET/POST/PATCH/DELETE /entries — journal entries (protected)
GET /metrics — request counts, latency per endpoint

Full source: github.com/absep98/Go_learn

My Webhooks Were Sending Data Anyone Could Fake. HMAC Signing Fixed That.

Abhishek Sharma — Mon, 18 May 2026 18:11:26 +0000

In Part 13, I built a worker pool that fires webhooks in the background when entries are created. The webhook delivery worked — but there was a security gap I'd already documented in the trade-offs section of my own code:

// TRADE-OFFS / WHAT PRODUCTION WOULD DO DIFFERENTLY:
// No request signing — production webhooks use HMAC-SHA256 signature in a header
// (X-Webhook-Signature) so the receiver can verify the payload wasn't tampered with

Time to close that gap.

The Problem: Unsigned Webhooks Are Unauthenticated

When my server fires a webhook, the receiver gets a JSON payload at their URL. But they have no way to know:

Did this actually come from my server?
Was the payload modified in transit?
Is someone replaying an old webhook?

An attacker who knows the webhook URL can send fake events. Without signing, the receiver has to either trust everything blindly or build their own authentication on top.

GitHub, Stripe, Twilio — every production webhook system solves this with HMAC signing.

How HMAC Signing Works

HMAC (Hash-based Message Authentication Code) uses a shared secret to produce a signature:

signature = HMAC-SHA256(payload_bytes, shared_secret)

The sender:

Computes signature = HMAC-SHA256(body, secret)
Sends both the body AND the signature in a header: X-Webhook-Signature: <hex>

The receiver:

Gets the body and the header
Computes expected = HMAC-SHA256(body, same_secret)
Compares expected == header_value
If they match → payload is genuine and untampered

An attacker can see the payload in transit but can't produce a valid signature without the secret. If anything in the payload changes (even one byte), the HMAC changes completely.

The Implementation

Step 1: The Sign Function

A pure function — same inputs always produce the same output:

// internal/webhook/sign.go
package webhook

import (
    "crypto/hmac"
    "crypto/sha256"
    "encoding/hex"
)

func Sign(payload []byte, secret string) string {
    h := hmac.New(sha256.New, []byte(secret))
    h.Write(payload)
    return hex.EncodeToString(h.Sum(nil))
}

Why hex encoding? Raw HMAC output is bytes — some are non-printable characters. You can't put byte(3) or byte(255) in an HTTP header. Hex encodes every byte as two printable characters (0-9, a-f). The result is always a clean, safe string.

Why []byte(secret)? hmac.New takes the key as bytes. secret is a string. Go doesn't auto-convert — explicit cast required.

Step 2: The Test

Before wiring it anywhere, verify the function produces the expected output for known inputs:

func Test_HexCode(t *testing.T) {
    hexString := Sign([]byte("hello"), "mysecret")
    hardCodedHexString := "f09399f0c446d84b31a080e57ec483392d41e6f512f3e7ada5027abbcd358c2a"

    if hexString != hardCodedHexString {
        t.Errorf("expected %s, got %s", hardCodedHexString, hexString)
    }
}

The expected value was computed from an online HMAC-SHA256 calculator. If the function produces the wrong value, the test catches it immediately — before touching any HTTP code.

Step 3: Wire It Into HTTPSender

HTTPSender previously had no secret. Added a Secret field:

// Before
type HTTPSender struct{}

// After
type HTTPSender struct {
    Secret string
}

Then updated Send() to sign the payload and set the header. The key change: switched from http.Post() (which doesn't let you set headers) to http.NewRequest() + httpClient.Do():

func (h HTTPSender) Send(url string, payload interface{}) error {
    data, err := json.Marshal(payload)
    if err != nil {
        return fmt.Errorf("failed to marshal payload: %w", err)
    }

    // Sign BEFORE wrapping in a reader (data is still []byte here)
    signature := Sign(data, h.Secret)

    body := bytes.NewReader(data)

    // http.NewRequest gives us a request object we can modify
    req, err := http.NewRequest("POST", url, body)
    if err != nil {
        return fmt.Errorf("failed to create request: %w", err)
    }

    req.Header.Set("Content-Type", "application/json")
    req.Header.Set("X-Webhook-Signature", signature)

    resp, err := httpClient.Do(req)
    // ... error handling, status check
}

Why sign before bytes.NewReader? data is []byte at that point — perfect for Sign. After bytes.NewReader(data), body is an io.Reader stream. You could still access data since it's still in scope, but signing from the raw bytes is cleaner and more explicit.

Step 4: Thread the Secret Through Config

The webhook secret is separate from JWT_SECRET — they protect different things:

JWT_SECRET signs auth tokens (inbound requests prove who the user is)
WEBHOOK_SECRET signs outbound webhooks (receivers verify the payload came from us)

Added to .env:

WEBHOOK_SECRET=your-webhook-secret-here

Added to config.go, read into cfg.WebhookSecret, and passed to HTTPSender at startup:

// main.go
worker.StartWorkerPool(
    cfg.WorkerPoolSize,
    cfg.WebhookURL,
    webhook.HTTPSender{Secret: cfg.WebhookSecret},
)

This is the dependency injection pattern from earlier — secrets are passed in, not read from os.Getenv() inside the function. Makes testing straightforward: pass a test secret, no env vars needed.

What I Had to Learn to Write This

http.Post vs http.NewRequest: http.Post is a one-liner convenience function — great for quick calls but returns no request object. To set custom headers, you need http.NewRequest to get a *http.Request you can modify, then httpClient.Do(req) to send it.

hmac.New argument order: hmac.New(hashFunction, key) — the key is the second argument. I initially passed them backwards. The test caught it immediately.

Why hex, not base64? Both would work for the header value. Hex is more common for webhook signatures (GitHub uses it), slightly more readable when debugging, and produces a fixed-length string that's easy to compare.

The Receiver Side

I didn't implement the receiver in this project — the webhook goes to webhook.site for inspection. But the receiver pattern would be:

func verifyWebhook(body []byte, signature, secret string) bool {
    expected := webhook.Sign(body, secret)
    return hmac.Equal([]byte(expected), []byte(signature))
}

Note hmac.Equal instead of ==. This does a constant-time comparison — it takes the same amount of time regardless of where the strings differ. A regular == comparison short-circuits on the first mismatch, which leaks timing information that an attacker could use to guess the signature byte by byte. For security comparisons, always use constant-time equality.

What I Learned

Test pure functions first, before wiring them anywhere. Sign is a pure function — no HTTP, no state, no side effects. Writing a unit test for it before touching Send() meant I knew the core logic was correct before dealing with HTTP plumbing.

The "strict mode" learning method works. For this feature, I wrote all the code myself with zero reference to existing files — only Go's standard library docs when I forgot a function signature. First attempt had several mistakes. Second attempt had two. Third attempt was clean. Real retrieval practice is painful but it sticks.

Security gaps you document will eventually come back. I wrote "No request signing" in my trade-offs section knowing I'd close it later. Documenting trade-offs isn't just for interviews — it's a backlog for future improvements.

Up next: shipping this to a real VPS.