Forem

How to Audit Your AI Agent Skills for Credential Exposure and Malicious Instructions

Armor1 — Fri, 15 May 2026 00:40:52 +0000

Two independent security research groups published this week with findings that land on the same problem from different angles: AI agent skill files are a serious and underaudited supply chain surface, and the attack techniques targeting them are already in active use.

The Scale Finding

Capsule Security's analysis covered more than 200,000 agent skill files and 160,000 code files. The result that stands out: 2,909 of 19,618 distinct skill files carry hardcoded credentials alongside direct database write access. Roughly 15% of distinct skill files in active use. No additional exploit is required. Install the skill, the agent reads the skill configuration, the credentials are there.

The same analysis found that AI workloads present a supply chain attack surface six times larger than traditional software. It also observed that malicious skills continue to persist and propagate after the campaigns that distributed them are officially terminated.

The Active Campaign

A separate disclosure published the same week documents a March 2026 campaign targeting a popular AI coding agent framework. Attackers published deceptive community skills that appeared legitimate at a glance. The payload delivery mechanism was not a traditional malware dropper. It was the installation instruction inside the skill file itself.

The skill's installation instructions directed the agent to perform operations that installed Remcos RAT and GhostLoader. The agent followed those instructions because that is exactly what installation instructions are for. No user interaction beyond installing the skill was required.

This is a distinct campaign from the January 2026 supply chain attack covered in prior security reporting. Different delivery mechanism. Different payloads. The point of connection: both used the skill ecosystem as the distribution channel.

What the Attack Surface Looks Like

An AI agent skill typically consists of a few components:

A metadata file (often named SKILL.md or similar) containing the skill's name, description, and installation instructions
Configuration specifying what tools, permissions, and external resources the skill uses
Optionally, code files the skill executes

The attack surface is broader than the code. The metadata file, particularly the installation instructions, is executed by the agent as part of skill setup. An agent that reads and follows installation instructions is following arbitrary instructions from whoever wrote that file. If the file was tampered with or written by a threat actor, those instructions are arbitrary commands.

The credential exposure problem is a separate issue: skill files that embed API keys, database connection strings, or other credentials expose those values to every developer who installs the skill, to the agent that reads the configuration, and to anything else in the agent's context window.

How to Audit Your Skills

Step 1: Inventory what you have. List every skill file currently active in your agent environment. For community-sourced skills, note the source and whether the version has changed since you installed it.

Step 2: Check skill metadata for credentials. Search skill configuration files for patterns that suggest embedded credentials: connection strings, API key patterns, private key markers. A regex scan for common credential patterns across skill metadata is a reasonable first pass.

Step 3: Review installation instructions for anomalies. Read the installation instruction sections of skill files, particularly community-sourced ones. Installation instructions that invoke shell commands, download additional packages from unverified sources, or reference external URLs outside the skill's stated purpose are worth investigating.

Step 4: Check skill versions and provenance. Skills that have changed since their last verified install are a flag. Skills from sources without a clear maintainer are a flag. If a skill you installed months ago now behaves differently, that is worth examining.

Step 5: Treat skill installs as supply chain events. The same controls that apply to adding a dependency to package.json should apply to adding a skill to an agent environment. Review what it does, check the source, pin to a specific version.

How Armor1 Approaches This

Armor1's skill security scanner evaluates every skill file before execution. The scanner checks for hardcoded credentials and credential misuse patterns, malicious installation instructions, data exfiltration patterns embedded in skill configuration, and supply chain risks such as references to unverified external packages or remote code in skill definitions. The scanner runs two passes: an initial analysis and a verification pass to reduce false positives.

The credential exposure Capsule Security found at scale and the installation instruction attack vector documented in the March 2026 campaign both fall inside the categories the scanner evaluates.

Check the risk of any MCP server in your environment with Armor1's free public catalog.

To cover every agentic app, MCP, tool, skill, and plugin across your stack, sign up free Here.

How to Send Auth Codes via WhatsApp in Your App With Kinde

Shola Jegede — Fri, 15 May 2026 00:38:16 +0000

Your users are in San Francisco, Jakarta, São Paulo, and Sydney. They have WhatsApp open all day. They check it before they check their SMS inbox. When your app sends an OTP to their phone number, it lands in a carrier SMS thread they barely look at. When it lands in WhatsApp, they see it instantly.

In this article, you will learn:

Why WhatsApp OTP delivers better completion rates than SMS in high-penetration markets
How Kinde delivers phone OTPs via WhatsApp when configured, with automatic SMS fallback
What you need before you start: Twilio account, WhatsApp Sender, Kinde Pro
How to configure Twilio Verify with a WhatsApp Sender
How to connect your Twilio account to Kinde
How to enable phone authentication in your Next.js app
How to enable WhatsApp as the delivery channel in Kinde
How to configure SMS as the automatic fallback
How to test the full flow before going live
What to watch for in Africa, South Asia, and Southeast Asia specifically

Let's dive in!

Why WhatsApp OTP Is the Right Choice for Your Market

If your users are in Europe or North America, SMS OTP is a reasonable default. Delivery is reliable, carrier infrastructure is solid, and most users check texts promptly.

If your users are in Nigeria, Kenya, Indonesia, Brazil, India, or the Philippines, the calculation is different. WhatsApp penetration in these markets is near-universal. Users across sub-Saharan Africa and Southeast Asia treat WhatsApp as their primary communication channel. SMS sits behind it, sometimes significantly behind.

The data on this is clear. Twilio has documented that in heavy WhatsApp countries, 20 to 40 percent of users pick the WhatsApp channel when given the option for OTP delivery. More importantly, WhatsApp OTPs arrive over Wi-Fi connections. A user whose cellular data signal is weak but who is on Wi-Fi still receives the WhatsApp message instantly. SMS requires telephony connectivity. In markets where cellular data coverage is more reliable than SMS delivery, WhatsApp is not just more convenient. It is more reliable.

There is also a cost argument. WhatsApp authentication messages cost 50 to 99 percent less than SMS in most markets globally. In developing markets where SMS costs are highest, the savings are largest. At any meaningful scale, the economics strongly favor WhatsApp.

The correct production setup is WhatsApp first with automatic SMS fallback for the minority of users who do not have WhatsApp. That is exactly what Kinde gives you.

How Kinde Handles WhatsApp OTP

Kinde supports phone number as both a primary authentication method and a secondary MFA factor. When phone authentication is configured, Kinde uses Twilio to deliver OTP codes. When you configure a WhatsApp Sender in your Twilio account and connect it to Kinde, Kinde automatically prefers WhatsApp for delivery and falls back to SMS when WhatsApp is unavailable.

This is Twilio's Verify WhatsApp feature working through Kinde's phone authentication layer. You do not write any message-routing logic. Kinde and Twilio handle it. When a user enters their phone number on your sign-in screen, the OTP arrives in their WhatsApp. If they do not have WhatsApp or the delivery fails, Twilio's Verify API automatically retries via SMS.

There are a few important constraints to know before you start:

Kinde Pro is required for production phone authentication. Kinde gives you 10 free SMS test sends per month on any plan to experiment with the feature, but production phone authentication (including WhatsApp) requires upgrading to the Pro plan or above.

The OTP message format is not editable. Kinde uses a standardized SMS/WhatsApp template that complies with OTP best practices. The message arrives as: 123456 is your verification code. followed by For your security, do not share this code. No app name, no URL, no hash. The sender name shown at the top of the WhatsApp chat comes from your registered Twilio business display name, not the message body. You cannot customize the message text or format.

A Twilio business account is required. You cannot use a personal or trial Twilio account for production A2P (Application-to-Person) messaging. You need a Twilio business account with a configured phone number or Messaging Service.

10DLC registration may be required in the US. If your users are in the United States, Twilio requires 10DLC registration for SMS. Check Twilio's guidelines and A2P messaging requirements for your target countries before setting up.

What You Need Before You Start

Before touching the Kinde dashboard, have the following ready:

A Twilio business account with your Account SID and Auth Token from the Twilio Console.

A Twilio phone number or Messaging Service SID. Twilio gives you two options for identifying the sender: a specific phone number or a Messaging Service (a pool of numbers Twilio manages for deliverability). The Messaging Service is recommended for production because Twilio handles number rotation and deliverability automatically.

A WhatsApp Sender configured in Twilio. This is a WhatsApp Business Account (WABA) phone number registered with Meta and approved for authentication message templates. Twilio's Verify WhatsApp documentation walks through this process. You need Meta Business verification and an approved authentication template before WhatsApp delivery works.

A Kinde account on the Pro plan or above.

A Next.js app with the Kinde SDK installed. If you are starting fresh, the Kinde Next.js quickstart at docs.kinde.com gets you to a working auth setup in under ten minutes.

Note: You can complete the Kinde configuration and test with the 10 free SMS sends before completing the WhatsApp Sender setup in Twilio. This lets you verify the Kinde connection is working before adding WhatsApp to the mix.

Step #1: Configure Twilio for Phone and WhatsApp Delivery

Get your credentials. From the Console Dashboard, copy your Account SID and Auth Token. Keep the Auth Token private.

Set up a Messaging Service (recommended) or phone number. If using a Messaging Service, navigate to Messaging → Services → Create Messaging Service. Give it a name, add your sender number to it, and copy the Messaging Service SID.

If using a specific Twilio phone number instead, navigate to Phone Numbers → Manage → Active numbers and copy the phone number in E.164 format (e.g. +12025551234).

Configure the WhatsApp Sender for Verify. This is the step that enables WhatsApp delivery. Navigate to Messaging → Senders → WhatsApp senders in the Twilio Console.

Select Add Sender. You will be prompted to connect a WhatsApp Business Account. This requires:

A Meta Business Account (verified)
A phone number registered as a WhatsApp Business number
An approved WhatsApp authentication message template

Twilio auto-creates the authentication template in supported languages once you complete the WhatsApp Sender setup. The template uses the Copy Code format, which displays the OTP with a button users tap to copy it to their clipboard.

Note: WhatsApp Sender approval from Meta typically takes one to three business days. Plan your timeline accordingly. You can continue with the Kinde setup and test using SMS while waiting for WhatsApp approval.

Step #2: Connect Twilio to Kinde

With Twilio credentials ready, connect them to Kinde.

In your Kinde dashboard, navigate to Settings → Environment → Phone providers.

Enter your Twilio credentials:

Account SID: from your Twilio Console dashboard
Auth Token: from your Twilio Console dashboard
Messaging service SID or Twilio phone number: enter whichever you set up in Step #1

If you want to use a fallback in case the primary Twilio service is interrupted, enable the fallback service option and configure a secondary provider.

Select Save.

Terrific! Kinde can now route phone OTP delivery through Twilio. The WhatsApp channel activates automatically once your WhatsApp Sender is approved in Twilio.

Step #3: Enable Phone Authentication in Kinde

With Twilio connected, turn on phone as an authentication method for your application.

Navigate to Settings → Environment → Authentication. In the Passwordless section, find the Phone tile and select Configure.

In the configuration window, toggle phone authentication on for the applications you want it active for. If you have multiple applications in your Kinde environment, you can enable it selectively per application.

Select Save.

Your sign-in screen now includes a phone number input option alongside the existing email input. Users can choose to sign in with their phone number and receive an OTP instead of entering a password or email code.

Step #4: Enable WhatsApp as the Delivery Channel

With phone authentication active and Twilio connected, the final step is confirming that WhatsApp is set as the preferred delivery channel.

In your Kinde dashboard, navigate to Settings → Environment → Phone providers. In your Twilio configuration, you will see the WhatsApp delivery option.

Enable the WhatsApp delivery option. Once enabled:

Kinde sends the OTP via WhatsApp when the user's phone number is registered with WhatsApp
If WhatsApp delivery fails (user does not have WhatsApp, or the delivery fails for any reason), Twilio's Verify API automatically falls back to SMS
No code changes are needed in your application

The fallback happens silently. Your users do not see an error or need to request a retry. Twilio detects the WhatsApp delivery failure and retries via SMS automatically.

Step #5: Configure Phone Auth as MFA (Optional)

If you want to use WhatsApp OTP as a second factor rather than (or in addition to) a primary authentication method, configure it at the MFA level.

Navigate to Settings → Environment → Multi-factor auth.

In the Additional authentication methods section, toggle on SMS. Per the Kinde docs, the SMS MFA option delivers via WhatsApp when configured, with automatic fallback to SMS. The WhatsApp preference follows from your Twilio configuration in Step #4 automatically.

Set MFA to Yes (mandatory) or Optional depending on your product's security requirements:

Yes: every user is required to set up MFA on first sign-in. For products targeting enterprise customers or handling sensitive data, this is the right default.
Optional: users are prompted to set up MFA but can skip it. They can enable it later from their profile settings.

Note: if your primary authentication method is already phone OTP (email OTP), do not set phone SMS as the secondary MFA factor. Kinde recommends against using the same channel for both primary and secondary factors. If your primary auth is email OTP, use phone SMS or authenticator app for MFA. If your primary auth is phone OTP, use email or authenticator app for MFA.

Select Save.

Step #6: Wire Phone Authentication Into Your Next.js App

Kinde's hosted sign-in screen already includes the phone number input once you enable phone authentication. Your Next.js app does not need code changes to show the phone sign-in option. It appears automatically on the Kinde-hosted auth pages.

However, if you want to pre-fill the phone number for users coming from a known context (for example, users you have invited via phone number), use the login_hint parameter to reduce friction:

// app/api/auth/[kindeAuth]/route.ts
// Standard Kinde auth setup — no changes needed for basic WhatsApp OTP

// For login with pre-filled phone number hint:
// Pass login_hint in the authorization URL when you know the user's phone number
// This skips the phone number entry step

import { handleAuth } from "@kinde-oss/kinde-auth-nextjs/server";
export const GET = handleAuth();

For inviting users with a known phone number and pre-filling the sign-in form:

// components/PhoneInviteButton.tsx
// Pre-fills the phone number on the Kinde sign-in screen
// Useful when you know the user's phone number before they authenticate

import { LoginLink } from "@kinde-oss/kinde-auth-nextjs/components";

interface PhoneInviteButtonProps {
  phoneNumber: string; // E.164 format e.g. "+2348012345678"
}

export function PhoneInviteButton({ phoneNumber }: PhoneInviteButtonProps) {
  return (
    <LoginLink
      authUrlParams={{
        // login_hint pre-fills the identity field on the Kinde sign-in screen
        // The user sees their phone number already entered and just confirms it
        login_hint: phoneNumber,
        // connection_id routes directly to phone authentication
        // Skips the method selection screen
        connection_id: "phone",
      }}
    >
      Sign in with phone
    </LoginLink>
  );
}

For protecting API routes on the server, the existing getKindeServerSession approach works identically regardless of whether the user authenticated via email or phone:

// app/api/example/route.ts
// Phone-authenticated users produce the same session as email-authenticated users
// No changes needed to protected route logic

import { getKindeServerSession } from "@kinde-oss/kinde-auth-nextjs/server";
import { NextResponse } from "next/server";

export async function GET() {
  const { isAuthenticated, getUser } = getKindeServerSession();

  if (!(await isAuthenticated())) {
    return NextResponse.json({ error: "Unauthorized" }, { status: 401 });
  }

  const user = await getUser();

  // user.phone is populated when the user authenticated via phone number
  // user.email is populated when the user authenticated via email
  // Both may be present if the user has linked both identities

  return NextResponse.json({
    userId: user?.id,
    phone: user?.phone,
    email: user?.email,
  });
}

Amazing!

Step #7: Test the Full WhatsApp OTP Flow

Before going live, test three scenarios in your Kinde non-production environment.

Test 1: WhatsApp delivery to a WhatsApp-registered number

Enter a phone number that is registered with WhatsApp. Kinde should route the OTP through Twilio Verify to WhatsApp. The code arrives in your WhatsApp with your Twilio-registered business name as the sender.

Note: Kinde provides 10 free SMS sends per month for testing. These 10 free sends apply to SMS delivery. WhatsApp delivery tests use your Twilio Verify credits.

Test 2: Automatic SMS fallback

To test the fallback, enter a valid phone number that is not registered with WhatsApp, or temporarily disable WhatsApp in your Twilio account. Twilio Verify should detect the WhatsApp delivery failure and automatically send via SMS. The OTP code is the same in both channels.

Test 3: MFA flow (if configured)

If you have set phone SMS as an MFA factor, sign in with email OTP first. On the second factor screen, Kinde prompts for the phone-based code. Enter your phone number if not already registered, and confirm the WhatsApp delivery.

Country-Specific Notes for African and Southeast Asian Markets

Nigeria and Ghana: WhatsApp penetration is extremely high, above 90 percent of smartphone users. SMS delivery is inconsistent in some areas. WhatsApp OTP is strongly recommended as the primary channel. Twilio's A2P messaging in Nigeria requires pre-registered sender IDs. Check Twilio's Nigeria SMS guidelines before launch.

Kenya, Tanzania, Uganda: WhatsApp is widely used but M-Pesa and other mobile money services mean users are accustomed to SMS-based verification from financial services. WhatsApp OTP delivers a better experience but SMS fallback is particularly important in rural areas.

Indonesia, Philippines, Vietnam: Near-universal WhatsApp (and Line, in some markets) penetration. International SMS is expensive from most providers. WhatsApp OTP delivers significant cost savings at scale here.

India: WhatsApp has over 500 million users. However, Meta has implemented messaging limits for WhatsApp Business in India. Review the current Meta Business Platform limits for Indian traffic before projecting volume. Twilio's documentation covers the current limits.

Brazil: One of the highest WhatsApp penetration rates globally. WhatsApp OTP is effectively the standard for authentication flows built for Brazilian users.

For all markets: always test with real numbers in the target country before launch. Carrier behavior, number formatting requirements (always use E.164 format), and delivery timing vary by region.

Troubleshooting Common Issues

OTP not received via WhatsApp

Check that your WhatsApp Sender is approved in Twilio and that the authentication template is active. An unapproved or suspended sender silently fails delivery. Check Twilio's delivery logs for error codes. Error code 63024 from Twilio means the phone number is not associated with a WhatsApp account and the fallback to SMS should have triggered.

OTP received via SMS instead of WhatsApp

This is the expected behavior when WhatsApp delivery is not available. If you expected WhatsApp delivery but got SMS, check: Is the destination phone number registered with WhatsApp? Is the WhatsApp Sender active and approved in Twilio? Has the user blocked your business sender in WhatsApp?

"You need to enter your Twilio account details" message in Kinde

This appears when Kinde's phone authentication is configured but Twilio credentials have not been saved, or the credentials are invalid. Navigate to Settings → Environment → Phone providers and re-enter your Twilio Account SID and Auth Token.

Users in the United States not receiving SMS

US carriers require 10DLC registration for A2P SMS. If your Twilio account is not 10DLC registered for US traffic, messages to US numbers will fail. Complete 10DLC registration in Twilio before enabling phone authentication for US users.

Phone number formatting errors

Kinde and Twilio both require phone numbers in E.164 format (e.g. +2348012345678 for a Nigerian number). If users enter numbers without country codes, the OTP send will fail. Kinde's hosted sign-in screen includes a country code dropdown to help users format numbers correctly. If you are pre-filling numbers via login_hint, always format them in E.164.

Putting It All Together

Here is a summary of the full setup:

Step	What you do	Where
Twilio business account	Get Account SID, Auth Token, Messaging Service	Twilio Console
WhatsApp Sender	Register WhatsApp Business number with Meta via Twilio	Twilio Console > Verify > WhatsApp Senders
Connect Twilio to Kinde	Enter Twilio credentials	Kinde > Settings > Phone providers
Enable phone auth	Toggle on Phone in Passwordless section	Kinde > Settings > Authentication
Enable WhatsApp delivery	Configure WhatsApp as preferred channel	Kinde > Settings > Phone providers
Configure MFA (optional)	Enable SMS as second factor	Kinde > Settings > Multi-factor auth
Test	3-scenario flow test before going live	Non-production environment

Conclusion

In this article, you connected Twilio Verify to Kinde, registered a WhatsApp Business Sender, enabled phone authentication, and configured WhatsApp as the preferred OTP delivery channel with automatic SMS fallback. Users in markets where WhatsApp dominates now receive their authentication codes in the app they check first, over Wi-Fi when needed, at a fraction of the SMS cost.

The setup is the same for phone as primary auth and as MFA. Once your Twilio credentials are in Kinde and your WhatsApp Sender is approved, the routing is handled entirely by Twilio Verify. Your application code does not change. Kinde issues the same JWT regardless of whether the OTP arrived via WhatsApp or SMS.

Kinde is free for up to 10,500 monthly active users. Phone authentication and WhatsApp OTP require the Pro plan. Create your account at kinde.com and meet your users where they already are.

AI Desk Meter: Building a Local-First Runtime Dashboard Toward MuseMeter

Gary Doman/TizWildin — Fri, 15 May 2026 00:36:36 +0000

AI Desk Meter: Building a Local-First Runtime Dashboard Toward MuseMeter

I’m building AI Desk Meter, an open-source local-first runtime dashboard for AI status, runtime state, and companion-style desktop visibility.

The project is also the open-source foundation leading toward MuseMeter, a future second-brain / Neural Synth / AI buddy product.

The core idea is simple:

local runtime state → JSON source of truth → dashboard sync → native/app/hardware display

AI Desk Meter is meant to stay lightweight, inspectable, and useful without requiring a server.

What AI Desk Meter is

AI Desk Meter is a local-first dashboard project that displays runtime state from a JSON-backed source of truth.

It is designed as a visible companion surface for an AI/runtime system, showing state in a way that can eventually connect to:

local AI agents
runtime monitors
desktop companion apps
small hardware displays
Raspberry Pi / ESP32 style companion builds
native app shells
future MuseMeter hardware/software releases

The current project is focused on making the foundation clean, open, and usable.

Why I’m building it

Most AI interfaces are either chat boxes, dashboards, or cloud services.

AI Desk Meter is aimed at a different interaction pattern: a small visible runtime companion that can sit on your desktop, show what the system is doing, and eventually become a bridge between AI status, local memory, agent state, and companion hardware.

The long-term direction is MuseMeter:

second-brain style companion
local-first AI buddy
Neural Synth-inspired visual interface
desktop/runtime visibility
optional companion hardware
open-source foundation before the commercial 3.0 product line

Local-first design

The project is intentionally built around a no-server default.

That means:

no required cloud backend
dashboard state comes from local files/runtime output
JSON can act as the source of truth
the system can be inspected directly
future native/hardware layers can read the same state model

This keeps the project simple, portable, and easier to reason about.

Current release direction

The current AI Desk Meter direction includes:

runtime dashboard sync
JSON-backed state updates
local-first/no-server architecture
support/funding links
open-source project foundation
future native app holster direction
future companion hardware direction
roadmap toward MuseMeter 3.0

The small pixel companion character and “Musing...” state are intentional.

Right now, Musing... represents an active response/action/loading state. Later versions may split this into more specific runtime states such as:

responding
loading
thinking
idle
action running
waiting for input
agent task active

Why JSON as source of truth

The dashboard is built around a JSON state model because it gives the project a clean bridge between layers.

A JSON runtime state can be read by:

the web dashboard
a native app wrapper
Python CLI tools
hardware companion displays
future agent runtimes
test scripts
docs and demos

This makes the dashboard more than a static UI. It becomes a visible surface for a local runtime.

Where MuseMeter fits

AI Desk Meter is the open-source foundation.

MuseMeter is the larger product direction.

The plan is:

AI Desk Meter open-source foundation
→ runtime dashboard stability
→ native app shell / holster
→ real Muse/agent connection
→ companion hardware support
→ MuseMeter 3.0 commercial package

Everything leading up to the commercial 3.0 direction is meant to preserve the open-source foundation while proving the runtime/dashboard concept in public.

Repo

https://github.com/GareBear99/ai-desk-meter

What I’m looking for

I’m looking for feedback from:

AI developers
local-first app builders
Python developers
web dashboard developers
hardware/display builders
Raspberry Pi users
ESP32/Arduino experimenters
people interested in AI companion interfaces
open-source maintainers

Useful feedback includes:

dashboard layout issues
JSON runtime state suggestions
native app packaging ideas
hardware display ideas
local-first architecture feedback
UI/UX suggestions
install/run issues
roadmap feedback

Long-term vision

The long-term goal is a small, useful, local-first AI companion surface that can grow from a web dashboard into a native app and eventually into hardware.

AI Desk Meter is the foundation.

MuseMeter is the product horizon.

I’m building it in public so the runtime, dashboard, and companion architecture can be tested, improved, and documented as it grows.

How to fix native module errors when switching JavaScript runtimes

Alan West — Fri, 15 May 2026 00:31:38 +0000

The error that ruins your Monday

You spent the weekend migrating your build pipeline to a faster JavaScript runtime. Tests passed locally. CI was green. You shipped it. Then Monday morning, your monitoring lights up: Error: The module 'XXX.node' was compiled against a different Node.js version using NODE_MODULE_VERSION 108. This version requires NODE_MODULE_VERSION 115.

Or worse — silent failures. Functions that worked yesterday now return undefined. A crypto library that always hashed correctly now segfaults on production-shaped inputs.

I ran into this last month migrating a media-processing service off an older Node version. The lesson cost me a Sunday and most of my patience.

Why native modules are so fragile

When you require('sharp') or require('better-sqlite3'), you're not just pulling in JavaScript. You're loading a compiled .node binary that talks to the engine through one of three ABIs:

Direct V8 bindings — raw C++ calls into V8 internals. Fast, brittle, version-locked.
NAN (Native Abstractions for Node) — a header-only abstraction layer over V8 changes.
Node-API (N-API) — a stable ABI that promises forward compatibility across Node major versions.

The trouble: every JavaScript runtime advertises "Node.js compatibility," but compatibility means different things at different layers. Pure JavaScript code? Almost always fine. CommonJS resolution? Mostly fine. Native modules? It depends entirely on how the module was built — and whether the target runtime ships a working N-API implementation.

Root cause: ABI mismatch

If a module ships prebuilt binaries (most popular ones do), the binary was compiled against a specific Node.js version. When you load it under a different runtime — or even a different Node major — the symbol table doesn't line up. The dynamic linker sees napi_create_string_utf8 and tries to resolve it against the host process. If the host doesn't export that symbol, or exports a different version of it, you get either a load-time crash or undefined behavior at runtime.

Forget "JavaScript is portable." Native modules are C/C++, and C doesn't forgive.

Step-by-step: how to actually fix it

Step 1: Find every native module you depend on

Don't guess. Run this in your project root.

# Find every compiled .node binary in your installed dependencies
find node_modules -name "*.node" -type f 2>/dev/null

The output is your liability list. Anything with a .node extension is a compiled binary tied to a specific ABI.

Step 2: Check each module's compatibility surface

For each native module, look at its package.json for these fields:

{
  "binary": {
    "napi_versions": [6, 7, 8]
  },
  "engines": {
    "node": ">=16.0.0"
  }
}

Modules that declare napi_versions are using Node-API and have the best chance of working across runtimes. Modules without that declaration are gambling — they likely use NAN or direct V8 bindings, and your migration is going to hurt. You can read the spec at the Node-API documentation to understand what each version level guarantees.

Step 3: Force a rebuild against your target runtime

Prebuilt binaries are the enemy here. Force the source compilation path:

# Skip the prebuilt download and compile from source
npm rebuild --build-from-source

# For a clean slate with yarn
rm -rf node_modules
yarn install --ignore-scripts=false --build-from-source

I learned the hard way: some packages have prebuild-install baked into their install script and will silently grab a binary even when you ask for source builds. Watch the install output. If you see prebuild-install downloading something, kill it and read the package's install script before continuing.

Step 4: Diagnose runtime-specific crashes

If the module loads but crashes at runtime, you need a stack trace from the native side. On Linux:

# Run your process under gdb to catch the native crash
gdb --args node your-broken-script.js

# Inside gdb:
#   (gdb) run
#   (gdb) bt   # after the crash, prints native stack trace

On macOS, swap gdb for lldb. The trace usually points at a single symbol — say, napi_get_value_string_utf8 — and that tells you exactly which N-API call is misbehaving. From there it's usually a version mismatch or a missing symbol the host runtime hasn't implemented yet.

Step 5: Pin and verify

Once you find a working combination, lock it in. Add an explicit runtime version to your CI config and ship a smoke test that loads every native module on startup:

// scripts/verify-native.js — run as a postinstall sanity check
const nativeModules = [
  'sharp',
  'better-sqlite3',
  'bcrypt'
];

// Walk the list and try to require each one.
// Exit non-zero on failure so CI catches the regression before deploy.
for (const name of nativeModules) {
  try {
    require(name);
    console.log(`OK: ${name}`);
  } catch (err) {
    console.error(`FAIL: ${name} -> ${err.message}`);
    process.exit(1);
  }
}

Wire that into your CI matrix so every runtime version gets tested before it touches production.

Prevention: build the safety net before you need it

A few habits that have saved me repeatedly:

Audit native deps every release cycle. A quick find node_modules -name '*.node' keeps the list visible. New transitive dependencies sneak in through innocent-looking packages.
Prefer pure-JS alternatives where the perf hit is acceptable. bcryptjs instead of bcrypt, sql.js instead of better-sqlite3 for non-hot-path code. You trade speed for portability — sometimes that's the right trade.
Pin your runtime version in CI and Docker. Don't let node:latest drift in your Dockerfile. I've watched entire teams debug "the same code stopped working" only to discover the base image updated underneath them.
Read the changelog before any major runtime upgrade. Look specifically for ABI changes or Node-API version bumps. The Node.js previous releases page flags ABI-breaking versions.

The honest tradeoff

Alternative JavaScript runtimes are genuinely faster for a lot of workloads. I'm not arguing against trying them. But the "drop-in replacement" promise has an asterisk the size of a billboard, and that asterisk is named native modules.

If your dependency tree is pure JavaScript, migration is mostly painless. If you have a handful of Node-API modules with declared compatibility, you're fine after a rebuild. If you're three levels deep into a NAN-based image-processing library that nobody has maintained since 2019 — that's the conversation worth having before the migration, not after.

Test your native modules first. Everything else is downstream of that.

Service Worker Caching Strategies: Cache-First, Network-First, and SWR

Ashish Kumar — Fri, 15 May 2026 00:30:00 +0000

Related: Network Optimization for SPAs and React Apps covers the broader network optimization picture including HTTP caching and API request optimization.

A service worker is a JavaScript file that runs in a background thread, separate from your main application. It intercepts every network request your page makes and can respond from cache, modify the request, or let it pass through to the network unchanged. For a returning visitor, a well-configured service worker means many requests never touch the network at all. The page loads from cache at local disk speed.

What this covers: What service workers can and cannot do, the three core caching strategies (cache-first, network-first, stale-while-revalidate), when each strategy is correct for which resource type, and how Workbox makes implementing these strategies practical without writing the interception logic by hand.

What a service worker actually does

A service worker is registered by your application JavaScript and installed by the browser. Once installed, it intercepts all network requests made from pages on its origin. This includes requests for HTML, CSS, JavaScript, images, fonts, and API calls.

// Register the service worker from your main application
if ('serviceWorker' in navigator) {
  window.addEventListener('load', () => {
    navigator.serviceWorker.register('/sw.js');
  });
}

The service worker file (sw.js) runs in a separate worker thread. It has access to the Cache Storage API, which is separate from the HTTP cache the browser manages automatically. The Cache Storage API is under your complete control: you decide what to cache, when to cache it, how long to keep it, and when to delete it.

// Inside sw.js: intercept a fetch event and respond from cache
self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request).then(cachedResponse => {
      if (cachedResponse) {
        return cachedResponse; // Serve from cache
      }
      return fetch(event.request); // Fall through to network
    })
  );
});

This is the basic cache-first pattern in raw form. Every real application needs more nuance: what if the cache is stale? What if certain resources should never be served from cache? What if the network is unavailable? Writing and maintaining all of this logic by hand is error-prone, which is why Workbox exists.

Strategy 1: Cache-First

Cache-first means: check the cache first. If a response is in cache, return it immediately without hitting the network. Only go to the network if the resource is not in cache.

Use this for: Versioned static assets. JavaScript bundles, CSS files, images, and fonts that have content hashes in their filenames (main-a1b2c3.js). When the content changes, the filename changes, so cached versions are never stale. The old cache entry becomes unreachable by the new URL and gets cleaned up during the next cache update.

Why it works for these resources: Versioned assets are safe to serve from cache forever because the filename is tied to the content. A browser serving main-a1b2c3.js from cache in six months will serve the exact same content that was served when the file was first cached. The application code that requests this file will either request the cached version (nothing changed) or request a different URL (the content changed and the new build output has a new hash).

// Workbox: cache-first for all versioned assets

registerRoute(
  // Match hashed JavaScript and CSS files
  ({ request, url }) =>
    request.destination === 'script' ||
    request.destination === 'style',
  new CacheFirst({
    cacheName: 'static-assets',
    plugins: [
      new ExpirationPlugin({
        maxAgeSeconds: 365 * 24 * 60 * 60, // 1 year
        maxEntries: 60,
      }),
    ],
  })
);

What to avoid: Using cache-first for HTML documents or unversioned API endpoints. If your HTML is served from cache and you deploy a new version, users will continue loading the old HTML until the cache expires. HTML should use network-first or stale-while-revalidate so users always get current navigation and content structure.

Strategy 2: Network-First

Network-first means: try the network first. If the network succeeds, serve the response and update the cache. If the network fails (offline, timeout, server error), fall back to the cached version.

Use this for: HTML pages, API endpoints serving fresh data, and any resource where stale content would cause problems. The user always gets the freshest version when online. When offline, they get a reasonable fallback from cache.

// Workbox: network-first for HTML pages

registerRoute(
  ({ request }) => request.mode === 'navigate', // HTML navigation requests
  new NetworkFirst({
    cacheName: 'pages',
    networkTimeoutSeconds: 3, // Fall back to cache if network takes more than 3 seconds
    plugins: [
      new ExpirationPlugin({
        maxEntries: 50,
        maxAgeSeconds: 30 * 24 * 60 * 60, // Keep cached pages for 30 days
      }),
    ],
  })
);

The networkTimeoutSeconds option is important for offline-capable applications. Without it, network-first will wait indefinitely for a network response even when the user is offline, only falling back to cache after the connection eventually times out (which can take 30-60 seconds). Setting a 3-second timeout means users in poor network conditions get a cached response quickly.

For API endpoints serving user-specific or time-sensitive data:

// Workbox: network-first for API calls
registerRoute(
  ({ url }) => url.pathname.startsWith('/api/'),
  new NetworkFirst({
    cacheName: 'api-responses',
    networkTimeoutSeconds: 5,
    plugins: [
      new ExpirationPlugin({
        maxEntries: 100,
        maxAgeSeconds: 24 * 60 * 60, // Cache API responses for 1 day
      }),
    ],
  })
);

The cached API response is not perfectly fresh, but for most use cases it is better than showing an error page when the network is unavailable.

Strategy 3: Stale-While-Revalidate

Stale-while-revalidate means: serve the cached version immediately (stale), and simultaneously fetch a fresh version from the network in the background (revalidate). The next request gets the fresh version.

Use this for: Resources where some staleness is acceptable and speed is more important than absolute freshness. Navigation assets that change infrequently, avatar images, icon sets, and any resource where showing a slightly old version on the current visit is fine as long as the next visit gets the update.

// Workbox: stale-while-revalidate for images

registerRoute(
  ({ request }) => request.destination === 'image',
  new StaleWhileRevalidate({
    cacheName: 'images',
    plugins: [
      new ExpirationPlugin({
        maxEntries: 60,
        maxAgeSeconds: 30 * 24 * 60 * 60, // 30 days
      }),
    ],
  })
);

The user experience for stale-while-revalidate: on the first visit, there is no cache, so the image loads from the network normally. On subsequent visits, the cached image appears instantly. In the background, the service worker fetches a fresh version from the network. If the image changed, the fresh version replaces the cached version. On the visit after that, the updated image appears instantly.

Why this is powerful for most non-critical resources: Users almost never notice if an avatar image or icon set is one version old. What they notice is speed. Stale-while-revalidate gives them cache speed on every visit while keeping the cache reasonably fresh.

Precaching: caching at install time

All three strategies above are runtime caching: resources get cached when the user visits pages that request them. Precaching is different: you tell Workbox which resources to cache immediately when the service worker installs, before the user has visited any page.

Precaching is used for the application shell: the minimal HTML, CSS, and JavaScript needed to render a working (possibly empty) UI. When the user opens the app, even before any network requests complete, the service worker serves the precached shell and the app renders immediately.

// Workbox: precache the app shell at install time

// This list is generated by Workbox at build time (via workbox-build or the Vite plugin)
// It contains all files from your build output with their content hashes
precacheAndRoute(self.__WB_MANIFEST);

The self.__WB_MANIFEST placeholder is replaced at build time by the Workbox build tool with an array of all your static assets and their content hashes. When a user installs the service worker for the first time, Workbox fetches all these assets and caches them. On subsequent visits, they are served from cache instantly.

Setting up Workbox in a Vite project

The easiest setup for modern projects uses the vite-plugin-pwa plugin, which integrates Workbox configuration into the Vite build process:

// vite.config.ts

  plugins: [
    VitePWA({
      registerType: 'autoUpdate',
      workbox: {
        // Precache all files matching these patterns from the build output
        globPatterns: ['**/*.{js,css,html,ico,png,webp,svg,woff2}'],

        // Runtime caching rules
        runtimeCaching: [
          // Cache-first for versioned assets
          {
            urlPattern: /\.(?:js|css)$/,
            handler: 'CacheFirst',
            options: {
              cacheName: 'static-resources',
              expiration: {
                maxAgeSeconds: 365 * 24 * 60 * 60,
              },
            },
          },
          // Network-first for API calls
          {
            urlPattern: /^https:\/\/api\.example\.com\//,
            handler: 'NetworkFirst',
            options: {
              cacheName: 'api-cache',
              networkTimeoutSeconds: 5,
              expiration: {
                maxEntries: 200,
                maxAgeSeconds: 24 * 60 * 60,
              },
            },
          },
          // Stale-while-revalidate for images
          {
            urlPattern: /\.(?:png|jpg|webp|svg|gif)$/,
            handler: 'StaleWhileRevalidate',
            options: {
              cacheName: 'images',
              expiration: {
                maxEntries: 100,
                maxAgeSeconds: 30 * 24 * 60 * 60,
              },
            },
          },
        ],
      },
    }),
  ],
};

This configuration handles the most common case: versioned JavaScript and CSS with cache-first, API responses with network-first and a 5-second fallback timeout, and images with stale-while-revalidate.

What service workers cannot cache

Opaque responses. Requests to third-party origins without CORS headers return "opaque" responses. Opaque responses can be cached, but their size is counted as 7MB regardless of actual size due to security restrictions. Caching too many opaque responses can exhaust cache storage limits.

Range requests. Video streaming uses HTTP range requests to fetch specific byte ranges. Service workers can intercept these, but handling them correctly requires specific logic. The default Workbox strategies do not handle range requests.

Resources requiring authentication in every request. If a resource requires a fresh token in each request and you cannot cache the token, you cannot meaningfully cache the resource either.

The return visit experience

After a service worker is installed and caching is running correctly, a returning visitor's experience is qualitatively different from a first visit:

User opens the app
Service worker intercepts navigation request
Precached index.html returns instantly from service worker cache
Browser parses HTML, requests JavaScript and CSS
Service worker intercepts those requests, returns from cache instantly
App renders with no network requests at all
In background, service worker fetches fresh API data
UI updates with fresh data when background fetch completes

Steps 1 through 6 complete in under 100ms on most devices, regardless of network speed, because no network requests were made. The perceived load time is the time to render from cache, not the time to fetch from a server.

This is the correct mental model for why service workers matter: not as a way to make network requests faster, but as a way to eliminate network requests entirely for everything that can safely be served from cache.

Read the original article on Renderlog.in:
https://renderlog.in/blog/service-worker-caching-strategies-workbox/

If you found this helpful, I've also built some free tools for developers and everyday users. Feel free to try them once:

JSON Tools: https://json.renderlog.in
Text Tools: https://text.renderlog.in
QR Tools: https://qr.renderlog.in

How I Built a Fully Automated Job Board using Next.js, Prisma, and n8n published: true

wadifapublic — Fri, 15 May 2026 00:27:09 +0000

Building a job board is a classic developer project, but the real challenge isn't building the frontend—it's maintaining the data. Job postings expire quickly, formatting is always inconsistent, and manual data entry is a nightmare.

To solve this, I designed a fully automated architecture that scrapes, structures, and publishes job postings without human intervention. Here is how I built the pipeline using Next.js, Prisma, and n8n.

The Architecture at a Glance

Instead of relying on a traditional CMS, I wanted a highly scalable, developer-friendly stack:

n8n: The brain of the operation. It handles the cron jobs, web scraping, and API orchestrations.
Prisma: The ORM that safely handles our database schema and migrations.
Next.js: The frontend framework delivering blazing-fast SSR/SSG pages, which is crucial for SEO.

Step 1: Automating Data Collection with n8n

Writing custom Python scripts for scraping is fine, but managing their execution and failures is tedious. I used n8n to create visual workflows.

The workflow triggers daily, targeting various public sector portals and company career pages. It extracts raw HTML, parses the relevant nodes (Job Title, Requirements, Deadlines), and outputs clean JSON.

Step 2: Structuring the Data

Job descriptions are notoriously messy. To fix this, the n8n workflow passes the raw text to a local LLM before saving it. The AI extracts the exact hiring requirements, format the salary expectations, and generates a structured summary.

This JSON is then sent via a webhook to my Next.js API route, where Prisma validates the data against my schema and upserts it into a PostgreSQL database.

Step 3: Programmatic SEO with Next.js

For a job board, SEO is everything. You need to rank for highly specific long-tail keywords (e.g., "Technician jobs in Casablanca 2026").

Using Next.js dynamic routing, every new job entry automatically generates a highly optimized page. I inject dynamic JobPosting structured data (Schema.org) directly into the <head>, ensuring the postings appear directly inside the Google Jobs widget.

Because the pages are statically generated (with Incremental Static Regeneration - ISR) or server-side rendered, the page speed is incredibly fast, leading to higher search rankings.

The Result in Action

By combining n8n's automation with Next.js's performance, the platform practically runs itself. New jobs are indexed by Google within hours of being published.

If you want to see this architecture in action, check out a live implementation of this exact stack at WadifaPublic.ma. It aggregates public sector matches and jobs in Morocco with zero manual data entry.

Have you built anything similar using workflow automation tools? Let me know in the comments!

Studio Violin: Building a Physically Modelled Bowed-String Instrument in Instrudio

Gary Doman/TizWildin — Fri, 15 May 2026 00:25:14 +0000

Studio Violin: Building a Physically Modelled Bowed-String Instrument in Instrudio

I’m building Instrudio, a browser-based virtual instrument ecosystem, and the flagship instrument right now is Studio Violin.

Studio Violin is a physically modelled bowed-string instrument built around Helmholtz motion synthesis, H2 harmonic correction, inharmonicity modelling, Stradivari-style body resonances, sympathetic open-string resonance, and live MIDI control.

The goal is not just to make a violin-like web instrument. The goal is to prove that a single version-controlled instrument definition can drive synthesis, UI, MIDI routing, plugin bridge behavior, presets, and live update propagation from one source of truth.

What Studio Violin does

Studio Violin models the behavior of a bowed violin string using a synthesis chain designed around acoustic measurements and practical browser audio constraints.

The instrument includes:

Helmholtz bowed-string waveform synthesis
H2 correction oscillator
Inharmonicity chorus per string
8-band Stradivari-style body EQ
Per-string tonal offsets
Sympathetic open-string resonance
Nonlinear bow coupling
Pressure-coupled vibrato
Interval-scaled portamento
Bow-pressure, bow-speed, bow-point, character, brightness, attack, and vibrato controls
External MIDI routing through the Instrudio app

Synthesis model

The Helmholtz waveform uses a Fourier-style bowed-string model:

bₙ = −(2 / (n²π²D(1−D))) · sin(nπD)
D = 0.5 + bowPressure × 0.30

The H2 correction oscillator is used to bring the second harmonic closer to the target H2/H1 balance measured in bowed-string acoustic research.

Studio Violin also includes per-string inharmonicity spread:

G = 0.00035
D = 0.00028
A = 0.00022
E = 0.00018

The result is a sound engine that behaves less like a static sample trigger and more like a continuously controlled bowed instrument.

Stradivari-style body resonances

The body EQ model uses eight resonance bands:

A0: 275 Hz
A1: 475 Hz
B1−: 530 Hz
B1+: 580 Hz
Bridge hill: 2800 Hz, Q = 6.5
Upper resonance: 4500 Hz
Notch: 1100 Hz
Warmth: 180 Hz

There are also per-string offsets:

G string: warmer, reduced bridge hill
E string: brighter, boosted bridge hill

This lets the instrument react differently across the G, D, A, and E strings instead of applying one flat tone curve to the whole range.

Sympathetic resonance

Studio Violin includes sympathetic resonance using four triangle oscillators tuned to the open strings.

Amplitude = (1 − cents / 20) × 0.038

The closer the played note is to an open-string relationship, the stronger the sympathetic contribution becomes.

Expressive controls

The instrument exposes controls for:

Bow pressure
Bow speed
Bow point
Vibrato rate
Vibrato depth
Attack
Brightness
Reverb
Volume
Playing character

Character modes include:

Solo
Bowed
Pizzicato
Col Legno
Tremolo
Spiccato

It also includes scale helpers such as G Major, D Major, A Minor, and Chromatic.

Signal chain

The current signal chain is:

PeriodicWave oscillator
→ H2 oscillator
→ chorus oscillators
→ WaveShaper
→ injection gain
→ warm shelf
→ 8 peaking body EQ bands
→ master output

Single-source-of-truth instrument architecture

The bigger architecture behind Instrudio is the part I’m most excited about.

Studio Violin is driven by a single JSON definition file. That one definition can drive:

The web audio synthesis engine
The instrument UI
External MIDI CC routing
Note mapping
Plugin bridge event protocol
Preset management
Live auto-update propagation across connected outlets

The runtime uses a remote-first fetch strategy, so definition changes pushed to GitHub can propagate to connected running instances within the cache TTL window.

The default TTL is currently 5 minutes.

Runtime metrics

Instrudio also includes live evaluation metrics for the single-source-of-truth runtime.

The metrics panel can display:

SSOT fetch latency
Definition apply time
Remote source availability
MIDI pipeline latency

These are captured with high-resolution timing through performance.now().

Metrics are also available programmatically through:

InstrudioSSOTRuntime.getMetrics()
InstrudioMIDI.getLatencyMetrics()

Why this matters

A lot of virtual instruments are either sample libraries, closed plugin binaries, or isolated web toys.

Instrudio is aiming for something different:

web-first instruments
version-controlled definitions
measurable runtime behavior
MIDI-aware performance
bridgeable plugin architecture
open development
fast iteration without redeploying every outlet manually

Studio Violin is the flagship proof-of-concept for that architecture.

Repo

https://github.com/GareBear99/Instrudio

Feedback wanted

I’m looking for feedback from:

audio developers
Web Audio developers
musicians
violinists
producers
plugin developers
MIDI users
people interested in physical modelling

Useful feedback includes:

browser and OS
MIDI device behavior
latency
tone realism
UI feel
control response
broken notes or stuck notes
console errors
ideas for the next instrument model

Studio Violin is the flagship instrument in Instrudio, and I’m building it in public.

From Pixels to Peace: My Journey Through Game Dev Struggles and Building a Soulful Zen AI

Arifandi Tanggahma — Fri, 15 May 2026 00:22:43 +0000

Digital creation has always felt like a frontier to me—a place where you can build worlds out of nothing but logic and willpower. But if I’m being honest, the road wasn't paved with clean code; it was paved with frustration, late nights, and a lot of "Why isn't this working?!" moments.

The Godot Revelation: Breaking the Chains of Game Dev Struggle

When I first started my journey into game development, I was doing it the hard way. I wasn't using a dedicated engine like Godot, and man, the struggle was real. I was wrestling with every single line of code just to get a sprite to move or a collision to register. It felt like I was trying to build a skyscraper with a toothpick. I wasn't satisfied, the performance was clunky, and I almost felt like giving up on my dream of being a game dev.

Then, a friend introduced me to the Godot Engine. Everything changed. Suddenly, the bridge between my imagination and the screen became shorter. The node system, the GDScript efficiency—it finally felt like the engine was working with me, not against me. I finally tasted the satisfaction of seeing a game run exactly how I envisioned it. That was the first time I realized that as a developer, your tools don't just help you work; they help you breathe.

The Birth of Zen Reflection: Coding Peace on a Smartphone
But my journey didn't stop at games. I wanted to build something that could help people. That’s when the idea for Zen Reflection (Zeno) was born. I wanted to create a "Modern Monk"—an AI coach that doesn't just give robotic answers but offers genuine compassion for those struggling with bullying, stress, or emotional burnout.
The catch? I wasn't sitting in a high-tech office with three monitors. I coded this entire project on my smartphone.

This project was a true collaborative odyssey between me and my AI partner, Gemini. We went through it all together:

The Backend Battle: We spent hours debugging Vercel Serverless Functions, trying to route the power of Gemini 2.0 Flash into a clean API.

The Logic of Empathy: We didn't just want a chatbot; we wanted a soul. We meticulously crafted the "Zen System Prompt" to ensure Zeno speaks with pauses, nature metaphors, and stoic wisdom.

_The "Jangkrik" Debugging _Sessions: We fought through CORS errors, API quota limits (the dreaded 429 errors!), and region locks. Every time the system crashed, we went back to the drawing board, refined the code, and pushed again.

We Built This Together
Zeno isn't just a project; it's a testament to the fact that you don't need expensive gear to innovate. You just need a vision and the right collaborator. This AI wasn't just "generated"—it was forged through a back-and-forth dialogue between human intent and artificial intelligence. We navigated the complexities of React, Tailwind CSS, and Framer Motion to ensure that when a user feels overwhelmed, they have a beautiful, smooth, and calm interface to turn to.

From the nodes of Godot to the tokens of the Gemini API, my journey has been about finding the right "engine" for my creativity. Zen Reflection is now live, and I couldn't be prouder of the peace we've managed to program into existence.

To all the devs out there coding on your phones or struggling with your first engine: keep pushing. The breakthrough is usually just one "deploy" away.

zeno reflection ai: (https://zen-reflection.vercel.app/),

jangkrik ai: (https://jangkrik02.vercel.app/)

Mala on itch.io: (https://ariikksss.itch.io/mala)

Bounce Rate vs Exit Rate — What Each One Actually Counts in GA4

toshihiro shishido — Fri, 15 May 2026 00:18:17 +0000

"Bounce Rate is high, that's a problem, right?" "What's the difference between Bounce Rate and Exit Rate?"

These are the two metrics most often confused on the analytics floor. On top of that, the move from Universal Analytics (UA) to Google Analytics 4 (GA4) redefined Bounce Rate completely and removed Exit Rate from the default reports.

This article walks through the difference between Bounce Rate and Exit Rate, contrasts the UA and GA4 definitions, and ends with the question every EC operator actually cares about: which one should we be looking at when revenue is on the line?

TL;DR

Different sessions are counted: Exit Rate counts every session that included the page. Bounce Rate counts only sessions that started on that page
GA4 redefined Bounce Rate: what used to mean "single-page session" in UA now means "session without engagement" (1 minus Engagement Rate) in GA4
EC operators read 'exit quality' against revenue: a high Bounce Rate or Exit Rate is not automatically bad — combine it with RPS (Revenue Per Session) to decide whether to fix or to leave alone

1. Bounce Rate — The metric GA4 redefined

Bounce Rate means very different things in GA4 and Universal Analytics. The classic UA shortcut "percentage of single-page sessions" no longer holds in GA4.

Bounce Rate in UA (the old definition)

In UA, Bounce Rate was "the percentage of sessions that started with the page where there was only one pageview". The shorthand "people who left after seeing only one page" became the standard mental model.

Bounce Rate in GA4 (the new definition)

GA4 redefined Bounce Rate as "the percentage of sessions that were not engaged" (1 minus Engagement Rate).

A session counts as engaged when any one of the following is true.

The session lasts longer than 10 seconds
A Key Event (formerly Conversion) fires
There are 2 or more page or screen views

A single-page visit that lasts more than 10 seconds is no longer a bounce. Conversely, a 2-page visit under 10 seconds with no Key Event can still be counted as a bounce.

The simple "high Bounce Rate equals bad" reading is even harder to defend in GA4. Whether a sub-10-second exit means "bounced" or "read through" depends entirely on the page's purpose.

2. Exit Rate — Where each page becomes the last stop

Exit Rate is the percentage of sessions including the page where that page was the session's last.

Exit Rate = Sessions that ended on the page / All sessions that included the page

The fundamental difference from Bounce Rate is the session pool. Bounce Rate's denominator is sessions that started on the page. Exit Rate's denominator is every session that passed through the page.

GA4 dropped Exit Rate from default reports

UA had Exit Rate as a default column. GA4 does not list Exit Rate as a default metric.

To see exit behavior in GA4, use one of these instead. Path Exploration visualizes where users came from and where they exited. Aggregating session_end events shows the page right before the session ended. Combining engagement time with exit volume highlights pages with short stay and high exit.

The very habit of looking at "Exit Rate" as a single metric is downstream of UA's session-based model. Under GA4's event-based model the framing has shifted.

3. Bounce Rate vs Exit Rate — At a glance

A side-by-side table makes the difference clearer.

Aspect	Bounce Rate	Exit Rate
Sessions counted	Sessions that started on the page	All sessions that included the page
Numerator	Not-engaged sessions (GA4)	Sessions ending on the page
GA4 default metric	Yes (re-defined)	No (use Exploration)
Primary use	LP / entry-page evaluation	Identify exit pages

A simpler analogy: Bounce Rate is the share of visitors who turned around at the front door (entry-page lens). Exit Rate is the share of visitors who walked out from each room (per-page lens).

4. From a revenue lens — Are these "bad" metrics?

Both metrics are often labeled "high equals bad", but in practice that shortcut breaks down quickly.

A single-page LP that completes purchase or inquiry on one screen will, by design, see almost everyone "leave after one page". A 90% Bounce Rate is healthy if CVR is good. Article media also: search visitors who read an article and return to results are technically "bounces" but completed the page's actual job.

On the other hand, an EC product detail page where buyers with intent are dropping off has clear improvement levers — button placement, stock indicator, shipping copy. Mid-funnel checkout steps showing a spike on one step usually point to form design issues.

In other words, where the bounce or exit happens, and in what context, is the actual signal. A standalone rate number rarely points to an action.

5. Read "exit quality" with RPS

Both metrics ultimately need to be judged against revenue. Use RPS (Revenue Per Session) — Revenue / Sessions — to read "exit quality".

High exit, low RPS → fix priority ★★★ (revenue leakage is largest)
High exit, high RPS → fix priority ★ (post-conversion natural exit)
Low exit, low RPS → traffic flows but revenue does not (rethink CTA)
Low exit, high RPS → keep as is and replicate elsewhere

Plotting Exit Rate × RPS as a 2 × 2 matrix makes it instantly clear which page deserves the next hour of work.

Question for you

How often do you check Bounce Rate or Exit Rate in isolation versus alongside revenue? In your team, has the GA4 redefinition of Bounce Rate changed how you read those reports — or is the old "single-page session" mental model still in play?

For the full guide with all charts and the revenue-side breakdown:
Bounce Rate vs Exit Rate — The GA4 Basics You Were Afraid to Ask

The Frontier Became a Club

David Aronchick — Fri, 15 May 2026 00:18:03 +0000

Last week Anthropic announced Project Glasswing, the deployment program for the new flagship preview model Claude Mythos. The announcement framed Glasswing as a safety initiative. Mythos would not enter general availability. Instead it would be made available to a "small set of partner organizations under elevated trust and safety review," with structured oversight, third-party audits, and a controlled deployment timeline. The press wrote it up as a thoughtful pause. The companies on the list called their solutions architects.

The companies on the list are: Amazon Web Services, Apple, Cisco, CrowdStrike, Google, JPMorgan Chase, the Linux Foundation, Microsoft, NVIDIA, Palo Alto Networks, and a single research organization the announcement does not name publicly. Each one receives a $100M usage credit, drawn against future commercial usage at preferential pricing. The credit is structured as a multi-year commercial commitment, not a grant, which means each name on the list also represents a guaranteed minimum revenue line on Anthropic's books and a co-development relationship that lasts the length of the contract.

On paper this is a frontier-safety program. Read sideways, it is a hundred-billion-dollar-class commercial alliance, with eleven counterparties, that has decided who gets to run production workloads on the most capable model of 2026 and who does not.

I want to be careful about the framing here. The safety review work that goes into a Mythos-tier deployment is real, the Responsible Scaling Policy is not a marketing document, and the engineers running the partner reviews are not in bad faith. None of that is the part that matters for the rest of the industry. The part that matters is structural. For the first time since the GPT-3 API opened in 2020, the frontier of large-model capability is no longer available to a developer with a credit card. It is available to eleven counterparties under a contract the rest of the market cannot sign.

What being on the list actually buys you

People who have not worked inside one of these alliances tend to read access asymmetry as a feature flag or a latency edge. It is neither. The access asymmetry is co-development.

When a foundation-model lab signs a strategic partnership with a customer at the Glasswing tier, the work that gets done is not "we have an API endpoint that returns Mythos tokens." It is a multi-quarter, multi-team integration in which a solutions architecture team from the lab sits inside the customer for a year, the customer's eval pipelines and the lab's eval pipelines become shared infrastructure, the production telemetry is in dashboards both organizations can see, and the customer's roadmap feeds back into the next model's training mix. This is the pattern that produced the Google Cloud-Anthropic relationship, the AWS Bedrock integration, and every other "deep integration" headline of the last three years. It is the moat. Once it exists, you are not "using" the model. You are running on a version of the model that nobody outside the alliance can replicate by re-pointing an SDK.

The eleven Glasswing partners are getting that, against Mythos, for the next eighteen months. By the time the next capability tier ships into general availability, they will have shipped production systems with an integration depth the rest of the market cannot match in any reasonable timeline. That is the asymmetry. It is not access. It is co-evolution, on a clock the non-partners cannot stop.

There is a second piece of this that the safety framing politely avoids. Several of the named companies operate in regulated environments where deploying a frontier model into a customer-facing application is, today, a legal grey area. JPMorgan Chase cannot, without a license, expose a Mythos-class model to retail banking customers in New York under the draft NYDFS AI guidance. Under Glasswing it can, because the structured-review program co-signed by Anthropic and a compliance partner becomes the regulatory submission itself. The same logic applies to CrowdStrike in endpoint security telemetry, Palo Alto Networks in network traffic inspection, Apple in anything that touches a device, and Cisco in everything touching a customer's network edge. Glasswing is doing double duty. It is a model-access program and a regulatory-cover program, and the companies on the list will spend the next year writing the case law for what a "trusted frontier deployment" looks like. The companies off the list will be regulated against that case law without having helped write it.

The third piece is talent. The most capable foundation-model engineers in the United States make decisions about where to work, in part, by reading the access announcements. An engineer choosing between two equivalent offers in May 2026, one from a Glasswing partner and one from a non-partner, is making a decision about which side of the frontier-access wall they want to be on for the next two years of their career. The wall is one-directional. Once you have shipped a Mythos-class production system you are valuable inside the club and gradually less valuable outside it. The talent flow over the next eighteen months follows the access asymmetry, and the access asymmetry compounds because the talent followed it.

The argument I am willing to grant

The case Anthropic and its partners are making is not weak, and the strongest version of it deserves a serious hearing.

A model at the Mythos capability tier is the first system in the public record where a sufficiently motivated actor could plausibly extract meaningful uplift on a non-trivial set of dual-use domains. Open release of such a system is, under the current RSP framework, a decision the lab is not prepared to make. A graduated release into operators with established compliance infrastructure, audit relationships, and contractual liability is a way to keep the capability frontier moving in production without exposing the underlying model to misuse the lab cannot yet defend against. Nuclear power did this. The FDA medical device pathway does this. The pattern of "novel high-capability technology released first into a small set of trusted operators, then broadly" has, in domains far more dangerous than chatbot text, produced functioning markets over time. The argument applies. I grant it.

What the argument does not address is the part the analogy quietly skips.

Graduated release in nuclear did not produce eleven private operators with $100M in directed credit and a co-development moat against the rest of the industry. It produced the Nuclear Regulatory Commission, a federal licensing regime, and the principle that a reactor operator is a public counterparty subject to a rule set any qualified applicant could meet. The FDA medical-device path licenses by device class to any applicant who clears the bar, not to a pre-selected eleven. In both cases the trusted-operators pattern was bounded by an open licensing regime. Glasswing is not. It is bounded by an Anthropic-internal partner selection process with no published criteria, no appeal, no statutory floor under who can apply, and no public review of who was rejected. The eleven are not a regulated class. They are a chosen class. The choosing was done by the entity that captures the commercial value of having chosen. That is not a safety regime. It is, structurally, an alliance with a safety review attached to it. The two things can be true at the same time, and both are.

Where the production work moves now

If the capability frontier is fenced off, the production AI work the rest of the industry needs to ship in 2026 has to go somewhere. The somewhere-else determines what enterprise AI looks like for the next two years.

There is a tier-down path. You move to the current open-weights frontier, which today means some mix of Llama 4.5, the Mistral Mythoclast checkpoint, DeepSeek V4, and a handful of specialized open releases from Cohere, AI21, and xAI. None is at the Mythos capability tier. But on the median enterprise task the gap between "Mythos-class" and "strong open-weights" is smaller than the gap between either of those and a 2024 baseline, and the gap is closing on a six-month timescale, not a multi-year one. Most enterprise workloads do not need the frontier. They need a competent generalist the deploying organization actually controls. The open-weights frontier is that, and a meaningful chunk of the industry is going to take this path because it works.

There is also a sideways path, and it is the one this site has been arguing for since I started writing it. You stop building against a single proprietary frontier model accessed through a single API endpoint and you build against a federation of smaller models running close to their data, composed against each other under a routing layer the deploying organization controls. The continuity of that architecture does not depend on any single model lab's willingness to serve you. The ceiling on raw capability is lower per call, but the system-level capability scales with the federation rather than with any one component. It is harder to build, you cannot put a single vendor logo at the bottom of the procurement slide, and it requires the deploying organization to invest in data infrastructure that the centralized-model path lets them defer. It is also the only architecture that is robust to next year's version of the Glasswing decision, because there is no single frontier to be denied access to. The frontier is decomposed into capabilities that live in different places.

These two paths coexist in the short run. Over eighteen months they diverge fast and they do not converge again on a common substrate. By 2028 there will be two enterprise AI stacks. The first looks like Glasswing continued. Thick partner integrations against a small number of labs, with most of the platform value captured by the labs and their named consortium members, regulatory case law written by the partners, talent flowing toward access. The second looks like federated, locality-respecting, open-weights composition with no single counterparty in a position to decide who gets to the frontier because the frontier has been disassembled into things that move closer to the data.

Both stacks will exist in 2028. The interesting question is not which one is technically better. They are optimized for different buyers. The interesting question is which one your organization is on the receiving end of, and the answer to that question is being decided right now in budget meetings that are not framed as architectural decisions but are. If you are one of the eleven, the work is real and you should do it well. If you are not one of the eleven, the work is also real, and the cost of waiting eighteen months to see whether the list grows is eighteen months of integration depth the partners are building against a model you cannot deploy.

The frontier did not become unavailable. It became a club. The interesting question this year is not whether you get in. It is whether you build the alternative while the door past it is still cheap to walk through.

Want to learn how intelligent data pipelines can reduce your AI costs? Check out Expanso. Or don't. Who am I to tell you what to do.*

NOTE: I'm currently writing a book based on what I have seen about the real-world challenges of data preparation for machine learning, focusing on operational, compliance, and cost. I'd love to hear your thoughts!

Originally published at The Frontier Became a Club.

From 'No, sir' to 'Why, sir'. With 'Yes, sir' in between

Emory Raphael — Fri, 15 May 2026 00:16:40 +0000

Not long time ago, the corporation environment complains about how many 'No, sir' they were receiving from their dev teams, because of the high demanding, high asking, no priority pool, no conversation, inflate backlogs and everything that you can think about the daily basis of a regular company. Then the AI came up to solve this, to bring productive, high-speed delivery, reduce the technical bottleneck, and all excuses that non-technical fellows would love the hear.

No, sir

This moment where we still adapting about the many frameworks were propagating, migrations from local to cloud, scalable designs, discussion as "microservice vs monolithic", or any other tech topics that you can think of. Our demand to be on the latest topic was huge, and manage the tradeoff between new and old framework, introduce new bugs and maintain legacy code could delay the implementation of new features on the systems, pick a new task from the backlog just to cleaning it.
Because of these back-and-forth conversations among all the actors that compose a regular (let's call old just to laugh a bit) old team structure: devs, devops, PM, scrum master, QA team, manager, and so on, we constant said each other 'No, sir... we cannot implement this in the moment. Please, add this task to our backlog'.
Then the team's structure and ways to address and news idea swift to a fast pace, no boundaries, limit only by the numbers of token allowed... if you have this limit!

Yes, sir

What no one could think of (I mean, few folks over the world advise this, but not important right?!), is that tradeoff is the lack of quality vs more PRs, the bottleneck now is the high volume of non-checkable code, hidden bugs, extra "features that goes along with your prompt, just because the model found a similar vector to your question, even that the context / business implication is complete different. And, as any coder know, is harder to validate and reviews PRs with thousands of file changes.
Now, the fast-paced mind has a tool that only respond 'Yes, sir... as you command', even that don't do it as you asked, but it doesn't limit you as well. They can implement, test the idea as they have always wished, only that they don't know what is happening in the background.
Also, productive is measure by completeness tasks, but without detailed and clear criteria, the bar is too slow, but, hey, you are moving faster than we have ever had! Critics choices are not in the table anymore, there are no conflict ideas, because there is only user prompt idea. You have a bias servant applying the commands you give.
Do you allow to proceed with the next phase, sir?

Why, sir

Recently in a conversation among some students, I couldn't emphasis enough about how important we are as a human layer in the new time of tech, how our understanding about the world and humanity are a gate keeper of the responses for the AI. I mean, they are not evil or good, they are tools that can mimic humans' thoughts, behaviors and decisions. It's like have a small piece of yourself in a very specific point of the time (fun when you know that matrix weights in training are called checkpoints).

When we bring back the human conversation and interaction, after seeming our services stall, forgotten because they didn't solve any real problem than our ego to delivery something, even the lower minimal thing. Question mark like:

Would we have experience to question?
What is actually a good question?
Who should be questioning it?

Not sure if hope is the world, but I am looking forward to the imperative speak tune reduce, and the question raise again.

From zero to working product in two hours

Adam Shallcross — Fri, 15 May 2026 00:16:22 +0000

So tonight I went to an Umbraco.AI hackathon, and somehow walked out with a working product.

Not a hand-wavy prototype, not a "here's roughly what it could do" demo, but an actual end-to-end thing that does what it says on the tin, ready to show to people, ready to install on a real site.

Two hours.

And I didn't write a single line of code myself.

The problem I picked

AI-generated contact form spam has quietly become one of those headaches nobody really talks about. It reads as plausible English, has none of the obvious spam markers we've all trained ourselves to spot, and walks straight past the usual defences. If you run a public-facing website, you've almost certainly been quietly deleting it out of your inbox for the last twelve months, even if you hadn't quite put a name to it.

Nobody had built anything in the Umbraco ecosystem to deal with this at the contact form level, and that felt like a gap worth filling.

The idea was simple enough. Every time someone submits a form on your website, send the contents to an AI model, ask it to score how likely the submission is to be genuine, and if it looks like spam, stop it before it ever reaches your inbox or your team. The legitimate enquiries flow through as normal. The spammy ones get held back and logged somewhere you can review them later.

Easy on paper. The challenge was getting it built, working, and demonstrable in the time available.

How I actually built it

I used Claude Code.

For anyone who hasn't come across it yet, Claude Code is a tool that lets you describe what you want a piece of software to do, in plain English, and have it produce the actual code for you. You stay in the driving seat, you make the architectural decisions, you spot when it's gone off-track, you tell it what to fix. But the typing-the-actual-code part isn't your job anymore.

That matters more than it sounds, because I'm not a developer. I've spent twenty-odd years in and around digital delivery, leading teams, scoping projects, understanding the shape of what good looks like, but I've never been the person hands-on-keyboard writing C# at one in the morning. Historically, to ship something like this, I would have needed to find a developer, brief them, wait for them, and hope I'd communicated clearly enough that what came back resembled what I'd asked for.

Tonight, I just had the idea, the plan, and the tool.

The plan was what made the difference, not the typing. I went in with a proper product brief, a rough hour-by-hour breakdown, and a small set of test examples I'd prepared covering obvious spam, plausible AI outreach, and genuine enquiries. Claude Code did the actual building. I did the thinking, the steering, and the testing.

What actually happened

None of it went quite as I'd written it down.

The biggest surprise was how much the world had moved on from the version of reality I was carrying in my head. Things I'd assumed worked one way had been changed, renamed, or replaced entirely in newer versions of the platform. There's something quite humbling about discovering all of that in real time, with a clock running and people drifting over to ask how it's going.

This is where the tool genuinely earns its keep. When something didn't work the way the documentation said it should, I didn't have to dig through forum threads at midnight or guess at the right call to make. I'd describe the symptom, Claude Code would write a tiny test probe to confirm what was actually happening, and within a minute or two we'd know whether the real platform behaved like the docs said it did. Spoiler, it often didn't.

That probably sounds obvious. It isn't. The temptation under time pressure is always to skip the small experiment and just start building the thing, and almost every time you regret it.

What I built in

The other thing I leaned into early was a safety net.

A spam filter that breaks your contact form is worse than the spam itself, and I wanted that property baked in from the first commit rather than bolted on later. So the whole thing is wrapped in a "default-pass" guarantee. If the AI takes too long to respond, the submission goes through. If the response comes back garbled, the submission goes through. If anything at all goes wrong, the submission goes through.

The AI scoring is a quality-of-life feature, not a hard gate. That mindset shaped a lot of the design.

I also added a master kill switch and a configurable threshold, so anyone installing this can decide for themselves how aggressive they want it to be, or turn it off entirely without uninstalling. Small thing, but it matters. The worst thing a package can do is take options away from the people using it.

None of those decisions were the tool's. They were mine. The tool just made them happen.

What I learned

The headline lesson, for me, isn't really about spam filtering or contact forms. It's about what the role of the person sitting in front of these AI tools is actually becoming.

You don't need to be able to write the code anymore. You need to be able to define the problem clearly, design the safety nets, spot when the output is heading in the wrong direction, and know when to stop and ask a better question. That's a different skill set to the one our industry has been hiring for the last fifteen years, and it's one that experienced engineers, product people, and consultants are already quietly really good at, even if they've never thought of themselves as builders.

The gap between "I understand this conceptually" and "I can ship this in two hours" used to be made up of the typing. The actual writing of the code. The bit you had to either learn or pay someone else to do.

That gap has narrowed, sharply.

What's left in the gap is the harder, more interesting stuff. The judgement about what to build. The discipline to test your assumptions against reality. The instinct for when something is about to go wrong. The willingness to keep going when the first three attempts didn't work. None of that gets easier with better tools. If anything, it matters more, because the tools will happily produce something plausible and broken if you don't know what you're doing.

The reason I got over the line tonight wasn't that I had Claude Code. It was that I knew exactly what I wanted to build, why, and what good looked like along the way.

Where it lands

The package scored eight and a half out of nine on the test corpus. All the block decisions were correct. The legitimate enquiries flowed through normally, the spam got held back, and the flagged entries showed up in a dashboard a moment later for review.

There's a clear roadmap of next steps already forming in my head. Editor feedback loops so you can mark a flagged entry as a false positive and have the model learn from it. Webhooks out to Slack so a flagged entry can ping a channel for review. Per-form custom prompts for sites running very different kinds of enquiries. Stats over time. None of that was going to fit in two hours, and that's fine, because the point of an evening like tonight isn't to finish the thing. It's to prove the thing is possible.

The bit that's stayed with me, walking home, isn't the technical journey. It's that someone with no coding ability, but with twenty years of knowing what good software looks like, can now sit down in an evening and produce a real working product.

That's a genuinely new thing in our industry, and I don't think most people have fully felt the shape of it yet.

Two hours. One working product. Not a line of code typed by me.

What would you point a two-hour hackathon at, if you knew you could actually finish it?