Forem: Athreya aka Maneshwar

How Python's GIL actually works (and when it bites you)

Athreya aka Maneshwar — Sun, 10 May 2026 10:17:16 +0000

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

I remember the first time the GIL ruined my evening.

I was working on FreeDevTools and had a script that needed to parse, validate, and rewrite metadata for a few hundred thousand small markdown files and finally stores it into sqlite DB.

The bulk of my work was pure Python, a lot of looping, dictionary lookups, string concatenation, and small object churn. No NumPy, no Pillow, no native libraries doing the heavy lifting.

The single-threaded version was going to take forever, so I did what any reasonable person would do, I threw threads at it.

Eight worker threads. Should be a lot faster, right?

It was the same speed. Maybe a hair slower. I stared at the terminal for a solid minute thinking I'd done something wrong.

I had not done something wrong. I had met the GIL.

So what is it

GIL stands for Global Interpreter Lock.

The short version: it's a lock inside CPython (the standard Python you almost certainly use) that ensures only one thread executes Python bytecode at a time, within a single interpreter.

That word "bytecode" is doing a lot of work, and we'll come back to it.
For now, the simple version is: even if your laptop has 16 cores and you spin up 50 threads, only one of those threads is running Python code at any given instant. The rest are waiting their turn.

The threads do take turns.

CPython periodically gives other waiting threads a chance to acquire the GIL (the interval is 5 ms by default, tunable via sys.setswitchinterval()).

The actual handoff happens at the next safe point in the bytecode evaluation loop, so things look concurrent, even though no two threads are executing Python in parallel.

An analogy: you can hire ten cooks, but if there's only one knife, nine of them are watching the tenth one chop onions. They can rotate, but they can't chop simultaneously (Unless one of the cooks leaves the kitchen to wait for ingredients, which is roughly what happens during blocking I/O.)

One important caveat before we go further: the GIL is a CPython thing.
Other Python runtimes like Jython and IronPython don't use the same GIL model, and modern CPython now also ships an experimental free-threaded build.

When people say "Python has a GIL," they really mean "the most common Python implementation has a GIL."

Why does this exist

Not because anyone was lazy. The GIL is a real engineering tradeoff.

Python primarily manages memory with reference counting, plus a cyclic garbage collector for reference cycles.

Every variable assignment, every function call, every time you stuff something into a list, there's a counter being incremented or decremented in the background.

If two threads update those counters simultaneously without coordination, you get race conditions, and race conditions in memory management lead to crashes and corrupted data.

The alternatives to the GIL is fine-grained locking on every object, or rewriting the memory model that come with their own costs: more overhead per operation, slower single-threaded code, and a much harder life for anyone writing C extensions.

Much of the C extension ecosystem (NumPy, Pillow, lxml, every database driver) was built assuming the GIL exists. Rewriting all of that for thread safety is a generational project.

So the GIL stuck around because the tradeoff genuinely favored it: simpler implementation, faster single-threaded code, and an easy contract for C extensions.

The cost was no parallel execution of Python bytecode and for most users, that tradeoff was acceptable.

Let's actually see it

Here's a script that demonstrates the limitation. Two heavy countdowns, run sequentially, then again with threads:

import time
import threading

def countdown(n):
    while n > 0:
        n -= 1

COUNT = 50_000_000

start = time.time()
countdown(COUNT)
countdown(COUNT)
print(f"sequential: {time.time() - start:.2f}s")

start = time.time()
t1 = threading.Thread(target=countdown, args=(COUNT,))
t2 = threading.Thread(target=countdown, args=(COUNT,))
t1.start(); t2.start()
t1.join();  t2.join()
print(f"threaded:   {time.time() - start:.2f}s")

This benchmark is intentionally synthetic, a real workload has more nuance but it makes the core limitation visible in a way nothing else does.

The plot twist: threading isn't useless

Here's the part that took me embarrassingly long to internalize.

The GIL is released when Python is doing blocking I/O or, more precisely, when the C code implementing that I/O explicitly releases it.

Reading a file, waiting on a network request, querying a database, sleeping, the underlying C call releases the GIL during the wait, lets other threads run, then reacquires it on the way back.

Which means threading is genuinely useful, just not for what I initially thought.

import time
import threading

def fake_request():
    time.sleep(2)  # pretend this is a network call

start = time.time()
fake_request()
fake_request()
fake_request()
print(f"sequential: {time.time() - start:.2f}s")

start = time.time()
threads = [threading.Thread(target=fake_request) for _ in range(3)]
for t in threads: t.start()
for t in threads: t.join()
print(f"threaded:   {time.time() - start:.2f}s")

The rule of thumb that finally clicked for me:

if your workload is mostly waiting on I/O, threads often help a lot
if your workload is mostly computing in pure Python bytecode, threads usually won't speed it up

Web scrapers, API clients, anything that talks to a database or the filesystem for this, threading (or asyncio) is great.

Tight pure-Python loops that crunch data, threads will let you down.

Quick aside on asyncio, since it keeps coming up: asyncio isn't an alternative to threading for using more cores.

It's concurrency in a single thread i.e one event loop juggling many I/O-bound coroutines without the overhead of OS threads.

It's excellent for high-concurrency I/O workloads, but it does not bypass the GIL for CPU-bound Python code.

If your workload is CPU-bound, asyncio won't probably save you either.

When threads do use multiple cores

This is the section I wish someone had handed me a year ago.

The GIL only restricts execution of Python bytecode.

C extensions can release the GIL while they do their work in native code, and many of them do exactly that.

When the GIL is released inside a C extension, other Python threads can run in parallel on multiple cores.

This is why "threads can't use multiple cores in Python" is one of the most repeated half-truths on the internet.

Threads doing work inside a well-written C extension absolutely can.

If the underlying numerical or native library releases the GIL and isn't already saturating your CPU internally, threading on top can give you some parallelism. (If you want to go down the rabbit hole, this Stack Overflow thread has the canonical back-and-forth on the question)

This is also why scientific Python feels so much faster than the language has any right to be: most of the actual work is happening in C/C++/Fortran, and the GIL gets out of the way for the duration.

Okay but what if I genuinely need to crunch in pure Python

This is where multiprocessing comes in.

Each process gets its own Python interpreter, its own memory, its own GIL. Spin up four processes on a four-core machine, and you actually get four cores' worth of work — no lock fighting, no taking turns.

import time
from multiprocessing import Process

def countdown(n):
    while n > 0:
        n -= 1

if __name__ == "__main__":
    COUNT = 50_000_000
    start = time.time()
    p1 = Process(target=countdown, args=(COUNT,))
    p2 = Process(target=countdown, args=(COUNT,))
    p1.start(); p2.start()
    p1.join();  p2.join()
    print(f"multiprocessing: {time.time() - start:.2f}s")

The catch: processes are heavier than threads. They take longer to spin up, they don't share memory by default, and passing data between them involves serialization (usually pickling), which has its own gotchas. If you've ever seen a Can't pickle local object error, you've met one of them.

For most everyday cases, reach for concurrent.futures.ProcessPoolExecutor. It's a friendlier wrapper that makes multiprocessing feel almost as easy as threading.

The places it actually bites in real life

Times I've watched people (also me) get burned:

writing a "fast" data transformation in pure Python with threads, expecting linear scaling, getting none
threading a pandas pipeline that's mostly .apply() with a Python function. pandas drops into C and releases the GIL for vectorized ops, but .apply() calls back into Python — and Python is back to one thread at a time
web scrapers that thread the parsing with a pure-Python parser instead of the fetching. fetching is I/O (good for threads). HTML parsing can become CPU-bound, especially with html.parser. With lxml, you'd be fine because lxml releases the GIL, parser choice matters

The throughline is always the same: figure out whether your bottleneck is waiting, computing in pure Python, or computing in a C extension. Threading helps the first and third, not the middle.

Wait, isn't the GIL going away

Sort of.

PEP 703 the proposal to make the GIL optional in CPython — was accepted by the Steering Council in 2023, with explicit conditions: the rollout had to be gradual, ecosystem disruption had to stay manageable, and the entire effort could still be rolled back if it proved too disruptive.

Python 3.13 (October 2024) shipped the first experimental free-threaded build of CPython alongside the normal GIL-enabled build.
It allows running Python without the GIL, though many extension modules still rely on GIL assumptions and may re-enable it automatically when imported.

Python 3.14 substantially improved the experimental free-threaded runtime.
The adaptive interpreter was re-enabled, single-threaded performance penalties dropped substantially, and the project moved into Phase II of the Steering Council's rollout plan where free-threaded Python is considered supported, but still optional and not the default runtime.

CPython is clearly moving toward a future where no-GIL Python is viable but we're not at the point where the standard build is going away anytime soon.

What to actually do with all this

If I had to compress everything I wish someone had told me earlier:

When your code is slow, before reaching for any concurrency, profile it. Find out where the time is going. Then ask one question: is this thread waiting, computing in pure Python, or computing inside a C extension?

waiting → threading or asyncio will help a lot
pure Python → threading won't help; reach for multiprocessing, or find a library that drops to C (NumPy, polars, anything with a native backend)
C extension that releases the GIL → threading already helps; you may not need anything else

And don't feel dumb if you've been bitten by this. Everyone has. The GIL is one of those things that's obvious in hindsight and completely opaque the first time you hit it.

Now you've hit it on purpose, in a controlled environment, with a blog post next to you. That puts you ahead of where I was.

References

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a…

View on GitHub

Error Handling in Go: Stop Panicking, Start Wrapping

Athreya aka Maneshwar — Fri, 08 May 2026 19:30:03 +0000

So you wrote your first Go program. It compiled. You felt powerful. Then you saw this:

file, err := os.Open("dreams.txt")
if err != nil {
    return err
}
defer file.Close()

data, err := io.ReadAll(file)
if err != nil {
    return err
}

result, err := process(data)
if err != nil {
    return err
}

And you thought: "Wait... am I supposed to write if err != nil for the rest of my life?"

Yes, you are. But hear me out, it's actually kind of beautiful once you stop fighting it.

Why Go Did This To You (And Why It's Actually Fine)

Other languages treat errors like that one friend who shows up uninvited to your birthday party. They appear out of nowhere, ruin everything, and somebody else has to deal with them.

Go decided: errors are values. They're just things. Like strings. Or integers.

This means:

✅ Errors are visible in the function signature
✅ You can't accidentally ignore them (well, you can, but the linter will judge you)
✅ No invisible control flow jumping across 14 stack frames
❌ You have to type if err != nil approximately 9,000 times

It's a tradeoff. You'll grow to appreciate it. Or you'll switch to Rust. Both are valid.

Pattern 1: Just Return It

func loadConfig(path string) (*Config, error) {
    data, err := os.ReadFile(path)
    if err != nil {
        return nil, err
    }

    var cfg Config
    if err := json.Unmarshal(data, &cfg); err != nil {
        return nil, err
    }

    return &cfg, nil
}

When to use it: When you have nothing useful to add and the caller already has enough context.

When NOT to use it: When the caller is going to see unexpected end of JSON input and have absolutely no idea which of the 47 JSON files in your app caused it.

Pattern 2: Wrap It Like It's 1999

fmt.Errorf with %w. This is your new best friend. Treat them well.

func loadConfig(path string) (*Config, error) {
    data, err := os.ReadFile(path)
    if err != nil {
        return nil, fmt.Errorf("loadConfig: reading %s: %w", path, err)
    }

    var cfg Config
    if err := json.Unmarshal(data, &cfg); err != nil {
        return nil, fmt.Errorf("loadConfig: parsing %s: %w", path, err)
    }

    return &cfg, nil
}

Now when this fails, you get something like:

loadConfig: parsing /etc/app/config.json: unexpected end of JSON input

The %w verb wraps the error so callers can still inspect it with errors.Is and errors.As.

Use %v instead and you've turned your error into a string.

The error has been murdered. You are the murderer.

Pattern 3: Sentinel Errors (The Named Ones)

Sometimes you want callers to check for specific errors:

var (
    ErrNotFound      = errors.New("user: not found")
    ErrUnauthorized  = errors.New("user: unauthorized")
    ErrRateLimited   = errors.New("user: rate limited, chill out")
)

func GetUser(id string) (*User, error) {
    if id == "" {
        return nil, ErrNotFound
    }
    // ...
}

And the caller does:

user, err := GetUser(id)
if errors.Is(err, ErrNotFound) {
    return c.JSON(404, "user not found")
}
if err != nil {
    return c.JSON(500, "something exploded")
}

errors.Is walks the wrap chain, so even if the error got wrapped 12 times on its journey, you can still identify it. It's like DNA testing for errors.

Pattern 4: Custom Error Types (When You're Feeling Fancy)

Sometimes a string isn't enough. You want to attach data. You want a struct. You want to flex.

type ValidationError struct {
    Field   string
    Message string
}

func (e *ValidationError) Error() string {
    return fmt.Sprintf("validation failed on %s: %s", e.Field, e.Message)
}

func validateEmail(email string) error {
    if !strings.Contains(email, "@") {
        return &ValidationError{
            Field:   "email",
            Message: "missing @ symbol, are you okay?",
        }
    }
    return nil
}

And the caller pulls out the type:

err := validateEmail(input)
var vErr *ValidationError
if errors.As(err, &vErr) {
    fmt.Printf("Hey, your %s is broken: %s\n", vErr.Field, vErr.Message)
}

errors.As is errors.Is's overachieving cousin. It doesn't just check, it extracts.

Pattern 5: `panic` and `recover` (The Forbidden Techniques)

You may have heard of panic. Maybe you saw it in a library and felt a chill.

Rule of thumb: If you're panicking, you should probably be returning an error instead.

Real exceptions to the rule:

Truly unrecoverable situations (corrupt program state)
init() functions where the program literally can't start
Inside your own package, where you recover() at the boundary and convert to an error

func MustCompile(pattern string) *Regexp {
    re, err := Compile(pattern)
    if err != nil {
        panic(err) // genuinely fatal at startup
    }
    return re
}

If you're using panic for normal control flow, the Go gophers will find you. They have ways.

TL;DR For The Scrollers

Situation	Use This
Just bubbling it up with no extra info	`return err`
Want to add context	`fmt.Errorf("doing X: %w", err)`
Caller needs to check a specific error	Sentinel error + `errors.Is`
Caller needs error data	Custom type + `errors.As`
The world is ending	`panic` (sparingly!)

Final Thoughts

Yes, you'll write if err != nil a lot.

But here's the thing, once you stop seeing it as boilerplate and start seeing it as a decision point, every one of those blocks becomes a tiny little moment where you, the developer, get to think: "What does failure mean here? What does the caller need to know?"

That's not a burden. That's craftsmanship.

Now go forth and wrap your errors.

If you enjoyed this, drop a 🦫 in the comments. If you didn't, write if err != nil { return err } 100 times as penance.

*AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a…

View on GitHub

Shared Page Cache in SQLite: Smarter Memory, Less Redundant Work

Athreya aka Maneshwar — Thu, 07 May 2026 12:40:15 +0000

Hello, I'm Maneshwar. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

In SQLite’s default behavior, every database connection gets its own page cache.

This means that if your application opens the same database multiple times, even within the same thread and each connection loads and stores its own copy of data pages in memory.

This design keeps things simple and isolated, but it comes at a cost.

Memory usage increases because the same data may be stored multiple times, and disk I/O increases because each connection may read the same pages independently.

On desktops this might not matter much, but on constrained environments like mobile devices, this duplication becomes inefficient.

What Shared Page Cache Changes

Shared page cache is a feature that allows multiple database connections to reuse a single page cache instead of maintaining separate ones.

When enabled, connections to the same database within a process share both the page cache and the schema cache.

This means that once a page is loaded into memory, other connections can use it without reloading it from disk.

As a result, applications benefit from reduced memory usage and fewer disk operations, which can improve performance in read-heavy or multi-connection scenarios.

How SQLite Implements Shared Caching Internally

Even though connections share the cache, they are not merged into one.

Each connection still has its own internal B-tree structure, which represents how it interacts with the database.

However, these B-tree objects point to a shared structure known as BtShared.

This shared object contains the pager, which is responsible for managing the page cache.

Instead of each connection opening its own pager, they all rely on the same one.

SQLite keeps track of these shared structures using an internal list, and when a new connection is opened, it checks whether a matching database is already in use.

If it is, SQLite reuses the existing shared cache instead of creating a new one.

Enabling and Controlling Shared Cache

Shared caching is not enabled by default.

You can turn it on using the SQLite API:

sqlite3_enable_shared_cache(1);

To disable it, you pass 0 instead.

Shared cache operates at the process level, which means only connections within the same process can share memory.

Connections from different processes still operate independently and rely on standard file-level locking.

Locking Behavior in Shared Cache Mode

When multiple connections share the same cache, SQLite introduces additional locking mechanisms to ensure consistency and avoid conflicts.

These locks operate at different levels.

Transaction-Level Locking

At this level, SQLite ensures that only one connection can perform write operations at a time.

Multiple connections can still read concurrently, but writes are serialized to maintain database integrity.

Table-Level Locking

Shared cache introduces a limited form of table-level locking within the same process.

Instead of locking the entire database, SQLite can lock individual tables that are being accessed.

This allows different connections to work on different tables simultaneously, improving concurrency compared to the default mode.

Schema-Level Locking

Schema changes, such as creating or dropping tables, require stricter coordination.

SQLite locks the schema to ensure that all connections see a consistent structure and that no conflicting modifications occur during these operations.

Benefits of Using Shared Page Cache

The most immediate advantage of shared cache is reduced memory usage.

Since multiple connections reuse the same cached pages, the overall memory footprint decreases.

This is particularly useful for applications running on devices with limited resources.

Tradeoffs and Considerations

Shared cache introduces additional complexity in locking and coordination.

While it improves efficiency, it does not eliminate SQLite’s core limitation of allowing only one writer at a time.

Developers also need to be mindful of how multiple connections interact, as shared state can make debugging more challenging.

In many simple applications, a single connection is sufficient and avoids these complexities entirely.

*AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

AI Micro Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a habit,…

View on GitHub

4 Open-Source Security Tools Every Dev Should Know

Athreya aka Maneshwar — Wed, 06 May 2026 21:23:57 +0000

Hello, I'm Maneshwar. I'm building git-lrc, an AI code reviewer that runs on every commit. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

Go's standard library is solid. The ecosystem is mature. But none of that protects you from leaked secrets, vulnerable dependencies.

Security tooling fills the gap. The good news: the best tools in this space are open-source, free, and take about 1-10 minutes to set up.

Here are four that punch way above their weight — what they do, why they matter, and how to drop them into your workflow today.

1. Gitleaks — The Secret Scanner That Doesn't Sleep

⭐ 26k stars · gitleaks.io

Gitleaks scans your git history (yes, the whole thing) and your working tree for leaked secrets — API keys, AWS credentials, JWTs, private keys, the whole rogues' gallery.

It's basically the de facto standard.

gitleaks detect --source . -v

That's the whole command.

Run it, and within seconds it tells you exactly which commit, which file, which line you screwed up.

2. Semgrep — Grep, But It Actually Understands Code

⭐ 15k stars · semgrep.dev

Regular grep is a hammer. Semgrep is a scalpel.

Here's what makes it different: Semgrep is semantic.

If you write a rule looking for the value 2, it'll match x = 1; y = x + 1 because it knows y evaluates to 2.

That's not regex magic it's actual code comprehension.

For Go specifically, this means you can write rules like "flag any exec.Command call that takes user-controlled input" and it'll find them across your codebase, even when variable names differ.

Run it as a pre-commit hook to catch the dumb stuff before it ever hits CI:

semgrep --config=auto .

The auto config pulls community rules tailored to whatever languages it detects.

3. OSV-Scanner — Google's Vulnerability Detective

⭐ 10k stars · osv.dev

Your dependencies are a liability. Mine are too. Most projects don't talk about this enough.

OSV-Scanner is Google's answer, and it plugs into the OSV database — a unified vulnerability feed that aggregates data from dozens of sources.

Point it at your go.mod and it tells you exactly which deps have known CVEs and how bad each one is.

osv-scanner --lockfile=go.mod

The genuinely useful feature: guided remediation. It doesn't just yell "you have 47 vulnerabilities" — it ranks fixes by impact, dependency depth, severity, and return on investment.

It's the difference between a doctor saying "you're sick" and one handing you a treatment plan.

4. govulncheck — The Official One With Big Brain Energy

⭐ 470 stars · pkg.go.dev/golang.org/x/vuln

Don't let the modest star count fool you. This is the official Go vulnerability scanner from the Go team itself, and it does something genuinely smarter than most of its competitors.

Most scanners say: "you import a vulnerable library, panic now."

govulncheck says: "you import a vulnerable library AND you actually CALL the vulnerable function in your code paths."

That distinction is huge. The signal-to-noise ratio is night and day. No more drowning in false positives for code paths you never even hit.

go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...

The other wild thing: it works on compiled binaries too.

AI Just Changed The Game

Here's the thing nobody wants to say out loud: AI is pushing your team's monthly code volume 2x to 10x higher than it was a year ago.

More code. More diffs. More chances for something subtle to slip through until PR or production.

Static scanners are necessary, but they weren't designed for this volume.

They catch known patterns — leaked secrets, known CVEs, known anti-patterns. They don't catch the new failure modes AI introduces:

Code that "seems to work" but doesn't handle the edge case the prompt forgot to mention
The same prompt yielding different implementations on different runs
Subtle regressions buried in 400-line AI-generated diffs nobody actually reads
Logic errors that only show up after the demo, in front of customers

When you ship AI-generated code, it's your responsibility to know what you're shipping.

The model can generate the patch.

Your team still owns the outage, the exploit, the rollback, and the customer trust.

The 60-Second Control Point

This is what I'm building git-lrc for — micro AI code reviews that run on every commit, before the diff enters git history.

Git-native: reviews your staged diff at commit time, while context is still fresh
Fast: a micro review takes about 30 to 60 seconds
Useful: summary + bug, security, and performance warnings before code moves downstream

Small diffs reviewed early beat large diffs reviewed late. Every time.

The four tools above are your foundation. git-lrc is the verification loop on top — the difference between "we vibe-coded it and shipped" and "we shipped, and we know what we shipped."

You can't delegate responsibility. But you can automate the part where you check the work.

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

AI Micro Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a habit,…

View on GitHub

6 Agent Gateway Platforms That Actually Exist in 2026 (And What They're Good For)

Athreya aka Maneshwar — Mon, 04 May 2026 16:10:51 +0000

Picture this: it's 1:47 AM. Your phone buzzes. It's your team lead.

The helpful little agent you spun up last quarter to "handle Tier 1 support tickets" has just confidently emailed 47 customers confirming refunds it has no authority to issue.

None of the refunds are real. The numbers are hallucinated. Support Slack is on fire.

You stare at the ceiling and ask the only question that matters:

Who is actually in charge of these things?

Yeah. About that.

The thing nobody warned you about

Everyone's talking about agents. Almost nobody's talking about what happens after you ship them.

You don't have one agent. You have thirty. Each one has its own MCP tools, its own model, its own access to your systems. One is talking to your DB. One is sending emails. One is calling another agent that's calling another agent. Nobody on your team can answer "who can do what" without opening four repos.

Then one of them does something dumb at 3 AM and you realize: there's no central place to see it, stop it, or roll it back.

That's the gap agent gateways fill. The category is barely a category yet — think "API gateways in 2015." Here's what's actually shipping in 2026.

Wait, what even is an "agent gateway"?

Quick mental model: an agent gateway is the load-bearing wall between your agents and the rest of your infra. LLM routing, MCP tool governance, agent registry, A2A traffic, audit logs. Same energy as Istio or Kong, just pointed at agents instead of microservices.

If the "wait, isn't this just an AI gateway?" question is starting to form in your head, I wrote about exactly that distinction a while back: Link below

Athreya aka Maneshwar

Apr 13

What's an AI Gateway and do you think you need one?

#ai #programming #webdev #productivity

Comments 2

5 min read

1. TrueFoundry — the "I have a real job and a real budget" pick

If you're running agents in an actual enterprise, the kind with a compliance team that asks uncomfortable questions — TrueFoundry is the grown-up in the room.

It's the only Gartner-recognized platform in this space. It's processing 10B+ requests per month for companies like NVIDIA and Siemens Healthineers. SOC 2, HIPAA, and ITAR compliance out of the box.

You can deploy it in your VPC or on-prem, which matters approximately 0% to indie hackers and approximately 100% to anyone whose legal team has ever uttered the phrase "data residency." Latency overhead is around 3–4ms, which means it's not going to be the bottleneck.

It does the whole stack: LLM routing, MCP tool governance, agent registration. One control plane.

The con? It's a full platform. If all you want is a lightweight proxy because you're hacking on a weekend project, this is overkill. It's an opinionated, batteries-included thing.

Best for: Teams that want one control plane for models, tools, and agents.

2. AgentGateway.dev — the open-source bet

Backed by the Linux Foundation's Agentic AI Foundation. Written in Rust. Supports LLM routing, MCP tool federation, and A2A agent-to-agent communication.

The architecture is right. Like, you read the design docs and nod.

But. It launched in April 2026. As in, weeks ago. There's no RBAC. No compliance certifications. No prod case studies. You are not going to get fired for picking this in 2027.

Think of it as the foundation for what agent gateways will look like in a couple years. If you're the kind of person who runs Arch on your work laptop and contributes patches to Envoy on weekends, you'll feel right at home.

Best for: Teams who want to contribute to the open standard and are comfortable building governance on top.

3. Kagent

If your team's response to "we have a new traffic problem" is always "have you considered an Envoy filter," this one's for you.

Kagent is built on KGateway (which is built on Envoy) and basically extends the service mesh pattern to agent traffic. It handles MCP authorization and is moving toward A2A support.

The pitch is elegant: you already govern microservice traffic with Istio/Envoy. Why not govern agent traffic the same way? Same mental model, same tooling, same on-call team yelling at the same dashboards.

Con: very early. Tightly coupled to the K8s ecosystem. If you're not already a service mesh shop, the learning curve is "go take a 3-day course on Envoy filters first."

Best for: Platform teams already deep in Kubernetes and Envoy who want agents to be Just Another Workload™.

4. Pragatix — the "compliance team won't stop emailing me" pick

Pragatix doesn't try to be a Swiss Army knife. It picks one job and does it: agent governance. Execution-layer controls. On-prem deployment. Built for regulated industries like finance, healthcare, "we get audited four times a year" energy.

It's the equivalent of those single-purpose UNIX tools. Doesn't do a million things. Does one thing.

Con: narrow feature set. No LLM routing, no MCP gateway, no observability dashboard. You're going to need to pair it with other tools.

Best for: Security and compliance teams in regulated industries who need agent governance yesterday and don't care that it doesn't also make coffee.

5. Obot AI — the MCP-flavored pick

Started life as an open-source MCP gateway. Now adding agent orchestration features on top. Think of it as MCP-first, agents-second.

The MCP server lifecycle management is genuinely good. Deploying, cataloging, access controlling MCP servers feels like a solved problem here. They also donated the MCP Dev Summit to the Linux Foundation, which is the kind of move that signals "we're playing the long game, not the acquihire game."

Con: primarily MCP-focused, not a full agent gateway. No LLM routing. No A2A support.

Best for: Teams whose pain is specifically "we have 40 MCP servers and no idea who deployed which one", with a bit of agent orchestration on top.

6. Operant AI — the security nerd pick

Operant isn't really a gateway. It's more like the threat intelligence shop for the AI agent world. They published the 2026 Guide to Securing MCP and identified the "Shadow Escape" zero-click exploit vector, which is exactly as terrifying as it sounds.

If your job involves writing words like "attack surface" with a straight face, you'll like what they're doing.

Con: monitoring and research, not prevention and governance. You can't put Operant in front of your agents and call it a day. You pair it with an actual gateway.

Best for: Security teams who want to deeply understand agent attack vectors before they get told to deploy governance with a 2-week deadline.

Cheat sheet

Because I know you scrolled here first:

Platform	LLM Routing	MCP Governance	Agent Registry	A2A Support	Self-Hosted	Compliance Certs	Maturity
TrueFoundry	✅	✅	✅	Roadmap	VPC/on-prem	SOC 2, HIPAA, ITAR	Prod (10B+ req/mo)
AgentGateway	✅	✅	Via A2A cards	✅	✅	None	Pre-prod
Kagent	Via Envoy	✅	Planned	Planned	K8s only	None	Early
Pragatix	❌	❌	✅	❌	On-prem	TBD	Early
Obot AI	❌	✅	Partial	❌	✅	None	Early-mid
Operant AI	❌	Security only	❌	❌	❌	None	Research phase

So what do I actually pick?

Here's my honest read:

You're at a real company shipping real agents to real users today? TrueFoundry. It's the only thing on this list that's both enterprise-ready and comprehensive. Everything else is either narrow, early, or both.
You're a platform team that already lives and breathes K8s + Envoy? Try Kagent.
You're regulated to the eyeballs and just need governance? Pragatix.
You're an MCP-heavy shop? Obot.
You're playing the long game and want to bet on open source? AgentGateway.dev — with the caveat that you're going to be writing a lot of glue code in the meantime.
You're on the security team? Operant for intel, plus one of the others for actual enforcement.

So yeah…

The agent gateway space right now is exactly where API gateways were in 2015. Early. Fragmented. A handful of credible options, a bunch of half-baked ones, and a clear sense that something like this is going to be load-bearing infrastructure for the next decade.

Bookmark this post. Check back in 6 months. I'd bet good money this list is twice as long by then, and at least one of these names will have been acquired by someone with a much bigger logo.

What are you running in front of your agents right now? Drop it in the comments. I'm curious how everyone else is solving this.

Locking, Savepoints, and In-Memory Databases in SQLite

Athreya aka Maneshwar — Thu, 30 Apr 2026 09:48:57 +0000

As we go deeper into SQLite, things start getting less about syntax and more about how the database behaves under real workloads.

Features like triggers and autovacuum shape behavior internally, but now we’re stepping into how SQLite handles concurrency, transactions, and performance tradeoffs.

This is where concepts like table-level locking (or the lack of it), savepoints, and in-memory databases become important.

Table-Level Locking (Or Why SQLite Feels Different)

One of the most important things to understand about SQLite is this:

SQLite does not support table-level locking
It uses file-level locking instead

This means the entire database file is treated as a single unit when it comes to locking.

What This Means in Practice

If one process is writing to the database:

Other writes are blocked
Reads may also be restricted depending on the lock state

So unlike larger databases:

You cannot have multiple writers working on different tables at the same time
Concurrency is limited at the file level

This design keeps SQLite simple and reliable, but it also introduces limitations in high-write scenarios.

A Clever Workaround: Splitting the Database

If you really need something closer to table-level locking, SQLite gives you a workaround.

You can:

Store different tables in different database files
Then combine them using the ATTACH command

ATTACH DATABASE 'orders.db' AS orders_db;
ATTACH DATABASE 'users.db' AS users_db;

Now your application can treat them like one logical database.

Why This Improves Concurrency

Because each file is locked separately:

One process can write to users.db
Another can write to orders.db

At the same time.

So while SQLite doesn’t support table-level locking directly, you can simulate it by splitting tables across files.

The Tradeoffs

This approach works—but it’s not free.

You introduce:

Multiple database files to manage
Multiple rollback journals
A master journal for multi-database transactions
Increased memory usage (each file has its own cache)

Also, transactions spanning multiple databases:

Are still ACID
But can be slower due to coordination overhead

So this is a tradeoff between concurrency and complexity.

Savepoints: Fine-Grained Control Inside Transactions

Transactions in SQLite are usually all-or-nothing.

But sometimes you don’t want to roll back everything,you just want to undo part of it.

That’s where savepoints come in.

What is a Savepoint?

A savepoint is a named checkpoint inside a transaction.

You create one like this:

SAVEPOINT sp1;

Now SQLite remembers the current state.

Rolling Back Partially

If something goes wrong, you can roll back just part of your work:

ROLLBACK TO sp1;

This:

Undoes changes made after sp1
Keeps the transaction active

This is very different from a full ROLLBACK, which cancels everything.

Releasing a Savepoint

Once you’re happy with changes, you can finalize them:

RELEASE sp1;

This commits that portion of the transaction.

Why Savepoints Matter

Savepoints are especially useful when:

You have complex operations
You want partial recovery
You don’t want to restart an entire transaction

They give you granular control, which is something basic transactions don’t offer.

A Small but Important Detail

Savepoints can be:

Nested
Reused (same name overrides previous one)

Also, SQLite keeps extra journal data while savepoints exist, because it needs that information to support partial rollbacks.

In-Memory Databases: Maximum Speed, Maximum Risk

Now let’s talk about performance.

SQLite allows you to create a database that lives entirely in memory:

sqlite3_open(":memory:", &db);

This creates a database with:

No files
No disk I/O
Everything stored in RAM

Why It’s So Fast

Because:

No disk reads/writes
No file system overhead

Operations become extremely fast, making this ideal for:

Testing
Temporary data
High-speed processing

The Limitations

This speed comes with serious tradeoffs.

1. Data is Not Persistent

Once the application closes:

The entire database is gone

2. Not Shareable Across Processes

Each in-memory database:

Exists only within one connection
Cannot be accessed by other processes

3. Risk of Data Loss

If:

The app crashes
The system crashes

All data is lost instantly.

4. Memory Usage

Everything lives in RAM, so:

Large datasets require large memory
Not suitable for heavy storage

When Should You Use In-Memory Databases?

They are great for:

Caching
Temporary computations
Unit testing
Prototyping

They are not suitable for:

Persistent storage
Critical systems
Large-scale datasets

*AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

AI Micro Code Reviews That Run on Commit

git-lrc

AI Micro Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a habit,…

View on GitHub

AUTOVACUUM in SQLite: How Your Database Cleans Up After Itself

Athreya aka Maneshwar — Wed, 22 Apr 2026 04:42:29 +0000

AUTOVACUUM in SQLite: How Your Database Cleans Up After Itself

Up to this point, we’ve looked at how SQLite handles logic (triggers), structure (views), and identity (autoincrement).

Now we shift focus to something less visible but equally important i.e how SQLite manages space inside the database file.

Because unlike many systems, SQLite stores everything in a single file.

And over time, that file doesn’t always behave the way you expect.

The Default Mode: Nothing Gets Smaller Automatically

By default, SQLite runs in non-autovacuum mode.

This means that when you delete data or update rows, the database does not immediately shrink.

Instead, something quieter happens.

The space that was used by deleted data becomes free pages, and these pages are added to something called a freelist.

SQLite keeps track of these pages and reuses them later when new data is inserted.

So internally:

The file size stays the same
Free space exists inside the file
Future inserts reuse that space

This is efficient, but it also means your database file can grow large and never shrink back down, even if you delete a lot of data.

Manual Cleanup: The VACUUM Command

If you want to actually shrink the database file, you need to run:

VACUUM;

This command:

Rebuilds the database
Removes unused pages
Returns space to the file system

However, there are two important constraints:

It cannot run inside a transaction (BEGIN ... END)
It must be executed manually

This is why it’s called manual vacuuming.

Enter AUTOVACUUM: Automatic Space Reclaiming

SQLite provides a feature called autovacuum, which changes how this process works.

When autovacuum is enabled:

Freed pages are still tracked during a transaction
But at commit time, SQLite returns unused space back to the file system automatically

This means:

The database file can shrink on its own
You don’t need to run VACUUM manually

Once autovacuum is enabled, the VACUUM command becomes mostly unnecessary.

The Catch: Files Can Only Shrink From the End

Here’s where things get interesting.

Operating systems generally cannot remove space from the middle of a file. They can only shrink a file from the end.

So if SQLite frees pages in the middle of the file, it cannot just delete them directly.

Instead, it has to:

Move valid data from the end of the file into free space earlier in the file
Free up pages at the end
Then shrink the file

This process is called relocation, and it is essentially a form of internal compaction.

Pointer Map Pages: The Hidden Data Structure

To make relocation possible, SQLite needs to track how pages are connected. This is where pointer-map pages come in.

These are special pages inside the database that store:

The type of each page
The parent page that references it

Each entry is very compact:

1 byte → type
4 bytes → parent page number

This allows SQLite to quickly:

Find relationships between pages
Update references when pages are moved

Without this structure, relocating pages safely would be extremely difficult.

Why Pointer Maps Matter

In a normal database tree, parent pages point to child pages. But during relocation, SQLite needs the reverse—it must find the parent of a page quickly.

Pointer-map pages provide exactly that:
👉 a fast lookup from child → parent

This is critical when:

Moving pages
Updating references
Maintaining database integrity

Types of Pointer Map Entries

Each page in the database is categorized using a type:

ROOTPAGE → top-level page, no parent
BTREE → regular internal page with a parent
OVERFLOW (1st page) → linked from a data cell
OVERFLOW (next pages) → linked from previous overflow page
FREEPAGE → unused space

These types help SQLite understand how each page fits into the overall structure.

Tradeoffs of AUTOVACUUM

Autovacuum sounds like a clear win, but it comes with tradeoffs.

Advantages:

No need for manual cleanup
Database file stays compact
Space is returned to the system automatically

Disadvantages:

Slightly larger database size (due to pointer-map pages)
Extra overhead during commits
More internal complexity

When Should You Use AUTOVACUUM?

Autovacuum is useful when:

Your database frequently deletes or updates data
File size matters (e.g., mobile apps, embedded systems)
You want automatic maintenance

You might avoid it when:

You want maximum performance
You prefer manual control using VACUUM
Your data doesn’t change frequently

Final Thought

Autovacuum is one of those features you rarely think about—until your database file grows far larger than expected.

By default, SQLite optimizes for reuse, not shrinkage.

Autovacuum flips that behavior and keeps your file size in check, but it does so by adding internal complexity and overhead.

Understanding this tradeoff helps you decide whether you want a database that:

Reuses space efficiently, or
Actively keeps itself compact

Both approaches are valid.

The right choice depends on how your application actually uses data.

*AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

AI Micro Code Reviews That Run on Commit

git-lrc

AI Micro Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a habit,…

View on GitHub

What Building with MCP Taught Me About Its Biggest Gap

Athreya aka Maneshwar — Mon, 20 Apr 2026 16:58:14 +0000

I spent the last few weeks wiring up MCP at my org, stitching a handful of internal tools (GitHub, Slack, Datadog) into a shared layer that multiple teams' AI agents could call into.

Useful. Powerful. And, about a week in, slightly alarming.

The same four or five "wait, doesn't MCP handle this?" questions kept coming up. Who's allowed to call this tool? What happens if a tool returns 50MB of data? Where are we logging any of this? How do I give Team A read-only access when Team B needs write?

Turns out: MCP doesn't handle any of it. Not because it's broken, because that's not what it's for.

MCP standardizes how agents talk to tools. It says nothing about who gets to, how much they can pull, or whether anyone's keeping receipts.

I can't drop my org's internal code into a blog post, so I rebuilt the same shape of problem in a tiny public repo.

Three MCP servers, one Gemini-driven agent, one minimal gateway, all runnable in five minutes.

So, MCP. What is it, again?

A thirty-second version of MCP, straight from the official docs:

The mental model that finally made it click for me: MCP standardizes the plug, not the power grid.

Your agent speaks MCP.

Your tools (GitHub, Slack, Datadog, your database) speak MCP.

They meet in the middle and everything Just Works.

Well. Almost everything.

The demo: one agent, three MCP servers, a Gemini brain

To make this concrete, I built the smallest possible setup, a repo anyone can clone and run in five minutes:

A GitHub MCP server that exposes get_readme, get_latest_commit, get_repo_files
A Slack MCP server that exposes send_message
A SQLite MCP server that exposes log_event, get_logs
A Gemini-driven agent that picks a tool, calls it, summarizes the result, and posts to Slack

Five processes, one loop. Here's what that actually looks like on screen:

Point the agent at a repo and off it goes:

taco@TCSIND-4shZvZXk:~/mcp$ node agent/agent.js
[agent] starting one-loop run
[agent] chosen tool: github.get_readme
[agent] summary: Ragfolio is an AI-powered portfolio template that uses RAG to answer professional questions based on your resume data. It is built with a modern stack including React, FastAPI, and Google Gemini for high-performance retrieval and generation.
[agent] demo loop complete

Try a bigger, more famous repo? Same agent, no code change:

taco@TCSIND-4shZvZXk:~/mcp$ node agent/agent.js https://github.com/vercel/next.js
[agent] starting one-loop run
[agent] target repo: https://github.com/vercel/next.js
[agent] objective: Summarize the project highlights for a dev audience.
[agent] chosen tool: github.get_readme
[agent] summary: Next.js is a full-stack React framework designed for building high-performance web applications with integrated Rust-based tooling. It extends the latest React features while providing optimized build processes and a robust ecosystem for enterprise-scale development.
[agent] demo loop complete

Slack confirms the summaries landed:

Everything works. High-fives all around. I'm ready to ship this to teams.

And then I actually think about what I just built.

What MCP quietly does not give you

MCP is a protocol. That's wonderful and that's also exactly the problem. Out of the box, vanilla MCP has:

No auth. Anyone who can reach port 4001 can call every tool on the GitHub server. In prod, that's a problem.
No RBAC. Every caller gets every tool, or no tools.
No audit. Unless you add logging to every server, by hand, there is no record of who called what.
No guardrails on outputs. If a tool returns a 2MB README, your agent happily eats 2MB of its context window. If a tool returns rm -rf /, your agent happily executes it too.
No shared policy layer. Every team ends up copy-pasting the same "validate tool name, wrap in { output, error }" boilerplate, each with its own subtly different bugs.

This is not a knock on MCP.

USB-C also doesn't come with a surge protector.

Those are separate products for good reasons.

But if you're running agents in an environment where the blast radius of "oops" is meaningful, you need that separate product.

The obvious place for that product to live? A gateway, sitting between every agent and every MCP server.

Putting a tiny gateway in front of everything

In my demo repo, the gateway is a single 90-line Express file (gateway/gateway.js). It does three things. Together, they cover 80% of the complaints above.

1. An allowlist — capability control in one `Set`

Every tool call is namespaced (github.get_readme, slack.send_message, db.log_event).

The allowlist is quite literally a JS Set:

const TOOL_ALLOWLIST = new Set([
  TOOL_NAMES.GITHUB_GET_README,
  TOOL_NAMES.SLACK_SEND_MESSAGE,
  TOOL_NAMES.DB_LOG_EVENT
]);

If an agent (or a prompt-injected-into-misbehavior agent) tries to call github.delete_repo, it never reaches the GitHub server.

The gateway refuses in three lines, logs the attempt, and sends back a polite error.

Notice what this isn't: a prompt that says "please don't call delete_repo."

Prompts are suggestions.

Allowlists are rules.

2. A guardrail — the content contract

Some tools return unbounded blobs.

READMEs in particular love to be 40KB of badges and marketing copy.

The gateway has a hardcoded cap:

if (
  tool === TOOL_NAMES.GITHUB_GET_README &&
  serverResponse.output.content.length > 5000
) {
  return { output: null, error: createError("README content exceeded 5000 characters") };
}

Here's that guardrail earning its keep on a deliberately gnarly repo:

taco@TCSIND-4shZvZXk:~/mcp$ node agent/agent.js https://github.com/juice-shop/juice-shop 
[agent] starting one-loop run
[agent] target repo: https://github.com/juice-shop/juice-shop
[agent] objective: Summarize the project highlights for a dev audience.
[agent] chosen tool: github.get_readme
[agent] first tool call failed: {
  message: 'Guardrail blocked response: README content exceeded 5000 characters',
  details: null
}

Juice Shop's README is enormous.

Without the guardrail, my agent would've burned half its context on emoji-laden marketing.

With the guardrail, the agent got a clean "nope, try something else" and my context window stayed intact.

3. Logging — audit trail for free

Every single call through the gateway i.e success, failure, allowlist rejection, guardrail block gets recorded to SQLite via the db.log_event tool.

Best-effort, fire-and-forget, one await in the middleware.

Now when someone asks "what did the agent do yesterday?" the answer is a query, not a shrug.

That's it.

That's the whole governance layer.

An allowlist, a guardrail, a log roughly 200 lines of Node, no framework, readable in a single sitting.

But a toy gateway is still a toy

Here's where I have to be honest with myself.

My gateway works for the demo.

It would not survive contact with a real organization.

The allowlist is one Set shared by everyone. No per-team, per-agent, per-use-case scoping.
Guardrails are hardcoded conditionals. Adding a new one means a code change and a redeploy.
Authentication is nonexistent. Anyone who can curl :3000/mcp is an agent now.
Routing is three localhost URLs in a map. No service discovery, no health checks, no retries.
Adding a new tool means editing three files.

Solving each of those is a weekend project.

Solving all of them, operating them, and keeping them maintained as tools come and go across teams, that's a platform team's full-time job.

The feature I wish I'd built first: the Virtual MCP Server

While researching what a grown-up version of this gateway looks like, I came across TrueFoundry's MCP Gateway and specifically their concept of a Virtual MCP Server.

It's one of those ideas that's obvious in retrospect and I'm mildly annoyed I didn't think of it first.

The idea:

You have a bunch of real MCP servers, each exposing lots of tools.

Some tools are safe.

Some are dangerous.

Some are fine for one team and a footgun for another.

Rather than giving teams access to whole servers, you compose a Virtual MCP Server, a curated, custom, named collection of tools pulled from whichever upstream servers you want.

Concretely:

Your doc-summary-bot Virtual MCP Server exposes just github.get_readme and slack.send_message. That's the full surface area.
Your release-bot Virtual MCP Server exposes github.create_release, github.tag_commit, and slack.send_message — but not github.delete_repo, even though the upstream GitHub server technically supports it.

No new deployments.

The virtual server is just configuration on the gateway, and each one gets its own allowlist, its own guardrails, its own auth scope.

This matters because of the failure mode it quietly prevents.

Here's a solid demo video explaining Virtual MCP Server.

What this looks like in a real workflow

Let me walk through the kind of agent I'd actually want to run in production, a compliance automation bot, operating entirely through a TrueFoundry MCP Gateway endpoint:

A PR merges to main. A webhook wakes the agent.
The agent calls github.get_diff via its Virtual MCP Server. Authenticated, not with a bare PAT pasted into an env var, but with a service token the gateway issued and can rotate.
The diff comes back. The gateway's guardrail notices it's 12,000 lines, well over the "unsupervised review" threshold and pauses the run, requesting human approval before continuing. (Try getting that out of a lone MCP server.)
A reviewer approves. The agent writes the diff plus metadata to MongoDB via db.store_diff.
It opens a Jira ticket via jira.create_issue, linking back to the diff.
It posts a summary to Slack via slack.send_message.

Six tool calls.

Four different upstream MCP servers.

One endpoint. Every call authenticated. Every call logged to the audit trail.

The single dangerous tool the agent isn't supposed to touch, even if a prompt injection convinces it to try it isn't prompted against.

It's simply not in the Virtual MCP Server, so calling it is a 404, not a judgment call.

That, to me, is the jump from protocol to platform.

Wrapping up

MCP gave us a clean, shared language for AI agents to talk to tools.

That's a big deal, and it's easy to underrate how much of a pain this was before MCP existed.

But a shared language isn't a shared policy.

If you're running more than one agent, or letting more than one team build agents, you will need the thing that sits between "call the tool" and "did we mean to let it call the tool."

That thing is a gateway.

You can build a toy version in an afternoon.

My demo repo is proof.

But for anything real — auth, RBAC, audit, per-scope capability boundaries, and the Virtual MCP Server trick you want a platform that treats governance as the product, not the afterthought.

Take a look at TrueFoundry's MCP Gateway and the Virtual MCP Server feature if you're at the "I'm giving real agents real tools and someone in security wants to talk to me" stage.

If you build something interesting on top of either, I'd love to see it. Happy gatewaying.

Triggers in SQLite: Automating Logic Inside Your Database

Athreya aka Maneshwar — Tue, 14 Apr 2026 18:19:58 +0000

So far, we’ve looked at how SQLite lets you query smarter (subqueries), structure cleaner (views), and control IDs (autoincrement).

Now we move into something more powerful—something that lets your database react automatically.

That’s where triggers come in.

A trigger is code that runs automatically when something happens in your database.

You don’t call it.
You don’t manually execute it.
It just runs behind the scenes.

The Three Parts of a Trigger

Every trigger is built on three things:

1. Event (When it runs)

This is what activates the trigger:

INSERT
UPDATE
DELETE

2. Condition (Should it run?)

An optional check using a WHEN clause.

If the condition is false → trigger does nothing.

3. Action (What it does)

The actual SQL logic:

INSERT
UPDATE
DELETE
SELECT

Real-World Use Case: Preventing Invalid Data

Imagine you're managing a banking system.

You don’t want a user’s account balance to go negative accidentally.

Instead of relying only on application code, you can enforce this rule directly in the database using a trigger.

CREATE TRIGGER prevent_negative_balance
BEFORE UPDATE OF balance ON accounts
WHEN NEW.balance < 0
BEGIN
    SELECT RAISE(ABORT, 'Balance cannot be negative');
END;

What’s happening here?

The trigger fires before the balance is updated.
It checks if the new balance is less than zero.
If true, it aborts the operation with an error message.

This ensures your data remains consistent no matter where the update originates.

Keeping Track: Audit Logs with Triggers

Another powerful use of triggers is maintaining an audit trail.

For example, tracking changes made to sensitive data like salaries or account details.

CREATE TRIGGER log_salary_update
AFTER UPDATE OF salary ON employees
BEGIN
    INSERT INTO salary_audit(employee_id, old_salary, new_salary, change_date)
    VALUES (OLD.id, OLD.salary, NEW.salary, datetime('now'));
END;

Now every time a salary is updated:

The old and new values are recorded
You get a timestamp of the change
No manual logging required!

When Triggers Go Wrong

While triggers are powerful, they can also introduce complexity if not used carefully.

Here are a few pitfalls to watch out for:

Hidden logic: Since triggers run automatically, it can be hard to debug unexpected behavior.
Performance impact: Multiple triggers on large datasets can slow down operations.
Recursive triggers: A trigger that modifies a table may unintentionally fire another trigger, creating loops.

Best practice: Keep triggers simple, focused, and well-documented.

Triggers are like invisible guardians of your database, they watch, react, and enforce rules without being explicitly called.

When used wisely, they reduce redundancy, improve consistency, and make your system more robust.

But like any powerful tool, they demand discipline.

Overuse or misuse can lead to confusion and performance issues.

The key is balance: use triggers where they shine, and keep your logic transparent and maintainable.

*AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

AI Micro Code Reviews That Run on Commit

git-lrc

AI Micro Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a habit,…

View on GitHub

What's an AI Gateway and do you think you need one?

Athreya aka Maneshwar — Mon, 13 Apr 2026 15:52:46 +0000

It usually starts simple.

You're building a feature in your team with an AI feature in the product.

One API call to OpenAI. Maybe wrapped in a small helper function. You ship a feature. It works. Then things start creeping in.

Another team wants to use it. Someone adds a second model. Now you’ve got API keys sitting in different repos.

Nobody’s really tracking usage. Finance asks how much you're spending on AI this month, you don’t have a clear answer which team is using how much.

Then security shows up asking where prompts and responses are going what are the guardrails list and share it with us.

And at some point, a provider slows down or goes down, and suddenly your app is stuck waiting on a single dependency you don’t control.

Now you’ve got:

Multiple teams calling different models
No centralized control
No clear cost visibility
Zero guardrails

This is usually the moment people start searching:
“Do I actually need an AI gateway?”

What an AI Gateway Actually Is (Without the Buzzwords)

If you’ve worked with backend systems, you already know how an API Gateway works.

It sits in front of your services and handles things like routing, authentication, rate limiting, and observability, so your services don’t have to deal with that themselves.

An AI Gateway works in a very similar way.

But instead of sitting in front of microservices, it sits in front of your model providers.

At its core, an AI Gateway is just a layer between your application and the LLM APIs you’re calling.

Instead of your app directly hitting providers like OpenAI or Anthropic, every request goes through this gateway first.

That one change unlocks a lot.

Now you have a single place that can:

Route requests across different models
Handle authentication centrally
Enforce rate limits
Track usage and cost at a detailed level (tokens, not just requests)
Apply guardrails on inputs and outputs
Give you visibility into what’s actually happening

Most teams don’t start here though.

They usually go through this progression:

1. Raw SDKs

You use something like the OpenAI SDK. Quick to set up, works great, as long as it’s just one team and one use case.

2. Simple proxies (like LiteLLM)

You add a thin layer to route between models. Helps a bit, but governance, security, and cost tracking are still pretty limited.

3. AI Gateway

This is where things become structured. Instead of every team doing their own thing, you now have a centralized control plane managing how AI is used across your org.

The key difference isn’t just routing, it’s understanding.

An API Gateway can tell you:
“this service got 10,000 requests.”

An AI Gateway can tell you:
“this team used 4M tokens on GPT-4, spent $X, and triggered guardrails 3 times.”

Without it, your AI usage grows organically (read: chaotically).
With it, you can actually manage it.

So… do you actually need one?

This is the part most people overcomplicate.

You don’t need a framework. You don’t need a 10-step checklist.

You just need to be honest about how your setup actually looks today, not how you think it looks.

You probably don’t need one (yet)

If your world is still pretty contained, you’re fine.

One team building one feature, calling one model, with a bill that’s small enough that nobody’s asking questions, this kind of setup doesn’t need extra infrastructure yet.

Seriously.

Adding an AI Gateway here is like adding Kubernetes to a side project.
You can do it. You probably shouldn’t.

Just ship.

You do need one (or you’re about to)

Now flip it.

multiple teams are using LLMs independently
you’re juggling OpenAI + Anthropic (or thinking about it)
someone from compliance said words like “HIPAA”, “GDPR”, “SOC 2”, blah, blah, blah...

finance asked for a breakdown and you gave them… vibes
you’ve had that one moment where you thought: “wait… did we just send something sensitive to an LLM?”

And then there’s that subtle moment where you realize something could go wrong.

Maybe you don’t know exactly what’s being sent in prompts. Maybe logs are incomplete. Maybe you’re not sure how to stop a bad request before it reaches the model.

That’s usually the signal.

You don’t feel like you’re running “complex infrastructure,” but the problems you’re dealing with are already infrastructure problems.

What a production AI setup actually looks like

This is where things stop being “a few API calls” and start looking like a system.

Recently, I came across TrueFoundry while digging into how teams handle this at scale, and it’s a pretty good example of what this setup looks like in practice.

Instead of every team managing their own keys and integrations, everything goes through one layer. That one change removes a surprising amount of chaos.

So now:

there’s a single API key internally (teams don’t touch provider credentials anymore)
you can set budgets and rate limits per team so one experiment doesn’t accidentally burn your entire budget
if OpenAI slows down, you can fallback to Anthropic automatically instead of your feature just breaking
every request is tracked prompt, response, tokens, cost — all of it
you can add guardrails PII filtering, prompt injection checks, whatever your security team keeps asking about
and the whole thing can run in your own VPC / on-prem so data isn’t flying around random third-party infra

Performance wise, this isn’t some heavy layer either.

We’re talking about handling 350+ requests per second on a single vCPU with sub-3ms latency, which means it adds control without slowing things down in any meaningful way.

Also worth noting, this space is becoming real infra, not just hacks.

Tools like this are already showing up in places like the Gartner Market Guide for AI Gateways, which is usually a signal that “okay, this is a category now”.

The boring but real conclusion

Most teams don’t wake up and say:

“today we implement an AI Gateway”

They get pushed into it by problems.

If you read the earlier section and thought:

“yeah… we’re kinda there already”

Then you probably are.

And the tradeoff is simple:
You either spend a bit of time setting up structure now, or you keep paying for it later in the form of confusion, rising costs, and occasional fire drills that nobody enjoys dealing with.

Pick your pain.

Try it (if you’re already feeling the pain)

At this point, you can keep patching things together… or just try something like TrueFoundry and see what a structured setup actually feels like.

You can get it running in your own cloud pretty quickly, without needing a long setup process or even a credit card.

Even if you decide not to stick with it, going through the process once will give you a much clearer picture of what’s missing in your current setup.

AUTOINCREMENT in SQLite

Athreya aka Maneshwar — Sun, 12 Apr 2026 17:45:35 +0000

When working with SQLite, generating unique IDs is something you deal with almost immediately.

Most developers assume that AUTOINCREMENT is required for this, but SQLite already handles auto-incrementing behavior by default in a slightly different way.

Default Auto-Increment Behavior

If you define a column like this:

CREATE TABLE t1 (
    a INTEGER PRIMARY KEY
);

SQLite will automatically assign values to a whenever you insert NULL or don’t provide a value at all.

For example:

INSERT INTO t1 VALUES (NULL);

In most cases, SQLite assigns a value that is one greater than the current maximum in that column. If the table is empty, it starts from 1.

This makes it feel like standard auto-increment behavior, and for many applications, this is more than enough.

The Subtle Catch

The important detail is that SQLite only guarantees current uniqueness, not historical uniqueness.

If you:

Insert rows → 1, 2, 3
Delete row with ID 3
Insert again

SQLite may reuse 3.

This is not a bug. It is simply how SQLite optimizes ID generation.

It avoids keeping extra state and just looks at existing values.

For internal systems, this usually doesn’t matter. But if IDs are exposed outside (like APIs or logs), reuse can create confusion.

What AUTOINCREMENT Actually Does

When you explicitly use:

CREATE TABLE t1 (
    a INTEGER PRIMARY KEY AUTOINCREMENT
);

SQLite switches to a stricter strategy.

Now, instead of checking the current max value, it remembers the largest value ever used and always generates a new value greater than that.

So even if you delete rows, old IDs are never reused.

This gives you a stronger guarantee:

IDs are unique across the entire lifetime of the table
No accidental reuse

The Role of sqlite_sequence

To make this work, SQLite maintains a special internal table called sqlite_sequence.

It stores:

Table name
Highest ID ever used

This table is created automatically when you first insert into a table that uses AUTOINCREMENT.

Each new insert updates this value so SQLite always knows what comes next.

Why Not Always Use AUTOINCREMENT?

At first glance, AUTOINCREMENT seems like the safer option. But it comes with tradeoffs.

It adds a small performance overhead
It requires maintaining extra state (sqlite_sequence)
It prevents reuse, which may not always be necessary

Also, SQLite has a limit on integer values. If the maximum value is ever reached, further inserts will fail.

SQLite already gives you auto-incrementing IDs without needing AUTOINCREMENT.

The keyword is only for stricter guarantees, not basic functionality.

Instead of blindly adding AUTOINCREMENT, you choose it only when your system actually needs that level of consistency.

*AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

AI Micro Code Reviews That Run on Commit

git-lrc

AI Micro Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a habit,…

View on GitHub

Subqueries & Views in SQLite: Writing Smarter, Cleaner Queries

Athreya aka Maneshwar — Sat, 11 Apr 2026 19:52:43 +0000

In the previous discussion, we explored how PRAGMA gives you control over SQLite’s internal behavior.

Now, let’s see how you actually structure smarter queries using subqueries and views.

These aren’t just SQL features.

They’re tools that help you write cleaner logic, reduce duplication, and make your database easier to work with.

Subqueries: Queries Inside Queries

At its core, a basic SQL query looks like this:

SELECT x FROM y WHERE z;

x → columns
y → tables
z → condition

Now here’s where things get interesting:
That z (the condition) can itself contain another query.

That’s a subquery.

A Simple Subquery Example

SELECT name 
FROM Students 
WHERE sid IN (
    SELECT sid 
    FROM Admitted_to 
    WHERE doj = 'Jan 01, 2000'
);

What’s happening here?

Inner query → finds student IDs admitted on a specific date
Outer query → fetches names of those students

The inner query runs first, then feeds results into the outer query.

Where You Can Use Subqueries

Subqueries aren’t limited to WHERE. You can use them in:

WHERE clause (most common)
FROM clause (as derived tables)
HAVING clause (with grouped data)

They act like temporary datasets inside your query.

Correlated Subqueries: When Things Get Dynamic

Now we step into more advanced territory.

A correlated subquery is one that depends on the outer query.

Example:

SELECT name 
FROM Students 
WHERE EXISTS (
    SELECT * 
    FROM Admitted_to 
    WHERE sid = Students.sid 
    AND doj = 'Jan 01, 2000'
);

What’s different here?

The inner query references Students.sid
That means it cannot run independently
It depends on each row from the outer query

How Correlated Subqueries Actually Execute

This is where many people misunderstand what’s happening.

For each row in Students:

SQLite takes that row’s sid
Substitutes it into the subquery
Executes the subquery
Decides whether to include that row

So instead of running once, the subquery runs multiple times.

This makes correlated subqueries:

Powerful
But potentially slower

When to Use Subqueries (and When Not To)

Use them when:

You want clear, readable logic
You need intermediate filtering
You’re avoiding complex joins

Avoid them when:

Performance is critical
A join can do the same job more efficiently

Views: Virtual Tables That Simplify Everything

If subqueries are about embedding logic, views are about reusing it.

A view is basically a saved query that behaves like a table.

But here’s the key detail:

A view does not store data
It stores only the query definition

Creating a View

CREATE VIEW view1 AS 
SELECT name, sid 
FROM Students;

This doesn’t create a new table.

Instead, SQLite stores the query definition internally.

Using a View

Once created, you can query it like a normal table:

SELECT name 
FROM view1 
WHERE sid = 1001;

Behind the scenes:

SQLite runs the original query
Then applies your new query on top

Why Views Exist (And Why You Should Care)

Views solve real problems:

1. Simplify Complex Queries

Instead of repeating a long query everywhere:

Write it once as a view
Reuse it everywhere

2. Hide Complexity

You can expose only what users need:

Hide joins
Hide sensitive columns
Present clean datasets

3. Provide Schema Independence

If your base table changes:

Your view may still work unchanged
Applications using the view stay stable

Temporary Views

SQLite also allows temporary views:

CREATE TEMP VIEW temp_view AS 
SELECT name FROM Students;

Exists only during the session
Automatically deleted when connection closes

Useful for:

Testing
Intermediate processing
Session-based logic

The Catch: Views in SQLite Are Read-Only

Unlike some databases, SQLite does not allow direct updates on views.

So these won’t work:

INSERT INTO view1 ...
UPDATE view1 ...
DELETE FROM view1 ...

If you need updates:

You must use triggers on the view
Those triggers then modify base tables

*AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

AI Micro Code Reviews That Run on Commit

git-lrc

AI Micro Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a habit,…

View on GitHub

Forem: Athreya aka Maneshwar

How Python's GIL actually works (and when it bites you)

So what is it

Why does this exist

Let's actually see it

The plot twist: threading isn't useless

When threads do use multiple cores

Okay but what if I genuinely need to crunch in pure Python

The places it actually bites in real life

Wait, isn't the GIL going away

What to actually do with all this

References

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

See It In Action

Why

Error Handling in Go: Stop Panicking, Start Wrapping

Why Go Did This To You (And Why It's Actually Fine)

Pattern 1: Just Return It

Pattern 2: Wrap It Like It's 1999

Pattern 3: Sentinel Errors (The Named Ones)

Pattern 4: Custom Error Types (When You're Feeling Fancy)

Pattern 5: panic and recover (The Forbidden Techniques)

TL;DR For The Scrollers

Final Thoughts

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

See It In Action

Why

Shared Page Cache in SQLite: Smarter Memory, Less Redundant Work

What Shared Page Cache Changes

How SQLite Implements Shared Caching Internally

Enabling and Controlling Shared Cache

Locking Behavior in Shared Cache Mode

Transaction-Level Locking

Table-Level Locking

Schema-Level Locking

Benefits of Using Shared Page Cache

Tradeoffs and Considerations

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

AI Micro Code Reviews That Run on Commit

See It In Action

Why

4 Open-Source Security Tools Every Dev Should Know

1. Gitleaks — The Secret Scanner That Doesn't Sleep

2. Semgrep — Grep, But It Actually Understands Code

3. OSV-Scanner — Google's Vulnerability Detective

4. govulncheck — The Official One With Big Brain Energy

AI Just Changed The Game

The 60-Second Control Point

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

AI Micro Code Reviews That Run on Commit

See It In Action

Why

6 Agent Gateway Platforms That Actually Exist in 2026 (And What They're Good For)

The thing nobody warned you about

Wait, what even is an "agent gateway"?

What's an AI Gateway and do you think you need one?

1. TrueFoundry — the "I have a real job and a real budget" pick

2. AgentGateway.dev — the open-source bet

3. Kagent

4. Pragatix — the "compliance team won't stop emailing me" pick

5. Obot AI — the MCP-flavored pick

6. Operant AI — the security nerd pick

Cheat sheet

So what do I actually pick?

So yeah…

Locking, Savepoints, and In-Memory Databases in SQLite

Table-Level Locking (Or Why SQLite Feels Different)

What This Means in Practice

A Clever Workaround: Splitting the Database

Why This Improves Concurrency

Pattern 5: `panic` and `recover` (The Forbidden Techniques)

1. An allowlist — capability control in one `Set`