DEV Community: Pavel Espitia

Streaming Long AI Jobs to the Browser: SSE Patterns From Building an Audit Tool

Pavel Espitia — Sun, 26 Jul 2026 15:12:56 +0000

The first version of the spectr-ai web frontend had a spinner. You uploaded a contract, the spinner spun, and several minutes later results appeared, or didn't. My test users (friends, so they were honest) all did the same thing: around the ninety-second mark they refreshed the page, killing the audit that was about to finish. A spinner with no progress is indistinguishable from a hang, and users act accordingly.

So I rebuilt the pipeline around Server-Sent Events, and most of what I learned wasn't in the SSE tutorials, because tutorials stream a chat completion for ten seconds and call it a day. Multi-minute jobs with real state are a different problem. Here's what actually mattered.

Why SSE and not WebSockets

Short version: the browser never needs to talk back mid-job. The client uploads a contract, then listens. That's exactly the shape SSE was built for, one-directional server-to-client over plain HTTP. No connection upgrade, no socket lifecycle management, and the browser's EventSource gives you automatic reconnection for free, which turns out to be the most valuable feature of the whole protocol. WebSockets would work, but I'd be maintaining bidirectional machinery to use ten percent of it.

Design the event vocabulary before writing any code

My first attempt streamed whatever the pipeline felt like emitting: raw model tokens, log lines, half-thoughts. The frontend became a parser for an undocumented format that changed whenever I touched the backend. Bad.

Second attempt: a fixed vocabulary of typed events, treated as a real API contract. Four types cover everything:

type AuditEvent =
  | { type: "progress"; step: string; current: number; total: number }
  | { type: "partial-finding"; finding: Finding }   // validated, complete finding
  | { type: "done"; summary: AuditSummary }
  | { type: "error"; message: string; recoverable: boolean };

Decisions inside that shape that earned their place:

progress carries semantic steps, not percentages. "Analyzing withdraw(), function 3 of 7" keeps a user at the screen through minute four. A bar crawling from 41% to 43% doesn't, and honest percentages are impossible anyway when you don't know how long each model call takes.

partial-finding is the retention feature. The pipeline finds issues one at a time, so I ship each one the moment it's validated. Users start reading the first finding while the model is still chewing on the rest, and the perceived wait collapses even though total time is unchanged. If your long job produces incremental results, streaming them beats any progress bar you could design.

Findings stream only after validation. Early on I forwarded findings as raw model output and occasionally streamed garbage straight into the UI. Now everything passes schema validation server-side first. Stream results, never stream your parsing problem.

error distinguishes recoverable from fatal. A single model call failing means retrying and telling the user, the audit continues. Out of budget or malformed input means the job is dead. The frontend does very different things with those, so the event must say which it is.

Reconnection: the part everyone skips

Laptops sleep. Phones switch networks. Proxies kill idle connections. Over several minutes, disconnection is a certainty at scale, and EventSource will reconnect automatically, sending a Last-Event-ID header with the last event it received.

That header is only useful if you built for it. Two requirements: every event gets a monotonic ID, and the server keeps a replayable log of events per job, independent of any connection. Which forces the real architectural insight: the job must not live inside the HTTP request. The audit runs somewhere durable and appends events to a log. The SSE endpoint is just a cursor over that log:

// app/api/audits/[id]/events/route.ts
export async function GET(req: Request, { params }: { params: { id: string } }) {
  const lastId = Number(req.headers.get("last-event-id") ?? -1);
  const job = await getJob(params.id);
  const encoder = new TextEncoder();

  const stream = new ReadableStream({
    async start(controller) {
      const send = (id: number, e: AuditEvent) =>
        controller.enqueue(
          encoder.encode(`id: ${id}\nevent: ${e.type}\ndata: ${JSON.stringify(e)}\n\n`),
        );

      // 1. Replay whatever this client missed
      for (const { id, event } of await job.eventsAfter(lastId)) send(id, event);

      // 2. Then follow the live log
      const unsubscribe = job.subscribe((id, event) => {
        send(id, event);
        if (event.type === "done" || (event.type === "error" && !event.recoverable)) {
          unsubscribe();
          controller.close();
        }
      });

      // 3. Heartbeat comment so proxies don't kill an idle connection
      const heartbeat = setInterval(
        () => controller.enqueue(encoder.encode(`: hb\n\n`)),
        15_000,
      );
      req.signal.addEventListener("abort", () => {
        clearInterval(heartbeat);
        unsubscribe();
      });
    },
  });

  return new Response(stream, {
    headers: {
      "Content-Type": "text/event-stream",
      "Cache-Control": "no-cache, no-transform",
      Connection: "keep-alive",
    },
  });
}

Replay-then-follow is the whole trick. A client that drops at event 12 reconnects, replays 13 through wherever the job is now, and continues live. Refresh the page mid-audit and you lose nothing. The heartbeat comment line (SSE ignores lines starting with :) keeps intermediaries from declaring the connection dead during a long model call, and no-transform stops well-meaning proxies from buffering your stream into uselessness.

Serverless will fight you on this

Everything above assumes the job outlives the request, and default serverless assumes the opposite. A function that dies at its time limit takes your four-minute audit with it, and "keep the function alive by streaming" only stretches the ceiling, it doesn't remove it, and now a client disconnect can kill the job for every other viewer of that audit.

What I landed on: separate the worker from the stream. The job runs in something with a long lifetime (a worker process, a queue consumer, a container, whatever your platform offers), writes events to shared storage, and the SSE function does nothing but read and forward. SSE endpoints become cheap and stateless, the job becomes durable, and reconnection falls out naturally because the log is the source of truth. If you're on a platform where a long-lived worker is genuinely unavailable, chunk the pipeline into resumable stages and accept the added complexity, but know that you're paying it to avoid a worker, not because streaming requires it.

Backpressure, or when the model outruns the browser

Local models on a decent GPU can emit events faster than a busy tab renders them, especially token-level progress. Two things saved me:

Coalesce chatty events server-side. Nobody needs 40 progress updates a second. I batch progress events on a short interval and send only the latest state per tick. Findings are never coalesced, every one ships. Classify your events as "latest value wins" or "every one matters" and throttle only the first kind.

Respect the stream's own signals. controller.enqueue piles into a buffer if the consumer is slow, and unbounded buffering on a multi-minute job is a slow memory leak. Check controller.desiredSize before enqueueing low-priority events and drop stale progress ticks when it goes negative. The client that skipped some progress frames catches up instantly at the next one, and nobody notices.

The pattern that ties all of this together: treat the event log as the product and the SSE connection as a disposable view of it. Every hard problem (reconnection, serverless limits, backpressure, even multiple tabs watching one audit) gets easy once the connection stops being where state lives.

What's the longest-running job you've had to keep a browser honest about, and what broke first?

A Typosquat Package Almost Got My Keys: Dissecting the Attack Safely

Pavel Espitia — Sat, 25 Jul 2026 15:12:20 +0000

A recruiter DM led to a "take-home" repo. Standard stuff, or so it looked. I cloned it, opened package.json, and one line stopped me: a dependency named clx-cookieparser. The real package is cookie-parser. That extra clx- prefix and the missing hyphen were the whole attack. I never installed it. Here is how I read it apart without running a single line, and the checklist that has saved me twice now.

I do smart contract security, but the boring truth is most attacks against developers do not touch the chain at all. They touch your machine, your environment variables, and your wallet files. This one wanted all three.

The bait

The repo was framed as a coding assessment for a "client." Clean README, a couple of real features, tests that passed. The kind of thing you skim and trust because it looks like work, not like a trap. That framing is the point. You are in "let me finish this task" mode, not "let me audit a stranger's code" mode.

The dependency list had mostly normal packages. Express, a test runner, a couple of utilities. And then clx-cookieparser, sitting in the middle like it belonged. Typosquatting works because your eyes autocorrect. You read "cookie parser," your brain fills in the canonical name, and you move on.

I did not move on, mostly out of habit. I keep npm configured so that installing is not a one-command reflex, which buys me time to look before anything executes.

Why I could read it without running it

Two settings do the heavy lifting here, and I recommend both to everyone:

# never run install/postinstall scripts automatically
npm config set ignore-scripts true

# with pnpm, add a cooldown so brand-new versions can't hit you instantly
pnpm config set minimumReleaseAge 1440   # 24 hours

ignore-scripts matters because the classic move is a postinstall hook that fires the moment you run install. Turn that off and cloning plus reading is safe, because nothing runs on its own. The cooldown matters because a lot of these malicious versions get yanked within hours of publication once someone reports them, so a 24-hour delay quietly dodges the freshest poison.

So I read. Reading is not running. That distinction is the entire safety model.

What the payload was shaped like

I want to be careful here, so I am describing structure, not handing anyone a recipe. No real payload code.

The package had two layers. The first layer, the code visible in the published tarball, was almost boring. It wrapped a real cookie-parsing function so the thing actually worked if you used it. That is camouflage. If the library breaks your app, you rip it out and the attacker loses. If it works, you keep it and stop looking.

The interesting part was a second dependency the first package pulled in, and here is the tell that made my neck prickle: that second dependency was present in the resolved dependency tree but did not appear in the lockfile the repo shipped. In other words, the code referenced a package that the committed lockfile did not account for. A supply chain that does not reconcile with its own lockfile is lying to you about something.

That second-stage package is where the real behavior lived. Reading its structure (not executing it), the intent was obvious from the surface it reached for:

It looked for environment variables and process env, the place people stash API keys, tokens, and RPC URLs.
It probed common wallet and keystore file locations in the home directory.
It assembled that data and prepared to ship it outbound to a remote endpoint.

Two-stage is a deliberate design. Stage one is quiet and passes a casual glance. Stage two carries the theft and hides behind an install-time or first-run trigger, one step removed from the package you actually named in your file. You have to follow the thread to see it.

The signals that gave it away

I did not need a fancy tool for the first pass. I needed to read like the code was guilty until proven innocent. The signals, roughly in the order they hit me:

The name. clx-cookieparser is not cookie-parser. Any prefix, swapped hyphen, or singular/plural flip on a popular package name is a five-alarm reason to stop.
Lockfile mismatch. A dependency resolving in the tree that the committed lockfile does not describe means the manifest and reality disagree. Legitimate projects reconcile.
Obfuscation and entropy. The second stage had chunks of high-entropy strings, the dense base64-looking blobs and hex that normal utility code just does not carry. Human-written cookie parsing is low entropy and readable. A wall of encoded bytes is a place to hide behavior from a reader.
Reach that does not match purpose. A cookie parser has no business reading your home directory or touching env beyond what it is handed. Capability that exceeds the stated job is intent.

For the entropy check you do not need to run anything either. You can eyeball it, or score strings statically. A rough sketch of the idea:

import math
from collections import Counter

def shannon_entropy(s: str) -> float:
    if not s:
        return 0.0
    counts = Counter(s)
    n = len(s)
    return -sum((c / n) * math.log2(c / n) for c in counts.values())

# high entropy long string literals in a "utility" package are a smell
for line in open("suspicious.js"):
    for token in line.split('"'):
        if len(token) > 120 and shannon_entropy(token) > 4.5:
            print("high-entropy blob:", token[:40], "...")

That is reading, scoring, and flagging. Never executing.

The checklist that saved me

This is the routine now, and it takes maybe five minutes on a fresh repo:

Read package.json dependencies out loud. Any name that is close-but-not-exact to a popular package gets verified against the real registry name before anything else.
Diff the dependency tree against the lockfile. Anything present in one and missing from the other is a stop sign.
Never let install scripts run by default. ignore-scripts true globally, opt in per project only when you trust it.
Grep for high-entropy string literals and unexpected network or filesystem calls in dependencies before install, not after.
Assume any repo from an unsolicited recruiter is hostile until proven otherwise. The social framing is part of the exploit.

I ended up feeding the repo through Argus Lens, the static repo scanner I built (lens.noctis.biz) partly because I got tired of doing this by hand. It flags build-time execution, lockfile-missing dependencies, and obfuscation without cloning or installing. But the tool just automates the checklist above. The checklist is the actual defense, and you can run it with your eyes.

I did not lose anything this time. The uncomfortable part is how close normal, get-the-task-done behavior came to running it. One npm install on autopilot and I would have shipped my env vars to someone.

What is your default posture when a stranger sends you a repo to run: trust and clone, or hostile until proven safe?

I'm Entering My First Sherlock Audit Contest: The Setup, the Plan, the Fear

Pavel Espitia — Fri, 24 Jul 2026 20:25:15 +0000

I have shipped software for 18 years. Roughly 8 of those in crypto. And this week I signed up for my first Sherlock audit contest, and my hands were a little cold when I clicked in. That gap tells you something about how competing in public feels versus building things.

I write secure code for a living. I built spectr-ai, an open-source AI smart contract auditor. I have read more Solidity than I can remember. None of that is the same as putting my name on a public leaderboard next to people who do this full time and win five figures per contest. So this post is me being honest about the setup, the plan, and the fear, before I have any results to brag about or hide.

Why a contest at all

There are a few ways to make money auditing. Firms hire you. Bug bounties pay you when you find a live bug. And contest platforms like Sherlock run time-boxed competitions where a protocol puts its code in scope, a pile of auditors (Watsons, in their language) hunt for bugs at the same time, and the prize pool gets split based on what you find.

The model is the part that pulled me in. Payouts are severity based. A valid High is worth more than a valid Medium, and the pot for a given issue gets shared among everyone who found it. If five people report the same High, they split that issue's reward. So the incentive is not just to find bugs, it is to find the bugs other people miss.

There is also a gate that matters if you care about ranking, not just cash. To climb from the entry tier you generally need to land 2 valid issues and clear a points threshold (around 20% of the top performer on a contest, from what I have read). That is a real bar. It stops the leaderboard from filling up with people who got lucky once. It also means my goal for the first contest is not "win." It is "submit 2 issues I can fully defend." Everything else is noise.

How I prepared

I did not open the code first. I spent the first two days reading old contest reports. Sherlock publishes them, and they are gold. You get to see what actually counted as a High, how judges reasoned about severity, which reports got downgraded to informational and why, and the shape of the mistakes that recur across protocols.

A few patterns jumped out fast:

Rounding and precision bugs in share/asset math show up constantly.
Access control that looks fine until you trace who can call an internal admin path through a proxy.
Oracle assumptions that hold on mainnet but break on an L2 or during sequencer downtime.
Reentrancy that is not the classic kind, but cross-function or cross-contract.

Reading reports also recalibrated my sense of what a "real" finding looks like. A lot of things I would flag in a code review ("this could be clearer," "add a check here") are not valid contest issues unless I can show funds at risk or an invariant broken. Severity is about impact plus likelihood, not tidiness.

The workflow: AI proposes, Foundry proves

Here is the rule I set for myself, and I am not breaking it: nothing gets submitted without a working Foundry proof of concept.

I use LLMs heavily, but as an idea generator, not an oracle. I run Ollama locally on WSL2 with qwen2.5-coder for the cheap fast passes, and I reach for a bigger model when a path looks promising. The loop looks like this:

I feed the model a contract plus the invariants I wrote down (more on that in another post) and ask it to enumerate attack paths, not to "find bugs." Open-ended "is this safe" prompts produce garbage. Specific "how could an attacker make totalAssets diverge from the sum of balances" prompts produce leads.
The model gives me candidate attacks. Most are wrong. Some are hallucinated functions that do not exist. I throw those out immediately.
For anything that survives, I write a Foundry test that either triggers the bug or fails to. If I cannot make it fail, it is not a finding.

A skeleton PoC looks like this:

// test/PocShareInflation.t.sol
pragma solidity ^0.8.20;

import "forge-std/Test.sol";
import {Vault} from "../src/Vault.sol";
import {MockToken} from "./mocks/MockToken.sol";

contract PocShareInflation is Test {
    Vault vault;
    MockToken token;
    address attacker = makeAddr("attacker");
    address victim = makeAddr("victim");

    function setUp() public {
        token = new MockToken();
        vault = new Vault(address(token));
        token.mint(attacker, 100 ether);
        token.mint(victim, 100 ether);
    }

    function test_firstDepositorInflation() public {
        // attacker deposits 1 wei, mints 1 share
        vm.startPrank(attacker);
        token.approve(address(vault), type(uint256).max);
        vault.deposit(1);
        // then donates directly to inflate share price
        token.transfer(address(vault), 50 ether);
        vm.stopPrank();

        // victim deposits and gets rounded down to 0 shares
        vm.startPrank(victim);
        token.approve(address(vault), type(uint256).max);
        vault.deposit(50 ether);
        vm.stopPrank();

        assertEq(vault.balanceOf(victim), 0, "victim minted zero shares");
        // attacker withdraws everything, including victim funds
    }
}

If that assert holds, I have something. If it does not, the model was wrong and I move on. The PoC is also what I paste into the report, because a judge should be able to run forge test --match-test test_firstDepositorInflation and watch it happen.

This is the same discipline I use everywhere. spectr-ai flags things, but a flag is a hypothesis, not a verdict. The PoC is the verdict.

The fear, handled honestly

The impostor feeling is real, and pretending it is not would be dishonest. Eighteen years of shipping does not translate to "I will place well against people who audit for a living." Those are different sports.

What settled me down was reframing the goal. I am not trying to top the board. I am trying to submit two issues I can defend line by line, learn how the judging actually works from the inside, and read every other Watson's report after the contest closes to see what I missed. The reports of a closed contest are the best paid course in the space, except it is free.

There is also a floor to the downside. The worst case is I submit nothing valid, lose a week, and learn a lot from the post-contest reports. That is a cheap tuition. The upside is a payout and a data point that I can actually do this.

I picked the contest this week. I am not naming it because I do not want to color anyone else's read of the same code, and honestly because I want to talk about method here, not about one protocol. Next posts will be about how I read the scope and how I turn invariants into findings.

If you have competed on a contest platform, what is the one thing you wish someone had told you before your first one?

Reading an Audit Contest Scope Like an Auditor: Invariants First, Code Second

Pavel Espitia — Fri, 24 Jul 2026 15:36:10 +0000

The first time I audited seriously, I opened the biggest contract in the repo and started reading line one. Two hours later I had a headache and zero findings. I had memorized how the code worked without ever asking what it was supposed to guarantee. That is backwards, and it took me a while to unlearn it.

Now I do not read Solidity first. I read the scope, and before I look at a single function body I write down what must always be true. Bugs are violations of those truths. If you do not know the truths, you are just admiring the code.

Step one: write the invariants before you read

An invariant is a property the protocol claims will always hold, no matter who calls what in what order. For a contest, I start with money and control, because that is where severity lives.

Two questions cover most of it:

Who can move funds, and under what conditions?
What must always hold about the accounting?

For a lending-pool-shaped protocol my starting invariant list looks like this, written in plain language before I care how any of it is implemented:

The sum of all user deposits minus all borrows equals the pool's available liquidity plus outstanding debt. Accounting must reconcile.
A user can only withdraw up to their own balance, never more, never someone else's.
A position can only be liquidated when it is actually under the health threshold.
Interest accrues monotonically, it never goes backwards in a way that lets someone repay less than they owe.
Only the borrower, or a liquidator on an unhealthy position, can reduce a debt.
Nobody except governance can change interest rate parameters or the oracle.

Notice none of that mentions a function name. These are the promises. Now my job for the rest of the contest is simple to state: find an ordering of calls that breaks one of these.

Step two: map the external entry points

Funds do not teleport. Something has to be called from outside for state to change. So I list every externally reachable function, because the attack surface is exactly that set and nothing else.

I do this fast with grep before reading anything carefully:

# every external / public function in scope
grep -rnE "function .*\b(external|public)\b" src/ \
  | grep -v "view\|pure"

I drop the views and pures because they cannot change state. What is left is the list of levers an attacker can pull. For a lending pool that is usually the familiar set: deposit, withdraw, borrow, repay, liquidate, and whatever admin setters exist.

Then I annotate each one with the invariant it could threaten. deposit and withdraw threaten the accounting reconciliation. withdraw threatens the "only your own balance" rule. liquidate threatens the "only when unhealthy" rule. The setters threaten the governance-only rules. Now I have a grid: entry points down one side, invariants across the top, and cells where they intersect are where I go hunting.

Step three: draw the trust boundaries

Most real findings live at the seams where the protocol trusts something it should not fully trust. Before reading logic I mark every boundary:

Oracles. Where does price come from? Can it be manipulated in a single transaction (spot price from an AMM is the classic footgun)? What happens if it returns stale data, or zero, or reverts?
Admin and roles. What can a privileged role do, and is any privileged path reachable through a proxy or a delegatecall in a way the code did not intend? "Admin can rug" is often out of scope, but "a non-admin can reach an admin-only effect" is a High.
Cross-contract calls. Every external call is a place where control leaves the contract and can come back (reentrancy), or where the callee can behave adversarially (a malicious token with a weird transfer, a fee-on-transfer token, a rebasing token).
Token assumptions. Does the code assume 18 decimals? Assume transfer returns a bool? Assume no fee on transfer? Each assumption is a boundary that a hostile token crosses.

For the lending pool, the oracle boundary is where I would look first, because "manipulate price, borrow against inflated collateral, walk away" is the shape of a lot of Highs.

Step four: now read the code, hunting for violations

Only now do I open function bodies. And I do not read them as "what does this do." I read them as "which invariant does this touch, and can I break it here."

Here is a mini worked example. Pseudocode, lending-pool-shaped, deliberately buggy:

// invariant at risk: a user can only withdraw up to their own balance
function withdraw(uint256 amount) external {
    uint256 shares = amountToShares(amount);
    // BUG: no check that balanceOf[msg.sender] >= shares
    balanceOf[msg.sender] -= shares;   // underflows? or does it?
    totalShares -= shares;
    token.transfer(msg.sender, amount);
}

Reading invariant-first, I do not ask "does this transfer tokens." I ask "does this enforce that you only take your own balance." The answer is no, there is no bound check before the subtraction. In old Solidity that underflows to a giant balance. In 0.8+ it reverts, so maybe safe... unless amountToShares rounds in a way that lets shares come out to zero while amount is nonzero, in which case you withdraw tokens while decrementing nothing. That is the crack. I go verify it with a Foundry PoC, because a hypothesis is not a finding until it fails a test.

Compare that to the oracle boundary:

// invariant at risk: only genuinely unhealthy positions can be liquidated
function liquidate(address user) external {
    uint256 price = ammPair.getSpotPrice();   // single-block manipulable
    uint256 collateralValue = collateral[user] * price;
    require(collateralValue < debt[user], "healthy");
    // seize collateral, repay debt
}

The invariant says liquidation only happens when a position is truly unhealthy. But price comes from a spot AMM read, which a well-funded attacker can push within a single transaction using a flash loan. So they can make a healthy position look unhealthy, liquidate it, and profit. The bug is not in the arithmetic, it is in trusting a manipulable source. Invariant-first thinking finds it because I already flagged the oracle as a boundary in step three, before I ever read this function.

Why this order matters

If you read code first, you get anchored on how it works and you start believing it. The author's mental model leaks into yours. You end up checking that the code does what it appears to intend, which is the opposite of auditing. Auditing is checking whether the code can be made to do what it must never do.

Invariants first flips the frame. You decide what the protocol promised, independent of the implementation. Then every function is a suspect measured against those promises. When I built spectr-ai, this is the structure I tried to bake into how it reasons: state the properties, then check the code against them, rather than free-associating about "vulnerabilities."

It is also faster. On the contest I picked this week, writing the invariant list took maybe 40 minutes and it turned a 2,000-line codebase into a short list of "here are the six things worth breaking, and here are the three seams where they probably break." That is a map. Reading line one to line two thousand is just wandering.

When you sit down with an unfamiliar codebase, do you write down what must always be true before you read it, or do you dive into the code and reconstruct the rules as you go?

What 67 Dev.to Posts in Three Months Taught Me About Writing for Developers

Pavel Espitia — Thu, 23 Jul 2026 15:58:59 +0000

Since the middle of April 2026 I have published 67 posts on dev.to. My best one has 576 views. That is not a humble brag, it is the honest ceiling of a security developer who decided to write in public and hit publish every day for three months. I want to lay out what actually happened, with the real numbers I have, because most "how to blog" advice comes from people who skip the unglamorous middle.

The number that surprised me

My top performer is a practical Ollama guide. A how-to. Run this model locally, here is the command, here is the gotcha on WSL2. 576 views.

Meanwhile the posts I was proudest of, the deep smart contract security pieces where I actually know things most people do not, consistently pulled roughly a fifth of the traffic. Not once. As a pattern. The local-AI how-tos beat the deep security content something like five to one on views, over and over.

That stung a little, and then it taught me something. My expertise is not what most readers came for. They came for a Tuesday problem: "I want to run a model on my machine without paying for tokens and it is not working." I happen to be able to answer that clearly. The fact that I would rather talk about reentrancy is my preference, not the reader's need.

Lesson one: write for the reader's Tuesday problem

The security posts assume you already care about smart contract security. That is a small room. The Ollama post assumes you have a laptop and a mild frustration, which is basically everyone in the building.

I did not stop writing security content. I write it because it is who I am and it is the work I want. But I stopped expecting it to travel. Content that solves a concrete, common, right-now problem travels. Content that requires you to already be in the niche does not, no matter how good it is.

Lesson two: niche expertise needs a bridge topic

Here is the move that started to work. Instead of choosing between "the thing people search for" and "the thing I know deeply," I bridge them. A post like "running a local model to triage code smells" sits on top of the popular Ollama topic but carries my security angle inside it. The Ollama part is the door. The security part is the room I actually wanted to show you.

That reframes the whole strategy. The popular topic is not a distraction from my expertise, it is the delivery vehicle for it. Nobody clicks "advanced oracle manipulation patterns." Plenty click "cheap local AI setup," and if I can teach one security idea while they are there, that is a win that would never have happened in a pure security post.

Lesson three: nobody comments until you ask

For a long stretch I got near-zero comments. Views, sometimes reactions, but silence. I assumed that was just how it goes for technical writing.

Then I started ending every post with one genuine question. Not "let me know what you think," which is noise. A specific question tied to the post: what is your default when a stranger sends you a repo, do you write invariants before you read code, that kind of thing. Comments started showing up. Not a flood, but real ones, from people with opinions.

The lesson is dumb in hindsight. A blog post is a monologue unless you explicitly hand the reader the mic. People will engage if you give them a small, concrete, low-effort opening. A big open-ended "thoughts?" is too much work to answer. A pointed question is easy to answer, so people do.

Lesson four: constancy beats motivation, so automate it

I publish daily, and I do not rely on feeling like it. I have a queue of drafts and a cron script that publishes the next one. The decision "should I post today" is where most blogging dies, so I deleted the decision.

The setup is not fancy. Drafts live in a folder, a script picks the next one and pushes it via the dev.to API, and cron runs it on a schedule. Roughly:

#!/usr/bin/env bash
set -euo pipefail

POSTS_DIR="$HOME/projects/pavelEspitia.github.io/posts"
NEXT=$(find "$POSTS_DIR" -name '*.md' -not -name '.*' | sort | head -n1)

[ -z "$NEXT" ] && { echo "queue empty"; exit 0; }

# publish $NEXT via the dev.to API, then move it out of the queue
publish_to_devto "$NEXT" && mv "$NEXT" "$POSTS_DIR/published/"
echo "published: $NEXT"

# one post a day at 9am, pulled from the queue
0 9 * * * /home/pavel/projects/pavelEspitia.github.io/publish-next.sh

The point is not the code. The point is that motivation is a terrible scheduler. A queue plus automation means I write in batches when I have energy, and publishing happens whether or not today-me feels inspired. Three months of daily posts did not come from discipline. They came from removing the daily choice.

Lesson five: distribution beats polish

I spent real time polishing early posts. Rewriting sentences, agonizing over structure. Those are not my top posts. My top posts are the ones on topics people actually search for, published consistently, cross-posted to more than one platform. The polish barely moved the numbers. The topic and the consistency moved the numbers.

That does not mean write badly. It means the marginal hour is better spent on "is this a thing people are looking for" and "did I actually ship it to where they are" than on the fourth pass of a sentence nobody will notice. Clear and published beats perfect and queued.

What I would tell myself in April

Write for the problem someone has on a normal Tuesday. Use the popular topic as the door to the room where your real expertise lives. End with a real question so the thing becomes a conversation. Put publishing on a script so your mood is not in charge. And accept that your favorite posts and your most-read posts will often be different posts, and that is fine.

Sixty-seven posts in, the compounding is subtle but real. Not viral, not a huge following, but a body of work that exists, a habit that runs on rails, and a much clearer sense of what readers actually want from me versus what I assumed they wanted.

If you write technical posts: what topic of yours quietly outperforms the stuff you are proudest of, and have you leaned into it or fought it?

The Cheap Way to Add AI Review to CI: Small Local Models Plus Prompt Caching

Pavel Espitia — Wed, 22 Jul 2026 15:46:53 +0000

I wired an AI code reviewer into CI, felt clever, and then looked at the bill after a busy week of PRs. Every push, every commit, sending full diffs to a big frontier model. It added up faster than I expected, and most of what it was reviewing was formatting changes and README edits that did not need a genius reading them. So I rebuilt it as two tiers, and the cost dropped hard without losing the catches that mattered.

The idea is simple. Do not send everything to the expensive model. Use a cheap model as a bouncer that decides what is even worth escalating, and reserve the big model (with caching turned on) for the files that could actually hurt you.

Tier one: a cheap triage pass

The first tier looks at the diff and answers one question: is anything here risky enough to justify a real review? That is a classification task, and classification does not need a frontier model.

I run this tier on a small local model. On my own machine that is Ollama with qwen2.5-coder, but in CI it can be a self-hosted small model or the cheapest cloud tier your provider offers. The job is triage, not judgment.

The triage prompt is deliberately narrow. I do not ask it to review. I ask it to route:

You are a triage filter for code review. For the diff below, output JSON only:
{ "risk": "low" | "high", "reason": "<one short phrase>" }

Mark "high" if the diff touches: auth, access control, money/token math,
cryptography, SQL or shell string building, deserialization, file paths,
network calls, or anything that changes who can do what.
Mark "low" for formatting, comments, docs, tests, renames, and config bumps.

DIFF:
<diff here>

A small model is perfectly good at "does this touch auth or money." When it says low, CI posts a one-line "no high-risk changes detected" and stops. No expensive call. In practice that shortcuts the majority of PRs, because most PRs really are docs, tests, and plumbing.

Tier two: the big model, but only on the risky files, with caching

When tier one says high, the risky files get escalated to the strong model. This is where the real review happens, and this is where prompt caching earns its keep.

The trick is that most of what you send the big model does not change between reviews. The system prompt (your review rubric, your severity definitions, your house rules) is identical every time. And your repo context (the surrounding files, the conventions, the interfaces the changed code depends on) is stable across the many small PRs that touch the same area. Caching that stable prefix means you pay full price for it once and a small fraction on every subsequent review that reuses it.

So I structure the request as: cached system prompt, then cached repo context, then the fresh diff last. Anthropic-style caching keys on a stable prefix, so the ordering matters. Stable stuff first, volatile stuff last.

# pseudocode, provider-agnostic shape
response = client.messages.create(
    model="big-model",
    system=[
        {
            "type": "text",
            "text": REVIEW_RUBRIC,            # never changes
            "cache_control": {"type": "ephemeral"},
        },
        {
            "type": "text",
            "text": repo_context_for(files),  # changes rarely
            "cache_control": {"type": "ephemeral"},
        },
    ],
    messages=[
        {"role": "user", "content": build_review_prompt(diff)},  # changes every time
    ],
)

The rubric and the repo context ride the cache. Only the diff is fresh each run. On a repo where lots of small PRs hit the same modules, the cache hit rate is high and the per-review cost of the big model drops to mostly the fresh tokens.

The GitHub Actions sketch

Wiring it together is not exotic. One job, two steps, conditional escalation:

name: ai-review
on: pull_request

permissions:
  contents: read
  pull-requests: write

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2
        with:
          fetch-depth: 0
          persist-credentials: false

      - name: Triage (cheap model)
        id: triage
        run: |
          git diff origin/${{ github.base_ref }}...HEAD > diff.patch
          python scripts/triage.py diff.patch > triage.json
          echo "risk=$(jq -r .risk triage.json)" >> "$GITHUB_OUTPUT"

      - name: Deep review (big model, cached)
        if: steps.triage.outputs.risk == 'high'
        env:
          MODEL_API_KEY: ${{ secrets.MODEL_API_KEY }}
        run: python scripts/deep_review.py diff.patch

The if: on the second step is the whole cost story. Low-risk PRs never reach the expensive model. High-risk ones get the full treatment.

The catch that diff-only review misses

Here is the part people get wrong, and it is the reason a naive AI reviewer gives you false confidence. If you only send the diff, the model cannot see cross-file bugs.

Say a PR changes a function's return type or the meaning of one of its parameters. The diff looks locally fine. The reviewer, seeing only those lines, approves it. But three other files call that function and now pass the old assumptions, and those files are not in the diff at all. The bug is real, it is severe, and diff-only review is structurally blind to it.

The cheap fix is to include the callers of changed functions in the context you send. You do not need to send the whole repo. You need the changed symbols plus everyone who touches them:

# find who calls the functions changed in this PR
changed_funcs=$(git diff origin/main...HEAD \
  | grep -oP '^\+.*function \K\w+' | sort -u)

for fn in $changed_funcs; do
  grep -rl "$fn(" src/ >> caller_files.txt
done
sort -u caller_files.txt

You feed those caller files into the tier-two context (the part that gets cached, since callers change slowly). Now when a change alters an interface, the model can see the code that relied on the old behavior and flag the mismatch. That single addition catches a class of bug that pure diff review will never see, and because callers are stable, they cost almost nothing after the first cached run.

What this actually buys you

The economics come from routing, not from a cheaper model doing the hard job. The small model is a filter, and filtering is cheap and easy. The big model does the real work, but only on the small slice that deserves it, and it pays full token price only on the changing diff while the rubric and context ride the cache.

I use pieces of this in how spectr-ai reasons about cost too: a fast local pass to decide what is worth a careful, expensive look, then the expensive look only where it counts. Running qwen2.5-coder locally for the triage tier means that stage is effectively free on hardware I already own.

The failure mode to avoid is treating the cheap tier as the reviewer. It is not. It is the bouncer. If your triage model starts writing review comments, you have given a hard job to the wrong tool. Keep tier one narrow, keep tier two well-fed with callers and cached context, and the bill stays small while the catches stay real.

If you run AI review in CI, are you sending bare diffs, or do you pull in the callers of what changed?

Run Qwen Coder & DeepSeek Locally: The 2026 Free AI Pair-Programmer Setup

Pavel Espitia — Thu, 16 Jul 2026 15:42:24 +0000

You're paying $10 to $20 a month for Copilot. You don't have to. A 2024-era laptop can run a coding model good enough for autocomplete, refactors, and "explain this function" entirely offline. No API key, no telemetry, no per-token bill. Here's the exact 2026 setup I run on a 16GB machine.

Why local in 2026

Two years ago, local coding models were a toy. The autocomplete was slow and the suggestions were noise. That changed. qwen2.5-coder and deepseek-coder-v2 are genuinely useful now, and the tooling caught up: Ollama serves them, Continue.dev wires them into your editor, and the whole thing runs on hardware you already own.

The pitch is simple:

Free. No subscription, no usage caps.
Private. Your proprietary code never leaves the machine. This matters if you work on smart contracts or anything under NDA.
Offline. Works on a plane, in a basement, behind a corporate firewall.

The tradeoff is quality and latency. We'll be honest about both.

Pick a model (and match it to your RAM)

This is the decision that makes or breaks the experience. Pick a model your machine can actually hold in memory, or it spills to disk and crawls.

# Fast, fits anywhere (8GB+)
ollama pull qwen2.5-coder:1.5b    # ~1.0GB
ollama pull qwen2.5-coder:3b      # ~1.9GB

# The sweet spot for most laptops (16GB)
ollama pull qwen2.5-coder:7b      # ~4.7GB

# Quality tier, needs headroom (32GB+ comfortable)
ollama pull deepseek-coder-v2     # ~8.9GB (16b MoE)
ollama pull qwen2.5-coder:14b     # ~9.0GB
ollama pull qwen2.5-coder:32b     # ~20GB

Rough rule: the model file size is the floor, then add a few GB for context and the OS. A 4.7GB model on a 16GB machine is comfortable. A 20GB model on the same machine is not.

Model	Size	RAM I'd want	Use it for
`qwen2.5-coder:1.5b`	1.0GB	8GB	Autocomplete, fast iteration
`qwen2.5-coder:7b`	4.7GB	16GB	Daily driver: chat, refactors, explain
`deepseek-coder-v2`	8.9GB	32GB	Harder reasoning, multi-file context
`qwen2.5-coder:32b`	20GB	64GB	Near-cloud quality, if you have the RAM

deepseek-coder-v2 is a 16b mixture-of-experts model, so it punches above what its file size suggests, only a couple billion parameters are active per token. It's the one I reach for when qwen2.5-coder:7b gives a shallow answer.

A note on quantization: those file sizes are the default 4-bit quants Ollama ships. They're the right call for a laptop. You can pull a higher-precision tag like qwen2.5-coder:7b-instruct-q8_0 for slightly better output, but it roughly doubles the memory and the speed cost, and on everyday coding tasks I can't tell the difference. Start with the defaults.

My actual setup on 16GB: qwen2.5-coder:1.5b for inline autocomplete (it has to be fast or it's useless), qwen2.5-coder:7b for the chat sidebar where I can wait two seconds. I keep deepseek-coder-v2 pulled but unloaded for the occasional gnarly problem, and let Ollama swap it in on demand.

Install and run Ollama

# Linux / WSL
curl -fsSL https://ollama.com/install.sh | sh

# macOS
brew install ollama

# Windows: download from https://ollama.com/download

Start the server. It listens on localhost:11434:

ollama serve

Confirm it's alive and a model responds:

ollama run qwen2.5-coder:7b "Write a TypeScript debounce function"

If that prints code, you have a working local LLM. Everything else is wiring.

Wire it into your editor with Continue.dev

Continue.dev is the open-source extension that turns Ollama into an editor assistant. It does chat, inline edits (highlight code, Cmd/Ctrl+I, describe the change), and tab autocomplete. Install it from the VS Code or JetBrains marketplace, then point it at your local models.

Edit ~/.continue/config.yaml:

name: Local pair programmer
version: 1.0.0
schema: v1

models:
  - name: Qwen Coder 7B
    provider: ollama
    model: qwen2.5-coder:7b
    roles:
      - chat
      - edit
  - name: Qwen Coder 1.5B (autocomplete)
    provider: ollama
    model: qwen2.5-coder:1.5b
    roles:
      - autocomplete

Two models, two jobs. The 1.5b handles the tight feedback loop of tab autocomplete where every millisecond shows. The 7b handles chat and multi-line edits where you'll tolerate a short wait for a better answer.

Restart VS Code, open the Continue sidebar, and ask it something about the file you have open. It reads your editor context and answers against your actual code, locally.

If you'd rather skip Continue and use the official Copilot-style hook, recent VS Code versions let you add Ollama as a custom model provider in the chat panel pointing at http://localhost:11434. Continue is still the more flexible option for autocomplete tuning.

One thing worth knowing: autocomplete and chat use different prompt formats under the hood. Continue handles this for you when you assign the autocomplete role, picking the fill-in-the-middle template the Qwen Coder models were trained on. If your inline suggestions come out garbled, it's almost always because a chat-only model got assigned the autocomplete role. The qwen2.5-coder family supports fill-in-the-middle at every size, which is why I use it for both jobs.

The 30-second sanity check with fetch

Before trusting any editor integration, hit the server directly. Ollama exposes an OpenAI-compatible endpoint, so this works with zero SDK:

const response = await fetch("http://localhost:11434/v1/chat/completions", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    model: "qwen2.5-coder:7b",
    messages: [
      { role: "system", content: "You are a senior TypeScript reviewer." },
      {
        role: "user",
        content: "Find the bug:\nfunction sum(a, b) { return a - b }",
      },
    ],
    temperature: 0,
    stream: false,
  }),
});

const data = await response.json();
console.log(data.choices[0].message.content);

No API key. No account. If this returns "it subtracts instead of adds," your local pair programmer is online and you can build anything on top of it.

For a streaming UI (the token-by-token effect), flip stream: true and read the response body as a stream. Same endpoint shape as OpenAI, so any client library that targets OpenAI works by just changing the base URL.

Latency: what to actually expect

Numbers depend entirely on your hardware, so here's what I see on my machine (16GB RAM, integrated GPU, WSL2 on Windows) rather than invented benchmarks:

First call after startup is slow. The model loads into memory once. On qwen2.5-coder:7b that's a few seconds. After that it stays warm.
Autocomplete with 1.5b feels instant enough to leave on. That's the whole reason to use the small model for that role.
Chat with 7b starts streaming in roughly a second or two and reads at a comfortable pace. Long multi-file prompts are slower.
A real GPU changes everything. On a machine with a discrete NVIDIA card, the same models run several times faster and the bigger models become practical. On pure CPU, stick to 1.5b and 3b or you'll be waiting.

Tip: keep ollama serve running in the background all day. Don't start and stop it per request, you pay the load cost every time.

Performance tips

One small model for autocomplete, one bigger for chat. Don't make deepseek-coder-v2 do tab completion, the latency kills the flow.
Set temperature: 0 for code. You want deterministic, not creative.
Match the model to RAM. If Ollama is swapping to disk you'll feel it instantly. Drop a size.
Trim the context window if you don't need 32k tokens. Smaller context means less memory and faster responses. Set it in the model's Continue config or with a custom Modelfile.
Warm the model on login. A throwaway ollama run qwen2.5-coder:7b "" at startup preloads it so your first real prompt isn't the slow one.
Validate any structured output. Smaller models occasionally botch JSON. Parse with Zod and retry on failure.

When local is good enough (and when it isn't)

I use local models for most of the day and reach for Claude only when the problem is genuinely hard. Here's the honest split:

Task	Local (`7b` / `deepseek`)	Reach for cloud
Inline autocomplete	Great	Overkill
"Explain this function"	Great	No need
Boilerplate, tests, docstrings	Great	No need
Refactor within one file	Good	Marginal gain
Multi-file architecture reasoning	Hit or miss	Better
Subtle security review	Use as first pass	Better
Latest framework APIs (2026)	Stale	Better

The cloud still wins on hard reasoning and on knowledge of the newest APIs. But for the volume of small, repetitive coding questions that make up most of a day, local is not "good enough as a fallback," it's just good enough. The quality gap that existed in 2024 has mostly closed for everyday work.

What I run this on

When I built spectr-ai, my AI smart-contract auditor, I made the engine provider-agnostic for exactly this reason. The same analysis runs against Claude or against Ollama:

# Local, free, no API key, contract never leaves the machine
pnpm --filter @spectr-ai/engine dev -- \
  --model ollama:qwen2.5-coder:1.5b examples/vulnerable.sol

For smart-contract work, that "never leaves the machine" part isn't a nice-to-have. Audit clients don't want their unreleased code shipped to a third-party API. Local models make a privacy-preserving first pass possible, then I escalate the interesting findings to Claude.

Get qwen2.5-coder:7b running, wire up Continue, and use it for a week before you renew any Copilot subscription. The setup costs you twenty minutes and zero dollars a month after that.

Fable 5 Just Shipped: What Anthropic's Newest Model Means for Developers

Pavel Espitia — Wed, 15 Jul 2026 15:40:21 +0000

On June 9, 2026, Anthropic shipped Claude Fable 5, a model in a new tier that sits above Opus. I have been building on the Claude API for over a year, and this is the first release that made me stop and re-read my whole prompt stack before touching the model string. Here is what actually changed and what it means if you ship software.

The short version

Fable 5 is the public release of the Mythos line, the family that earlier in the year unsettled the security world with how well it found and exploited vulnerabilities. The version you and I get is the same underlying model with safeguards bolted on. Anthropic calls the safe one Fable and the unrestricted one Mythos, and only a small group of cyberdefenders gets Mythos.

The numbers, for context:

1M token context window, 128K max output, knowledge cutoff January 2026.
Priced at $10 per million input tokens and $50 per million output. That is double Opus 4.8 ($5 / $25).
State of the art on nearly every benchmark they tested: 95% SWE-bench Verified, 80% SWE-bench Pro.
Adaptive thinking is always on. There is no "disabled" mode.

That last point matters more than the benchmarks. You do not tune a thinking budget anymore. The model decides.

The pricing reframes the decision

At $10/$50, Fable 5 is not your default model. It is your "this task is hard and getting it wrong is expensive" model. Opus 4.8 at $5/$25 remains the workhorse for most application traffic, and Haiku 4.5 at $1/$5 still wins on classification and routing.

The way I think about it now is a three-tier ladder:

Haiku 4.5   →  routing, classification, cheap extraction
Opus 4.8    →  default for app traffic, agentic loops, coding
Fable 5     →  long-horizon agentic work where correctness pays for itself

The "longer and more complex the task, the larger Fable's lead" framing from the announcement is the actual buying signal. A one-shot summarization does not justify 2x the cost. A multi-hour autonomous refactor that would otherwise need human correction might.

The API surface is the same as Opus 4.7/4.8, with one catch

If your code already runs on Opus 4.7 or 4.8, moving to Fable 5 is mostly a model-string swap:

const response = await client.messages.create({
  model: "claude-fable-5",
  max_tokens: 64000,
  thinking: { type: "adaptive" },
  output_config: { effort: "high" },
  messages: [{ role: "user", content: "..." }],
});

The catch: on Fable 5, an explicit thinking: { type: "disabled" } returns a 400. On Opus 4.8 you can disable thinking. On Fable 5 you cannot, so just omit the param if you do not want to set it. Sampling params (temperature, top_p, top_k) are gone too, same as the rest of the 4.7+ family. If you still pass them, you get a 400.

And remember to stream anything with a high max_tokens. 128K output through a non-streaming request will hit SDK HTTP timeouts.

The safeguards are a real product decision, not marketing

Here is the part that I find genuinely interesting as someone who works in security. Fable 5 has hard safeguards in cybersecurity, biology, chemistry, and health. If you ask it something high-risk in those areas, the request does not just refuse. It falls back to Opus 4.8 to answer safely.

So if you run a security tool on Fable 5 and feed it something that trips a safeguard, you are silently getting Opus 4.8 output for that request. For my smart-contract auditing work, that means I cannot assume Fable-tier reasoning on every prompt. Some auditing prompts that look adversarial may quietly downgrade. I now log response.model on every call to know which model actually answered.

const used = response.model;
if (!used.startsWith("claude-fable-5")) {
  logger.warn({ requested: "claude-fable-5", served: used }, "model fell back");
}

What I am actually doing about it

I left my default on Opus 4.8. Most of what I ship does not need Fable.
I added Fable 5 as an opt-in tier for the hardest auditing passes in spectr-ai, gated behind a config flag, with cost logging.
I am watching the fallback behavior closely. A security model that silently downgrades on the exact prompts I care about is a sharp edge, not a footnote.

The headline is "most capable model ever released." The practical reality is more nuanced: a powerful, expensive tier with guardrails that change behavior on the prompts security people send most. Read the model field. Log it. Do not assume.

Adaptive Thinking Killed My Token Budget Code: Migrating Off budget_tokens

Pavel Espitia — Tue, 14 Jul 2026 15:36:52 +0000

I had a tidy little helper that computed a thinking budget based on input size. Something like "give the model 30% of the context as thinking room." It worked great on Opus 4.5. Then I tried to point it at Opus 4.8 and got a 400. The whole concept I had built around is gone in the current models. Here is what replaced it and how I migrated.

What broke

The old pattern looked like this:

// Opus 4.5 and earlier
const response = await client.messages.create({
  model: "claude-opus-4-5",
  max_tokens: 16000,
  thinking: { type: "enabled", budget_tokens: 8000 },
  messages,
});

On Opus 4.7, 4.8, and Fable 5, thinking: { type: "enabled", budget_tokens: N } returns a 400. The fixed token budget is dead. The replacement is adaptive thinking, where the model decides how much to think, plus an effort knob that controls overall token spend.

// Opus 4.8
const response = await client.messages.create({
  model: "claude-opus-4-8",
  max_tokens: 16000,
  thinking: { type: "adaptive" },
  output_config: { effort: "high" }, // low | medium | high | xhigh | max
  messages,
});

Why this is actually better (after I got over it)

My old budget code was a guess dressed up as a calculation. I had no real basis for "30% of context." I picked it because it felt reasonable and the outputs looked fine. Adaptive thinking moves that decision to the model, which sees the actual problem.

The mental model shift: budget_tokens controlled how much the model could think. effort controls how much it thinks and acts. They are not the same axis, so there is no clean 1:1 mapping. I stopped trying to translate "8000 tokens" into an effort level and instead picked based on the workload.

How I chose effort levels

After running my own evals, here is where I landed:

Workload	Effort	Notes
Classification, routing	`low`	Fast, scoped, not intelligence-sensitive
Most app traffic	`medium` to `high`	The balance point
Coding and agentic loops	`xhigh`	Best for these; it is the Claude Code default
Correctness-critical, latency-insensitive	`max`	When being wrong costs more than tokens

One thing that surprised me: higher effort up front often reduced total cost on agentic work because the model planned better and took fewer turns. I had assumed max always meant more tokens. On multi-step tasks, it sometimes meant fewer.

The migration checklist I actually used

Grep for budget_tokens across the codebase.
Replace thinking: { type: "enabled", budget_tokens: N } with thinking: { type: "adaptive" }.
Add output_config: { effort: "..." } and pick a level per call site, not one global value.
Delete the budget-calculation helper entirely. It was dead weight.
Strip any temperature / top_p / top_k params (those also 400 on 4.7+).
Run one test request per model and assert on response.model.

const r = await client.messages.create({
  model: "claude-opus-4-8",
  max_tokens: 64,
  thinking: { type: "adaptive" },
  messages: [{ role: "user", content: "ping" }],
});
console.assert(r.model.startsWith("claude-opus-4-8"), r.model);

One gotcha with thinking display

On Opus 4.7+ and Fable 5, thinking blocks still stream but their text is empty by default. If you were rendering reasoning to a UI, you now see a long pause instead of progress. Opt back in:

thinking: { type: "adaptive", display: "summarized" }

I missed this for an afternoon and thought streaming was broken. It was just the new default (omitted).

The lesson

I built abstraction on top of a parameter that the platform later removed. That is the risk of wrapping a vendor knob in your own logic before you understand whether the knob is fundamental or incidental. budget_tokens was incidental. The fundamental thing was "let the model think when it helps," and adaptive thinking expresses that directly. Less of my code, more of theirs, and the outputs got better. I will take that trade.

The $292M KelpDAO Bridge Hack: Why the Audit Wasn't the Problem

Pavel Espitia — Mon, 13 Jul 2026 16:39:57 +0000

On April 18, 2026, attackers drained about 116,500 rsETH, roughly $292 million, from a cross-chain bridge KelpDAO built on LayerZero. It is the largest DeFi hack of the year so far. I spend my days finding bugs in smart contracts, and the most uncomfortable thing about this hack is that finding bugs would not have stopped it. Here is the post-mortem and what it should change about how you think about security.

What actually happened

The bridge held the reserve of rsETH backing the token across more than 20 chains: Base, Arbitrum, Linea, Blast, Mantle, Scroll, and others. When the reserve drained, every wrapped version downstream was suddenly under-collateralized.

The root cause, per LayerZero's post-mortem, was not a Solidity bug. The attack began on March 6, six weeks earlier, when a developer was socially engineered. The contract code did what it was written to do. The keys that controlled it ended up in the wrong hands.

KelpDAO froze the system about 46 minutes after the drain. The attacker tried twice more to take another $100 million and failed because of that freeze. The 46 minutes is the one genuinely good part of this story.

The pattern is the story, not the protocol

KelpDAO is not an outlier in 2026. Two weeks earlier, Drift Protocol lost $285 million on Solana. That post-mortem also found no code exploit. It was a six-month social engineering operation against the people who held the admin keys. Drift's TVL fell from $550 million to under $300 million in an hour.

Put the two together and the theme is unmissable: the most expensive failures of 2026 are not bugs. They are humans being patiently targeted. Security firms attribute 76% of crypto hack losses this year to North Korea-linked actors, up from 64% in 2025. These are not smash-and-grab opportunists. They are state-backed teams running multi-month campaigns.

What an audit covers, and what it does not

I want to be precise here because "audits are useless" is the wrong takeaway. Audits are not useless. They are scoped.

An audit answers: does this code do what it claims, and does it have known classes of vulnerabilities? Reentrancy, access control gaps, integer issues, oracle manipulation, logic flaws. I find these for a living and they still matter. Plenty of money is still lost to plain bugs.

An audit does not answer: will the person holding the upgrade key get phished in March? Is the multisig actually multi-party, or are three of the five signers the same engineer on three laptops? Does the bridge operator have a key-rotation policy? Those are operational security questions, and the contract source code is silent on all of them.

The questions I now ask alongside the code review

When I look at a protocol now, I treat the contracts as one layer and the key custody as another. The code review is necessary. It is not sufficient. The questions that would have mattered for KelpDAO and Drift:

Who can move the reserve, and how many independent humans must agree?
Are admin keys in hardware wallets, in an HSM, or in a hot wallet a server can reach?
Is there a time delay on privileged actions, so a drain is visible before it completes?
Is there a circuit breaker, and who can pull it, and how fast? (KelpDAO's 46-minute freeze is the difference between $292M and $392M.)
What is the social engineering surface? How many people could a patient attacker target?

None of those are answerable from the .sol files. All of them mattered more than the .sol files.

Where this leaves AI-assisted security

I build AI tooling for contract analysis, so people ask whether AI helps here. Honestly, partially. AI is good at the layer audits already cover: reasoning about code, catching cross-function logic flaws, explaining what a privileged function can do. It does not phish-proof your team.

But there is a second-order effect worth naming. Reports this year note that AI is lowering the bar for exploit discovery, with automated reconnaissance increasingly targeting old and unverified contracts. The same capability that helps me audit helps attackers scan. The defensive move is not to avoid AI. It is to use it on your own attack surface before someone else does, and to remember that the attack surface includes your people.

The contracts were fine. The keys were not. Spend accordingly.

Hybrid Local + Cloud LLMs in 2026: When to Use Ollama and When to Pay for Fable

Pavel Espitia — Sun, 12 Jul 2026 15:06:12 +0000

I run a local model and I pay for cloud models, and the most common question I get is "which one should I use?" The honest answer is both, on the same task, at different stages. After a year of building tools that use Ollama and Claude together, here is the decision framework I actually apply, updated for the mid-2026 landscape where the top cloud tier now costs $50 per million output tokens.

The cost gap got wider, which makes the question sharper

In 2026 the cloud frontier spread out into a clear ladder:

Haiku 4.5: $1 / $5 per million tokens
Opus 4.8: $5 / $25
Fable 5: $10 / $50

Local is $0 per token after you own the hardware. A 2024-era laptop runs qwen2.5-coder:7b well enough for real work. The gap between "free and on my machine" and "$50 per million output tokens" is large enough that throwing every request at the frontier is a real waste of money.

So the framework is not "local or cloud." It is "what is the cheapest tier that gets this specific step right?"

The three questions I ask per step

1. Does this step leave my machine's privacy boundary?

If I am analyzing a client's unpublished contract or a private repo, that content does not go to a cloud API unless I have explicit permission. Local model, full stop. This is not a cost decision. It is a trust decision.

2. Is this step hard, or is it bulk?

Bulk work (chunking, first-pass extraction, classification, "is this file even relevant") goes local. Hard reasoning (the actual vulnerability analysis, the tricky cross-function logic, the final report) goes cloud. The 7B local model is genuinely fine at the bulk. It is not Fable 5 at the hard part, and pretending otherwise produces confident wrong answers.

3. What does being wrong cost?

A wrong classification I can re-run for free. A wrong security finding in a report I hand to a client costs my reputation. The cost-of-error maps directly onto the tier. Cheap-to-fix errors go to cheap models.

What this looks like in code

Here is the shape of a hybrid pipeline from one of my tools. Local model triages, cloud model does the heavy reasoning only on what survives triage:

import { Ollama } from "ollama";
import Anthropic from "@anthropic-ai/sdk";

const local = new Ollama();
const cloud = new Anthropic();

async function triage(file: string): Promise<boolean> {
  const r = await local.generate({
    model: "qwen2.5-coder:7b",
    prompt: `Does this contract have external calls, delegatecall, or asset transfers? Answer yes or no only.\n\n${file}`,
  });
  return r.response.toLowerCase().includes("yes");
}

async function deepAudit(file: string) {
  return cloud.messages.create({
    model: "claude-opus-4-8",
    max_tokens: 16000,
    thinking: { type: "adaptive" },
    output_config: { effort: "xhigh" },
    messages: [{ role: "user", content: `Audit this contract:\n\n${file}` }],
  });
}

async function pipeline(files: string[]) {
  const results = [];
  for (const f of files) {
    if (await triage(f)) {
      results.push(await deepAudit(f)); // pays for cloud only on interesting files
    }
  }
  return results;
}

If half my files are boilerplate that fails triage, I just halved my cloud bill, and the local triage cost me nothing.

When I reach for Fable 5 specifically

Almost never by default. Opus 4.8 is my cloud workhorse. I escalate to Fable 5 only when:

The task is long-horizon agentic work where one mistake cascades.
I have already tried Opus 4.8 and it missed something I know matters.
The correctness genuinely justifies double the cost.

For a security report, the math can work, because a missed finding is far more expensive than the token difference. For "summarize this PR," it never works.

The anti-pattern: frontier for everything

The mistake I see most is reaching for the most capable model on every call because it "can't hurt." It can hurt. It hurts your latency (more thinking) and your bill (more dollars), and for bulk steps it gives you no measurable quality gain. The local 7B model answering "is this file relevant" in 200ms for free is the right tool. Save the $50-per-million tier for the moments that are actually hard.

Local for privacy and bulk. Cloud for reasoning. Frontier only when being wrong is expensive. That is the whole framework.

Writing Evals for an LLM Security Tool: How I Know It Didn't Get Worse

Pavel Espitia — Sat, 11 Jul 2026 15:04:37 +0000

Every time a new model ships, I face the same question for spectr-ai: does my contract auditor get better or worse on the new model? "Vibes" is not an answer when the tool tells people whether their code is safe. So I built evals. Here is how I test an LLM that produces fuzzy output, and why a handful of labeled examples beats a gut feeling every time.

The problem with testing LLM output

Unit tests assume deterministic output. LLM output is not deterministic, and even when it is correct it phrases things differently each run. You cannot assert output === "reentrancy on line 12". The model might say "the withdraw function is vulnerable to reentrancy" or "external call before state update in withdraw()."

So I do not test the text. I test the finding. Did the model identify the vulnerability class on the right function? That is a yes/no I can check, and it survives rephrasing.

The eval set

I built a directory of contracts where I know the ground truth, because I planted it or verified it by hand:

evals/
  cases/
    reentrancy-classic.sol        → expect: reentrancy in withdraw
    access-control-missing.sol    → expect: missing onlyOwner on setFee
    safe-checks-effects.sol       → expect: NO findings (clean contract)
    integer-edge.sol              → expect: division by zero in average
  expected.json

expected.json is the labeled ground truth:

{
  "reentrancy-classic.sol": [{ "class": "reentrancy", "function": "withdraw" }],
  "access-control-missing.sol": [{ "class": "access-control", "function": "setFee" }],
  "safe-checks-effects.sol": [],
  "integer-edge.sol": [{ "class": "division-by-zero", "function": "average" }]
}

The clean contract is the most important case. A tool that flags everything has perfect recall and is useless. I need to know it stays quiet when the code is safe.

Scoring with precision and recall, not accuracy

I score each run on two numbers:

Recall: of the real vulnerabilities, how many did the model find? Missing a bug is the dangerous failure for a security tool.
Precision: of the things the model flagged, how many were real? Crying wolf trains users to ignore the tool.

function score(found: Finding[], expected: Finding[]) {
  const match = (a: Finding, b: Finding) =>
    a.class === b.class && a.function === b.function;

  const truePositives = expected.filter((e) => found.some((f) => match(f, e)));
  const falsePositives = found.filter((f) => !expected.some((e) => match(e, f)));

  const recall = expected.length === 0 ? 1 : truePositives.length / expected.length;
  const precision = found.length === 0 ? 1 : truePositives.length / found.length;

  return { recall, precision };
}

I aggregate across all cases and report the mean. One number per model, comparable across runs.

The runner

import fs from "node:fs/promises";

async function runEvals(model: string) {
  const expected = JSON.parse(await fs.readFile("evals/expected.json", "utf8"));
  const scores = [];

  for (const [file, truth] of Object.entries(expected)) {
    const source = await fs.readFile(`evals/cases/${file}`, "utf8");
    const found = await analyze(source, model); // your auditor call
    scores.push(score(found, truth as Finding[]));
  }

  const recall = mean(scores.map((s) => s.recall));
  const precision = mean(scores.map((s) => s.precision));
  console.log(`${model}: recall=${recall.toFixed(2)} precision=${precision.toFixed(2)}`);
}

Now when Opus 4.8 or Fable 5 lands, I run the same suite against the new model string and compare. No vibes. Two numbers.

What the evals actually caught

The eval set has earned its keep more than once. When I tested a newer model, recall dropped on a case I expected it to nail. The model had found the bug but declined to report it because my prompt said "only report high-confidence issues." The newer model followed that instruction more literally than the old one did. The fix was a prompt change, not a model rollback, and I only knew to look because the number moved.

That is the real value. The eval does not just tell me a model is worse. It tells me where, so I can find out whether the cause is the model or my own prompt.

Start smaller than you think

You do not need a thousand cases. I started with eight and it was already enough to catch a regression. Label what you have, score precision and recall, run it on every model change. The discipline of having ground truth at all is most of the win. The size of the set is a refinement you add later, when eight cases stop surprising you.