DEV Community: Muhammad Awais

How to Add WebMCP to Your Next.js App (Complete 2026 Guide)

Muhammad Awais — Tue, 23 Jun 2026 04:16:56 +0000

I was watching Gemini in Chrome try to use a Next.js app I'd built. The agent was taking screenshots, guessing which input field was "search," clicking in the wrong places, hallucinating button labels.

It was painful to watch. Like watching someone read a book through a foggy window.

That's the exact problem WebMCP was built to solve.

WebMCP is a W3C draft standard that adds a navigator.modelContext API to browsers. Instead of an AI agent scraping your DOM and guessing what your app does, your Next.js app tells the agent exactly what it can do — in structured, machine-readable terms. The agent calls a function, gets clean data, moves on.

No screenshots. No broken selectors. No hallucinations.

In this guide: what WebMCP actually is, how it differs from Anthropic's MCP, and a complete step-by-step implementation in Next.js App Router with working code.

WebMCP vs MCP — Clear This Up First

This confuses a lot of developers. One sentence each:

Anthropic's MCP runs server-side. Your AI agent connects to a backend over JSON-RPC to access databases, file systems, or external APIs. Runs outside the browser entirely.

WebMCP runs client-side, inside the browser tab. Your site registers tools with navigator.modelContext, and in-browser agents discover and call them locally. No separate server. No extra auth. The agent uses whatever session the logged-in user already has.

They're complementary, not competing. A flight booking site might use WebMCP so browser agents can search flights on the front end, while also running an MCP server so Claude or GPT can book flights via API on the back end.

Feature	Anthropic MCP	WebMCP
Where it runs	Server-side	Browser tab
Protocol	JSON-RPC over stdio/HTTP	`navigator.modelContext` API
Auth	Separate auth required	Uses existing browser session
Backend needed?	Yes	No (zero backend)
Who made it	Anthropic	W3C (Google + Microsoft)
Browser support	N/A	Chrome 146+ (flag), Edge 147+ (flag)

The W3C published the WebMCP Draft Community Group Report on February 10, 2026. Chrome 146 shipped the first implementation behind a feature flag. All four major browser vendors are at the table — Google, Microsoft, Mozilla, Apple. That's a strong signal.

The Two APIs — Declarative vs Imperative

WebMCP gives you two ways to expose tools.

Declarative API — HTML Attributes (2 minutes to ship)

Already have HTML forms? Add two attributes:

<form
  toolname="searchProducts"
  tooldescription="Search the product catalog by keyword and category. Returns matching products with price and availability."
>
  <input name="query" type="text" placeholder="Search..." />
  <select name="category">
    <option value="">All categories</option>
    <option value="electronics">Electronics</option>
  </select>
  <input name="maxPrice" type="number" />
  <button type="submit">Search</button>
</form>

Done. An agent sees a searchProducts tool with typed parameters inferred from your form fields. Zero JavaScript needed.

Use for: search forms, filters, contact forms, newsletter signups.

Imperative API — registerTool()

For dynamic interactions, stateful logic, or multi-step flows:

if ('modelContext' in navigator) {
  navigator.modelContext.registerTool({
    name: 'getUserDashboard',
    description: "Get the current user's dashboard summary including recent orders, wishlist count, and loyalty points.",
    inputSchema: {
      type: 'object',
      properties: {
        includeOrders: {
          type: 'boolean',
          description: 'Include last 5 orders in the response'
        }
      },
      required: []
    },
    async execute({ includeOrders }) {
      const res = await fetch('/api/dashboard', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ includeOrders })
      });
      return res.json();
    }
  });
}

The if ('modelContext' in navigator) check is not optional. Browsers without WebMCP support shouldn't throw errors — they should degrade gracefully. The JSON Schema in inputSchema is the same format Claude, GPT, and Gemini already use for function calling. WebMCP speaks the language LLMs already understand.

Step-by-Step: Next.js App Router Implementation

Let's wire this into a real Next.js 15 project. I'll use a product search app as the example.

Step 1 — Install the Polyfill

Chrome 146+ has WebMCP behind a flag. Edge 147+ too. Everyone else needs the polyfill:

npm install @mcp-b/global @mcp-b/react-webmcp

@mcp-b/react-webmcp gives you the useWebMCP hook, which handles registration and cleanup automatically when components mount/unmount.

Step 2 — Initialize in Root Layout

Create a Client Component that initializes the polyfill once:

// components/WebMCPProvider.tsx
'use client';

import { useEffect } from 'react';

export function WebMCPProvider({ children }: { children: React.ReactNode }) {
  useEffect(() => {
    if (!('modelContext' in navigator)) {
      import('@mcp-b/global').then(({ initializeWebMCPPolyfill }) => {
        initializeWebMCPPolyfill();
      });
    }
  }, []);

  return <>{children}</>;
}

Add it to app/layout.tsx:

import { WebMCPProvider } from '@/components/WebMCPProvider';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <WebMCPProvider>
          {children}
        </WebMCPProvider>
      </body>
    </html>
  );
}

Step 3 — Register Tools in Page Components

Key principle: register tools when the UI is visible, unregister when the user leaves. The useWebMCP hook handles this automatically via AbortController.

// app/products/ProductsPageTools.tsx
'use client';

import { useWebMCP } from '@mcp-b/react-webmcp';
import { z } from 'zod';

export function ProductsPageTools() {
  useWebMCP({
    name: 'searchProducts',
    description:
      'Search the product catalog. Returns products with name, price, rating, and stock status. Use when the user asks to find, browse, or filter products.',
    inputSchema: z.object({
      query: z.string().describe('Search keywords — e.g. "wireless headphones"'),
      category: z.string().optional().describe('Product category filter'),
      maxPrice: z.number().optional().describe('Maximum price in USD'),
      inStock: z.boolean().optional().describe('Only return in-stock items'),
    }),
    execute: async ({ query, category, maxPrice, inStock }) => {
      const params = new URLSearchParams({ q: query });
      if (category) params.set('cat', category);
      if (maxPrice) params.set('max', String(maxPrice));
      if (inStock) params.set('inStock', '1');

      const res = await fetch(`/api/products?${params}`);
      if (!res.ok) throw new Error('Search failed');
      return res.json();
    },
  });

  return null; // renders nothing — just manages tool registration
}

Drop <ProductsPageTools /> inside your products page. When the component mounts, the tool registers. Navigate away — it automatically unregisters. Clean, no memory leaks.

Step 4 — Enable the Chrome Flag and Test

Open Chrome 146+
Navigate to chrome://flags
Search for "webmcp" → set "Enable WebMCP for testing" to Enabled
Relaunch Chrome
Open your app (localhost or HTTPS — plain HTTP won't work in production)
Open DevTools (F12) → Console → run: navigator.modelContext
If you see an object (not undefined), WebMCP is active ✅
Install the Model Context Tool Inspector extension from the Chrome Web Store — it shows registered tools and lets you invoke them with test inputs without needing an actual AI agent

That last step saved me ~40 minutes of debugging on my first implementation. Highly recommend.

Gotchas That Bit Me (So They Don't Bite You)

1. Single-Tab Scope

Tools only exist while the page is open. Navigate away — tools are gone. Refresh — they re-register. This is intentional (security), but make your tool descriptions rich and self-explanatory. The agent can't know what tools exist without visiting your page first.

2. provideContext() Is Gone

Earlier drafts had a provideContext() method for passing page state to agents. It was removed in March 2026. If you see tutorials using it, they're outdated.

The current pattern: bake context into your tool's description string directly.

// ❌ Old (removed)
navigator.modelContext.provideContext({ userId: '123' });

// ✅ Current
const userId = getCurrentUser().id;
useWebMCP({
  name: 'getUserOrders',
  description: `Get recent orders for the currently logged-in user (ID: ${userId}). Returns last 10 orders with status and tracking.`,
  // ...
});

3. Tightly Coupled React State Won't Work

Tool handlers don't have access to React state or Zustand stores. If your app logic is buried in component state, handlers will run with stale data.

Fix: put data-fetching logic in a shared service layer (plain functions, not hooks) and call it from both your UI and WebMCP handlers.

4. The 50-Tool Soft Limit

No hard cap in the spec, but stay under 50 tools per page. Each tool definition gets included in the agent's context window. Too many tools → bloated context → slow agent reasoning. Expose the actions that actually matter for agent workflows.

5. HTTPS Is Mandatory in Production

localhost gets a pass in dev. In production — HTTPS only. Custom local domains like myapp.test need a self-signed cert or ngrok.

Browser Support — Honest Picture (June 2026)

Browser	Status
Chrome 146+ Stable	✅ Behind flag (`enable-webmcp-testing`)
Edge 147+	✅ Behind flag (same as Chrome)
Chrome 149	🔜 Public Origin Trial (no flag needed)
Firefox	🔄 In W3C Working Group, no timeline
Safari	🔄 Bug-tracker entry, no commitment

Mainstream AI agents (Claude Desktop, ChatGPT, Gemini app) don't call WebMCP tools directly on websites yet as of mid-2026. The working bridge is the MCP-B browser extension, which aggregates WebMCP tools from open tabs and forwards them to local MCP clients.

The realistic timeline: late 2026 for Chrome Stable with WebMCP on by default.

Is It Worth Building Now?

Cost: a few hours of work. The polyfill handles cross-browser fallback. The useWebMCP hook handles cleanup. When Chrome flips the default switch, your app is already ready.

Start with one tool — the most important search or filter your users perform. Add useWebMCP. Test it with the Chrome DevTools inspector. Ship it. Then add more as the spec stabilizes.

The sites that did responsive design early won mobile. The ones that structured their content early won featured snippets. WebMCP is the same dynamic — and the cost of being early is genuinely low this time.

Resources

W3C WebMCP Draft Spec
WebMCP-org on GitHub — polyfill, React hooks, DevTools extension
Model Context Tool Inspector — Chrome extension for testing

Originally published at WebToolsHub — free developer tools and guides.

Antigravity IDE Black Screen After 2.0 Update - All Fixes (Windows, Mac, Linux)

Muhammad Awais — Wed, 17 Jun 2026 13:34:25 +0000

The Problem Nobody Warned Us About

On May 19, 2026, Google pushed Antigravity 2.0 as a silent automatic update. If you were using Antigravity 1.x that morning, you woke up to one of these:

A completely black Electron window
A blank white screen where your IDE should be
An IDE that opens but shows no file explorer, no project — just empty panels
An "Open IDE" button that does absolutely nothing

The frustrating part? Nothing about your machine changed. No driver update, no OS change. It's a packaging bug — and it's fixable in under 10 minutes once you know what actually happened.

What Antigravity 2.0 Actually Changed (And Why It Broke Things)

Antigravity 2.0 isn't an update to the IDE. It's an architecture split. Google separated the product into:

Antigravity — the new agent-focused launcher (this is what the 2.0 update installed)
Antigravity IDE — the actual code editor (this was NOT automatically installed)

When the update ran, it replaced your old IDE executable with the new launcher. The launcher looks for the IDE component, doesn't find it, and renders a blank window.

Additionally, the AppData path changed:

# Old path (Antigravity 1.x)
%APPDATA%\Roaming\Antigravity\

# New path (Antigravity 2.0+)
%APPDATA%\Roaming\Antigravity IDE\

Your settings, workspace state, extensions — all still in the old folder. The new IDE launches with an empty profile. This is why your file explorer shows nothing even after getting the IDE to open.

Version Timeline (Find Where You Are)

Version	Released	Known Issues
2.0.1	May 19, 2026	Blank/black screen, no IDE access
2.0.6	May 22, 2026	"Open IDE" button added but often non-functional
2.0.10	May 28, 2026	Minor stability fixes
2.0.11	June 3, 2026	Fixed antivirus GPU block + Open IDE button bugs

Check your version: Help → About (if you can get to the menu bar at all).

Fix 1: Update to 2.0.11

If the menu bar is visible on your blank screen:

Help → Check for Updates → Install → Restart

Critical: After closing, kill all processes before relaunching. On Windows:

# Kill all Antigravity processes
taskkill /F /IM antigravity.exe /T
taskkill /F /IM "antigravity ide.exe" /T

Then relaunch. Version 2.0.11 fixes the antivirus interference issue and the Open IDE button bugs — two of the most reported problems.

Fix 2: Clear Cache and Logs (2 Minutes)

Corrupted cache from a bad update or crash causes blank rendering even on a correctly installed IDE.

Windows:

# 1. Kill processes first
taskkill /F /IM antigravity.exe /T

# 2. Navigate and delete
cd $env:APPDATA\Antigravity
Remove-Item -Recurse -Force logs, Cache -ErrorAction SilentlyContinue

# 3. Relaunch

macOS:

pkill -f Antigravity
rm -rf ~/Library/Application\ Support/Antigravity/logs
rm -rf ~/Library/Application\ Support/Antigravity/Cache

Linux:

pkill -f antigravity
rm -rf ~/.config/Antigravity/logs ~/.config/Antigravity/Cache

Projects and extensions are stored separately — this is safe to run.

Fix 3: Clean Reinstall

When the cache clear doesn't work, a clean reinstall does. Your project files on disk are not touched.

Windows — full removal script:

# 1. Kill processes
taskkill /F /IM antigravity.exe /T

# 2. Uninstall via winget (if installed that way)
winget uninstall "Antigravity"
winget uninstall "Antigravity IDE"

# 3. Or uninstall manually: Settings → Apps → search "Antigravity" → uninstall both

# 4. Clean up AppData
Remove-Item -Recurse -Force "$env:APPDATA\Antigravity" -ErrorAction SilentlyContinue
Remove-Item -Recurse -Force "$env:APPDATA\Antigravity IDE" -ErrorAction SilentlyContinue
Remove-Item -Recurse -Force "$env:LOCALAPPDATA\Antigravity" -ErrorAction SilentlyContinue
Remove-Item -Recurse -Force "$env:LOCALAPPDATA\Antigravity IDE" -ErrorAction SilentlyContinue
Remove-Item -Recurse -Force "$env:USERPROFILE\.antigravity" -ErrorAction SilentlyContinue

# 5. Download fresh installer from antigravity.google and run

macOS:

# Remove app
sudo rm -rf /Applications/Antigravity.app
sudo rm -rf /Applications/Antigravity\ IDE.app

# Remove all data
rm -rf ~/Library/Application\ Support/Antigravity
rm -rf ~/Library/Application\ Support/Antigravity\ IDE
rm -rf ~/.antigravity

# Remove launch agents if any
launchctl list | grep antigravity
# For each result: launchctl remove <name>

Linux (Ubuntu):

sudo apt remove antigravity-ide
sudo apt autoremove
rm -rf ~/.config/Antigravity ~/.antigravity

Linux (Fedora):

sudo dnf remove antigravity-ide
rm -rf ~/.config/Antigravity ~/.antigravity

# After reinstalling, if still black screen:
antigravity --no-sandbox
# Fedora 40+ SELinux can block Electron — no-sandbox bypasses it

Fix 4: Open IDE Button Doing Nothing

The launcher and IDE communicate via a local socket. If that connection fails, the button appears to do nothing.

Workaround: Launch Antigravity IDE directly as a standalone app, bypassing the launcher entirely.

# Windows — find and launch directly
$idePath = "$env:LOCALAPPDATA\Programs\Antigravity IDE\Antigravity IDE.exe"
if (Test-Path $idePath) { Start-Process $idePath }
else { Write-Host "Not found — check %LOCALAPPDATA%\Programs\" }

If the shortcut is missing from Start Menu, find the exe at %LOCALAPPDATA%\Programs\Antigravity IDE\ and create a shortcut manually.

Fix 5: File Explorer Missing — AppData Migration

This is the issue most guides completely miss. You get the IDE open, but see an empty workspace with no file explorer because your settings are in the wrong folder.

# Windows — migrate old settings to new location
$old = "$env:APPDATA\Antigravity"
$new = "$env:APPDATA\Antigravity IDE"

if (Test-Path $old) {
    if (-not (Test-Path $new)) { New-Item -ItemType Directory -Path $new }
    Copy-Item "$old\*" -Destination $new -Recurse -Force
    Write-Host "Settings migrated — restart Antigravity IDE"
} else {
    Write-Host "Old folder not found — may already be migrated"
}

# macOS / Linux equivalent
OLD=~/Library/Application\ Support/Antigravity
NEW=~/Library/Application\ Support/Antigravity\ IDE
mkdir -p "$NEW"
cp -r "$OLD/"* "$NEW/"

After running this, restart Antigravity IDE. Extensions, themes, snippets, and workspace state should all come back. Reopen your project folder once via File → Open Folder.

Fix 6: Antivirus Causing Instant Black Screen (Windows)

Some antivirus configurations block Electron's GPU subprocess. The result is an instantly black window with zero loading.

Add these paths to your AV exclusions:

C:\Users\<YourUser>\AppData\Local\Programs\Antigravity IDE\
%APPDATA%\Antigravity
%APPDATA%\Antigravity IDE

Windows Defender via PowerShell:

$idePath = "$env:LOCALAPPDATA\Programs\Antigravity IDE"
Add-MpPreference -ExclusionPath $idePath
Add-MpPreference -ExclusionPath "$env:APPDATA\Antigravity"
Add-MpPreference -ExclusionPath "$env:APPDATA\Antigravity IDE"
Write-Host "Exclusions added — relaunch Antigravity IDE"

Quick Decision Guide

Blank screen appeared → Menu bar visible?
  YES → Update to 2.0.11 (Fix 1)
  NO  → Clean reinstall (Fix 3)

After reinstall → IDE opens but empty workspace?
  YES → AppData migration (Fix 5)

Open IDE button → Does nothing?
  YES → Launch IDE directly (Fix 4)

Instantly black on startup → Windows with AV software?
  YES → Add AV exclusions (Fix 6)

None of the above → Clear cache first (Fix 2), then Fix 3

While Your IDE Was Down

I kept working using browser tools that need zero setup:

JSON → TypeScript — validated config interfaces without the IDE
Regex Tester — checked patterns in Antigravity log files
Unix Timestamp Converter — cross-checked log timestamps

Everything runs in the browser — no data leaves your machine. Useful when you're debugging with config files that have API keys or sensitive data.

Full Guide + FAQ

For the complete breakdown including Mac launch agent removal, Ubuntu Wayland fix (--ozone-platform=x11), Fedora SELinux commands, all 7 FAQs, and version-by-version explanation:

👉 Complete Antigravity Black Screen Fix Guide — WebToolsHub

If the PowerShell migration script (Fix 5) saved you — drop a reaction. Took me an embarrassing amount of time to figure out that one.

How to Use OpenCode — The 160K-Star Free Cursor Alternative (2026)

Muhammad Awais — Tue, 16 Jun 2026 12:21:45 +0000

Originally published on WebToolsHub — free browser-based developer tools for modern devs.

You've probably seen OpenCode trending on your GitHub feed lately. 160,000+ stars. 7.5 million monthly active developers as of June 2026. The kind of growth that makes you stop and actually pay attention.

I spent three weeks using it on a real Next.js SaaS project before writing this. Not a quick "install and screenshot" job — actual production workflow testing. Here's everything I learned, including the stuff most guides skip.

🤔 Wait, What Even Is OpenCode?

Most people assume it's another autocomplete tool like Copilot. It's not.

OpenCode is a terminal-native agentic coding assistant — it understands your entire project, creates a plan, then executes multi-step tasks autonomously. Think of it as a junior developer who can:

Read all your project files
Write new code and edit existing files
Run shell commands and install packages
Execute tests and fix failures
Explain what it's doing at each step

The killer feature: model agnosticism. OpenCode connects to 75+ AI providers. Claude, GPT, Gemini, DeepSeek, Groq, and even fully local models via Ollama. You bring your own API keys and pay per token. No $20/month subscription that hits rate limits after two hours.

📦 Installation (Pick Your Method)

Method 1: Official Script — Fastest Option

Works on macOS, Linux, WSL. Run this:

curl -fsSL https://opencode.ai/install | bash

Verify it worked:

opencode --version
# v1.17.4 or later (current as of June 2026)

Method 2: npm

npm install -g opencode-ai

Good if you want version control via your Node.js package manager.

Method 3: Homebrew (macOS)

brew install opencode

Method 4: Go Install (Advanced / Compile from Source)

go install github.com/sst/opencode@latest

⚠️ Important: Since January 9, 2026, Anthropic blocked OpenCode from using Claude via consumer OAuth (Claude Pro/Max). You need an API key from console.anthropic.com if you want Claude models. Gemini 2.5 Pro and DeepSeek V4 are great alternatives — and honestly, Gemini Flash is what I use 80% of the time now.

⚙️ Configure Your AI Provider

Run the interactive setup:

opencode auth

Or manually create .opencode.json in your home directory or project root:

{
  "provider": "google",
  "model": "gemini-2.5-pro",
  "providers": {
    "google": {
      "apiKey": "${GEMINI_API_KEY}"
    },
    "anthropic": {
      "apiKey": "${ANTHROPIC_API_KEY}"
    },
    "openai": {
      "apiKey": "${OPENAI_API_KEY}"
    }
  }
}

Want completely free usage? Use Ollama with a local model:

{
  "provider": "ollama",
  "model": "llama3:8b",
  "providers": {
    "ollama": {
      "baseURL": "http://localhost:11434"
    }
  }
}

⚠️ Local models are noticeably weaker on multi-step tasks. Great for quick edits, not ideal for complex refactors. Use a frontier model when correctness matters.

If you're integrating OpenCode into a Next.js project with local AI, the Ollama + Next.js guide on WebToolsHub covers the full setup in detail.

🔍 The Feature Nobody Talks About: LSP Integration

This is OpenCode's most underrated advantage. Native Language Server Protocol (LSP) integration — it automatically spawns the correct language server (TypeScript, Python, Go...) and feeds real compiler diagnostics back to the AI after every edit.

Why this matters: Imagine OpenCode refactoring a Next.js component and introducing a TypeScript type error. Without LSP, the AI doesn't know. With LSP, the error feeds back into the next prompt automatically, and the model self-corrects — no copy-pasting error messages from your terminal.

In a Builder.io head-to-head test (Claude Sonnet 4.5, identical tasks), OpenCode wrote 21 more tests than Claude Code on the same codebase. The LSP feedback loop is a big reason.

This matters most on multi-file refactors with large TypeScript codebases. If you're working with complex API types, pair this with the JSON to TypeScript converter to keep your types accurate as the agent works.

⚔️ OpenCode vs Claude Code: The Honest Take

I've used both heavily. Here's my unfiltered take.

Where Claude Code Wins

Speed. Builder.io's benchmarks show OpenCode takes ~78% longer per identical task when running the same Claude model. The overhead comes from OpenCode's client-server architecture — even when running locally, the TUI talks to a backend process. If you're doing rapid-fire development, you'll feel that gap.

Where OpenCode Wins

Basically everything else:

Factor	OpenCode	Claude Code
Cost	Pay per token only	$20/mo + rate limits
Privacy	Ollama = fully local	Everything → Anthropic servers
Model choice	75+ providers	Anthropic only
LSP integration	✅ First-class	❌ Not native
Planning mode	`/plan` disables all writes	✅ Similar
Open source	✅ MIT licensed	❌ Proprietary

My actual recommendation: Use both. Claude Code for speed-critical production work. OpenCode for experimentation, privacy-sensitive codebases, and when you want model flexibility without burning a subscription.

The Claude Code Skills guide on WebToolsHub is worth reading too — most of those markdown skill files work in OpenCode with minor edits.

🚀 Real Next.js Workflow with OpenCode

This is the actual workflow I use on production projects.

Step 1: Initialize Project Context

cd my-nextjs-app
opencode

Inside the OpenCode session:

/init

This analyzes your codebase, understands your conventions and patterns, and creates a .opencode/ directory with persistent context. Always do this first.

Step 2: Use Planning Mode for New Features

Before touching any files:

/plan
Add rate limiting middleware to all API routes using Upstash Redis

OpenCode analyzes your existing routes, checks your dependencies, and produces a detailed implementation plan. Review it before saying "proceed." This 30-second habit saves hours.

Step 3: Give Explicit Scoped Instructions

Refactor /src/components/UserCard.tsx to use the shadcn Card component.
Keep all existing props. Don't touch parent components.
Run TypeScript check after making changes.

That last line — "run TypeScript check" — is where LSP integration shines. OpenCode runs tsc --noEmit, sees errors, and fixes them in the same session.

Step 4: Use /undo Liberally

OpenCode takes Git-based snapshots before every change. /undo reverts instantly. Use it constantly. This is what makes it safe to let the agent work aggressively.

💸 What Does OpenCode Actually Cost?

OpenCode itself: $0, forever, MIT licensed.

Model API costs for a typical developer daily use:

Model	Cost	Best For
Gemini 2.5 Flash	~$0.15/1M tokens	Quick edits, boilerplate
Gemini 2.5 Pro	~$3.50/1M tokens	Architecture, refactors
Claude Sonnet 4.6 (API)	~$3/1M tokens	TypeScript-heavy work
Claude Opus 4.6 (API)	~$15/1M tokens	Hard multi-file problems
Ollama (local)	$0.00	Privacy-sensitive tasks

For most developers, Gemini Flash handles 80% of tasks at near-zero cost. Save the heavy models for hard problems. Use the LLM API Cost Calculator on WebToolsHub to estimate your monthly spend before committing.

❌ Mistakes I See Beginners Make

1. Skipping /init
Without project initialization, OpenCode is guessing about your codebase. Always run /init first in any new project.

2. Using Llama 3 8B for complex refactors
It will disappoint you. Save Ollama for single-file edits. Use Gemini Pro or Claude Sonnet for anything spanning multiple files.

3. Not reviewing the plan
/plan before every large change. Non-negotiable. Reading the plan takes 30 seconds. Reverting a 20-file refactor takes 30 minutes.

4. Not committing a project-level config
Put .opencode.json in your repo root and commit it. Your team gets consistent model settings automatically.

5. Ignoring session sharing
OpenCode generates shareable links for any session. Massive for async debugging — share the exact session where a bug was introduced.

🔮 What's Coming in OpenCode

The H1 2026 shipping velocity has been impressive:

✅ Background subagents (multiple agents running in parallel)
✅ Scout agent for external research
✅ Desktop app beta (macOS, Windows, Linux)
🔜 Official plugin marketplace
🔜 MCP server support (already in beta)

With 85% of developers using AI tools daily and AI generating ~46% of all new code in 2026, the choice of coding agent matters more than ever. OpenCode's bet on model agnosticism and open-source transparency puts it in a strong position for however the AI landscape evolves from here.

⭐ TL;DR

OpenCode = free, MIT-licensed, terminal-native AI coding agent
Connects to 75+ providers — Claude, GPT, Gemini, Ollama
Native LSP integration for automatic error correction (unique feature)
~78% slower than Claude Code on identical tasks, but cheaper and more private
Best workflow: /init → /plan → execute → /undo if needed
Gemini 2.5 Flash for 80% of tasks, Claude Sonnet 4.6 API for hard TypeScript work

Want free developer tools that work the same way — fully in your browser, no data sent anywhere? Check out WebToolsHub — 100+ free tools for developers including a JSON→TypeScript converter, AI Prompt Optimizer, Cron Job Generator, and more.

All WebToolsHub tools are 100% client-side — nothing is sent to any server.

This article was originally published at webtoolshub.online/blog/opencode-complete-guide-setup-2026

How to Calculate LLM API Cost: Tokens, Pricing & the Formula Every Dev Needs (2026)

Muhammad Awais — Tue, 16 Jun 2026 07:04:22 +0000

A friend of mine deployed a customer support chatbot using GPT-4o. Three days later: $340 in OpenAI charges. He had no idea where it came from. He thought a few thousand API calls would cost maybe $10.

That's the LLM API cost trap — and it gets almost every developer the first time, because nobody actually teaches you the math before you ship.

This article fixes that. We'll cover:

What tokens actually are (the explanation that's actually useful)
Why input and output tokens are priced differently — and why it matters
A side-by-side pricing table for GPT-4o, Claude, Gemini, and others (mid-2026)
The exact formula to estimate your monthly bill before you deploy
5 silent cost killers in production AI apps

🧮 If you just want the number fast: LLM API Cost Calculator — free, no signup, runs in your browser.

What Is a Token? (The Version That Actually Helps)

Every article says "a token is ~4 characters or 0.75 words." Technically true. Practically useless.

Here's what you actually need to know: a token is the smallest chunk of text an LLM processes. The tokenizer splits your text using a vocabulary of ~100,000 patterns. Common words are usually 1 token. Rare or long words split into multiple tokens.

Real examples:

"Hello"              → 1 token
"Hello world"        → 2 tokens
"internationalization" → 4 tokens
{"name": "Muhammad"} → ~7 tokens
A 500-word article   → ~650–700 tokens

Why does this matter for cost? Every API call charges you for:

Every token you send (prompt + conversation history + system prompt)
Every token the model generates back

That friend with the $340 bill? He was passing the full 20-message conversation history on every single turn. By message 20, each API call was using 4,000+ tokens in context before the model even started replying.

Input Tokens vs Output Tokens — The Pricing Split

This is the distinction most developers miss and it costs them the most money.

Providers split pricing into:

Input tokens — everything you send to the model
Output tokens — everything the model generates back

Output tokens are almost always 3–5x more expensive than input tokens. Because generating a token requires the model to run a full forward pass for every single character it produces (autoregressive generation). Reading input is one pass. Writing output is N passes.

Practical impact:

Prompt Style	Input Tokens	Output Tokens	Cost Ratio
"Summarize in 3 bullets"	850	120	Low output cost
"Write a detailed analysis"	850	600	5x more output cost

Same input. Radically different bill. At 10,000 calls/month, that's hundreds of dollars difference from one word in your prompt.

The lever most developers ignore: control output length with max_tokens, not just prompt length.

LLM API Pricing Table — Mid-2026

⚠️ Pricing changes frequently. Always verify at openai.com/api/pricing and anthropic.com/pricing.

Model	Input / 1M tokens	Output / 1M tokens	Context
GPT-4o	$2.50	$10.00	128K
GPT-4o mini	$0.15	$0.60	128K
Claude Sonnet 4	$3.00	$15.00	200K
Claude Haiku 4.5	$0.80	$4.00	200K
Gemini 1.5 Pro	$1.25	$5.00	1M+
Gemini 1.5 Flash	$0.075	$0.30	1M+
Llama 3.3 70B (Groq)	$0.59	$0.79	128K

GPT-4o mini output tokens are 16x cheaper than GPT-4o. For classification, routing, or simple Q&A — this is the switch that changes unit economics entirely.

The Formula

Cost per call =
  (input_tokens  / 1_000_000 × input_rate) +
  (output_tokens / 1_000_000 × output_rate)

Worked example — Document summarizer on Claude Sonnet 4:

Document:      3,000 tokens  (input)
System prompt:   200 tokens  (input)
Summary output:  400 tokens  (output)

Cost per call:
  Input:  (3,200 / 1,000,000) × $3.00  = $0.0096
  Output: (400   / 1,000,000) × $15.00 = $0.0060
  Total:                                  $0.0156

Monthly (5,000 summaries): $78

Now add conversation history — context grows to 8,000 tokens per call → $195/month. Switch to flagship model → $600+. The math compounds fast.

How to Count Tokens Before You Send

Don't guess — count. Here's how for each provider:

OpenAI — tiktoken:

import tiktoken

encoder = tiktoken.encoding_for_model("gpt-4o")
tokens = encoder.encode("Your prompt text here")
print(f"Token count: {len(tokens)}")

Install: pip install tiktoken. Runs locally, no API call needed. Full docs on GitHub.

Claude — token counting endpoint:

// No actual generation — just counts
const response = await anthropic.messages.countTokens({
  model: "claude-sonnet-4-6",
  messages: [{ role: "user", content: yourPrompt }],
})
console.log(response.input_tokens)

See Anthropic's token counting docs for tool use + system prompt edge cases.

Quick estimate (English text only):

Characters ÷ 4 ≈ tokens
Words ÷ 0.75 ≈ tokens
Accuracy drops 20–40% for non-Latin scripts (Arabic, Hindi, Chinese)

5 Mistakes Silently Inflating Your Bill

These show up in almost every AI app I've reviewed. Fix them and you'll typically cut costs 40–60%.

1. Sending Full Conversation History Every Turn

Each turn adds more input tokens. By turn 20 in a chat, you're paying for 19 previous exchanges you already paid for. Implement a sliding window — keep last N turns only, or summarize old context.

2. Bloated System Prompts

A 2,000-token system prompt sent with every call = 100M tokens of overhead per day at 50k requests. Cut ruthlessly. Every sentence needs to earn its place.

3. No `max_tokens` Set

Without a ceiling, the model will be verbose. For classification tasks: 50–100 tokens. For summaries: 200–400 tokens. Always set this.

4. Flagship Model for Everything

Is your email categorization task worth 16x the cost of GPT-4o mini? Route simple tasks to cheaper models. Reserve GPT-4o / Claude Sonnet for tasks that actually need it. Most teams see 60–70% cost reduction from this one change.

5. Not Using Prompt Caching

If you're sending the same large reference document or knowledge base with every request, you're overpaying. Both Anthropic and OpenAI offer prompt caching in 2026. Anthropic's implementation can save up to 90% on cached input tokens.

Real-World Monthly Cost Estimates

App Type	Setup	Monthly Cost
Support chatbot (2k conversations/day)	GPT-4o mini, 8 turns avg	~$18–25
Same chatbot	GPT-4o	~$280–350
Code review assistant (500 PRs)	Claude Sonnet 4	~$23
Doc summarizer (10k docs)	GPT-4o mini	~$18–22
Content generator (1k articles)	GPT-4o	~$263

Pattern: output-heavy tasks + expensive models = highest cost. Build your own estimate with the LLM API Cost Calculator — plug in your numbers and it gives you the monthly projection instantly.

Monitoring in Production

Cost dashboard alone isn't enough — you find out after the damage. Set up:

OpenAI: Hard spend limits + soft alert thresholds in account settings
Anthropic: Usage API for daily spend data + console budget alerts (available 2026)
App-level: Log input_tokens and output_tokens from every API response into your own DB
Per-user limits: Rate limits or credit systems at application layer — don't let a single user's session spike your bill

Treat LLM API cost like database query cost. You wouldn't ship a query without understanding its performance profile.

Quick Reference

Token estimate:     word_count / 0.75  OR  char_count / 4
Cost per call:      (in_tok/1M × in_rate) + (out_tok/1M × out_rate)
Biggest cost lever: max_tokens ceiling + model routing
Best cheap models:  GPT-4o mini ($0.60/1M out), Gemini Flash ($0.30/1M out)
Free calculator:    webtoolshub.online/tools/llm-api-cost-calculator

The math isn't complicated once you know where to look. The $340 chatbot bill wasn't a pricing problem — it was a context management problem. Now you know what to check before you deploy.

What's your biggest AI API cost optimization? Drop it in the comments — always curious what's working for people in production.

How to Decode a JWT Token Online: The Debug Guide Every Developer Needs (2026)

Muhammad Awais — Sat, 13 Jun 2026 17:31:25 +0000

You're staring at a 401 Unauthorized. Your API is rejecting the token. You paste the JWT somewhere and get back a wall of Base64 that means nothing to you.

I've wasted entire afternoons on this. Turns out, reading a JWT takes about 10 seconds once you understand the structure. Let me save you the afternoon.

Canonical source: This article was originally published at WebToolsHub — How to Decode a JWT Token Online. That version includes a live free tool, full code examples, and is kept up to date.

What You'll Learn

The exact 3-part JWT structure and what each part contains
How to decode any JWT in your browser — no install, no account
The 5 JWT errors that waste the most developer time (and how to fix each one)
The localStorage mistake that's killed more auth systems than anything else
HS256 vs RS256 vs ES256 — which one you should actually be using in 2026

Every JWT Is Three Base64 Strings Separated by Two Dots

That's it. The structure is always:

HEADER.PAYLOAD.SIGNATURE

Here's a real one:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsIm5hbWUiOiJBd2FpcyIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcxNjgwMDAwMCwiZXhwIjoxNzE2ODAzNjAwfQ.mK7tqV9ZjX2pL0nW8sRdUeGfHzCvBwQoTlMxYkIjA1c

Paste this into the free JWT Decoder at WebToolsHub and you'll see all three sections decoded instantly. The tool runs 100% in your browser — nothing is sent to any server.

Part 1: The Header

Decode the first segment and you get:

{
  "alg": "HS256",
  "typ": "JWT"
}

alg is the most important field for debugging. It tells you exactly what's needed to verify this token:

Algorithm	Type	Used For
`HS256`	Symmetric (shared secret)	Monoliths, simple APIs
`RS256`	Asymmetric (public/private key)	Microservices, OAuth
`ES256`	Asymmetric (elliptic curve)	High-performance APIs
`none`	No signature	Never accept in production

If you're getting an invalid signature error, this field is where to start. Mismatched algorithm between your issuer and verifier is one of the top causes.

Part 2: The Payload (Claims)

Decode the second segment:

{
  "sub": "user_123",
  "name": "Awais",
  "role": "admin",
  "iat": 1716800000,
  "exp": 1716803600
}

The registered claims you'll see most often:

sub — Subject. Usually the user ID.
iss — Issuer. Usually your API's URL.
aud — Audience. Must match your server's expected value exactly.
exp — Expiration timestamp (Unix). Your server must validate this.
iat — Issued At timestamp.
nbf — Not Before. Token invalid until this time.
jti — JWT ID. Useful for revocation lists.

Critical rule: The payload is Base64URL-encoded, NOT encrypted. Anyone with the token string can decode and read every claim. Never put passwords, credit card numbers, SSNs, or API keys in a JWT payload.

Those exp and iat timestamps are Unix epoch values. When you see "exp": 1716803600 you have no idea if that's past or future. The Unix Timestamp Converter at WebToolsHub converts these instantly. Or in JavaScript:

// Check if token is expired
const isExpired = Date.now() >= payload.exp * 1000;

// Convert to readable date
const expDate = new Date(payload.exp * 1000).toLocaleString();

Multiply by 1000 — JavaScript uses milliseconds, JWT uses seconds. Classic gotcha.

Part 3: The Signature

The signature is created from:

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

If even one character in the header or payload changes, the signature breaks. That's the tamper-proof guarantee. Decoding the signature section tells you nothing useful — but verifying it tells you whether to trust the token.

Decoding ≠ Verifying. Anyone can decode a JWT without a key. Only the party with the correct secret or public key can verify the signature. Always verify on the server before trusting any claims.

The 5 JWT Errors That Waste the Most Time

Error 1: `jwt expired`

Your exp timestamp is in the past. Easy to diagnose — paste the token in the decoder and check the expiry date.

If valid tokens appear expired immediately after creation, you have clock skew. Your issuer and verifier have different system times.

// Add tolerance for clock skew
jwt.verify(token, secret, {
  algorithms: ['HS256'],
  clockTolerance: 60  // 60 seconds leeway
});

Run date -u on both servers. Even 30 seconds difference breaks short-lived tokens.

Error 2: `invalid signature`

Most common causes (ranked by how often I've seen them in the wild):

Different secret between environments — your .env.local secret doesn't match production
Algorithm mismatch — token is HS256, server expects RS256
Base64 encoding issue — secret stored as raw string in one place, Base64-encoded in another
Trailing whitespace/newline in env var — often from copy-pasting into .env files

Fix: Always whitelist algorithms explicitly:

// ✅ Always specify allowed algorithms
jwt.verify(token, process.env.JWT_SECRET, {
  algorithms: ['HS256']
});

// ❌ Never do this — vulnerable to algorithm confusion attacks
jwt.verify(token, process.env.JWT_SECRET);

Error 3: `jwt malformed`

The token doesn't have exactly 3 dot-separated segments. Common causes:

Forgot to strip the Bearer prefix before passing to verify
Token got URL-encoded twice (dots become %2E)
Token was truncated in transit or logging

// ✅ Strip Bearer prefix correctly
const token = req.headers.authorization?.startsWith('Bearer ')
  ? req.headers.authorization.slice(7)
  : null;

Error 4: Claims mismatch (`iss`/`aud` invalid)

Token is valid and not expired — but still rejected. Check the iss and aud claims in the decoder and compare them character-by-character against your server config.

Watch for:

Trailing slash differences (https://api.app.com vs https://api.app.com/)
HTTP vs HTTPS mismatch
Port numbers in one config but not the other

Error 5: `alg:none` attack

Not an error you'll encounter — it's an attack you need to block. Some older JWT libraries accept tokens where "alg": "none" is set in the header. An attacker strips the signature, sets the algorithm to none, and crafts any payload they want.

The fix is the same as Error 2: always whitelist algorithms. Never trust the algorithm value from the token header itself. Modern libraries like jose (used in Next.js Edge Runtime) block this by default.

For Next.js specifically, the article on JWT Authentication with JOSE in the Edge Runtime covers the full setup.

The JWT Security Rules That Actually Matter

Never Store JWTs in localStorage

I know every tutorial from 2020 did this. It's still wrong in 2026.

localStorage is readable by any JavaScript on the page. One XSS vulnerability, one compromised npm package — and every active user's token is gone. I've seen this happen in production.

The correct pattern:

Access token  → Memory only (React state / context). TTL: 5–15 minutes.
Refresh token → HttpOnly, Secure, SameSite=Lax cookie. Not readable by JS.

HttpOnly cookies literally cannot be accessed by JavaScript. That's the point.

For a full breakdown of storage options, the localStorage vs sessionStorage vs Cookies guide covers every tradeoff in detail.

Validate Every Claim on the Server

Verifying the signature is not enough:

function verifyToken(token: string) {
  const payload = jwt.verify(token, process.env.JWT_SECRET!, {
    algorithms: ['HS256'],
    issuer: 'https://api.myapp.com',
    audience: 'myapp-frontend',
  }) as JWTPayload;

  // Explicit expiry check — some libraries skip this by default
  if (payload.exp < Math.floor(Date.now() / 1000)) {
    throw new Error('Token expired');
  }

  return payload;
}

Never silently swallow verification failures. Log the exact error message — it tells you precisely what went wrong.

Keep Access Token TTL Short

15 minutes. A stolen token that expires in 15 minutes is a minor incident. A stolen token that lasts 7 days is a disaster.

HS256 vs RS256 vs ES256 — Quick Decision Guide

Scenario	Use
Single service (issues and verifies tokens itself)	HS256
Multiple services / microservices	RS256
High-throughput API, short key preference	ES256
Starting a new project right now	RS256 — you'll thank yourself later

I've migrated projects from HS256 to RS256 mid-flight. It's painful. If you're starting fresh in 2026, go RS256 from day one.

Verify a JWT Locally with Node.js

When you need this in your terminal during debugging:

import jwt from 'jsonwebtoken';

function verifyToken(token: string) {
  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET!, {
      algorithms: ['HS256'],
    });
    console.log('✅ Valid:', JSON.stringify(decoded, null, 2));
    return decoded;
  } catch (err: any) {
    console.error('❌ Failed:', err.message);
    // "jwt expired" | "invalid signature" | "jwt malformed" | "jwt audience invalid"
    throw err;
  }
}

The error message from jwt.verify() is specific. Use it.

Need a fresh secret? The JWT Secret Key Generator creates cryptographically random secrets — minimum 256 bits for HS256.

Quick Note: JWT vs bcrypt

I see this confusion constantly. They solve different problems:

bcrypt — hashes passwords at registration. You store the hash, never the plain password. At login, compare the submitted password against the stored hash.
JWT — issued after bcrypt verifies the password. Represents the authenticated session.

One comes before the other. The Bcrypt Hash Generator & Verifier lets you test hashing behavior if you're building the full auth flow.

TL;DR

JWT = Header (algorithm) + Payload (claims) + Signature (tamper-proof)
Payload is Base64 encoded, not encrypted — anyone can read it
Always whitelist algorithms explicitly — never trust the alg from the token
Store access tokens in memory, refresh tokens in HttpOnly cookies
Use RS256 for anything beyond a single-service monolith
The 5 errors (expired, invalid signature, malformed, claims mismatch, alg:none) cover 95% of JWT debugging

Free tool: WebToolsHub JWT Decoder & Verifier — paste any JWT, get full decoded output in under 5 seconds. Runs in your browser, nothing sent to any server.

Originally published at webtoolshub.online. Free developer tools including JWT decoder, regex tester, JSON-to-TypeScript converter, and more — no sign-up required.

10 Regex Patterns Every JavaScript Developer Should Know (2026)

Muhammad Awais — Sat, 13 Jun 2026 16:30:58 +0000

You're halfway through building a signup form. Email field. Phone field. Password field.

And suddenly you're Googling "email validation regex javascript" for the 40th time this year — copying a Stack Overflow answer from 2018, crossing your fingers, and moving on.

I've done this. On production projects. That's embarrassing to admit, but it's also why I finally built a proper reference — one I actually understand, not just copy-paste blindly.

These are the 10 regex patterns I reach for constantly in JavaScript projects. Each one is copy-paste ready, explained properly, and tested against real edge cases.

What You'll Learn

10 production-ready regex patterns with copy-paste JS code
What each pattern actually does — no cryptic symbol blindness
Edge cases that will bite you if you skip them
Common mistakes that ship to production every single day

Quick Method Reference

Before the patterns — the three methods you'll use 90% of the time:

/pattern/.test(str)          // → true/false. Use for validation.
str.match(/pattern/g)        // → array of matches. Use for extraction.
str.replace(/pattern/, 'x')  // → new string. Use for sanitization.

That's genuinely all you need. Let's get into the patterns.

1. Email Validation

This is the one everyone needs and everyone gets slightly wrong.

const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

function isValidEmail(email) {
  return emailRegex.test(email.trim());
}

console.log(isValidEmail("user@example.com"));    // ✅ true
console.log(isValidEmail("user+tag@company.co")); // ✅ true — plus sign works
console.log(isValidEmail("notanemail"));           // ❌ false
console.log(isValidEmail("missing@tld"));          // ❌ false

What [^\s@]+ does: Matches one or more characters that are NOT a space or @. Simple, readable, and handles edge cases like plus-sign aliases (user+filter@gmail.com) and long TLDs like .photography — things that trip up overcomplicated RFC-5322 patterns.

⚠️ Important: Regex validates format, not deliverability. It can't tell you if the mailbox actually exists. For that, use a verification API or just send a confirmation email.

2. Password Strength (with Lookaheads)

Most auth systems need: 8+ characters, one uppercase, one lowercase, one digit, one special character. Here's the pattern using lookaheads:

const strongPasswordRegex = /^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[!@#$%^&*()_+\-=\[\]{}|;:,.<>?]).{8,}$/;
const mediumPasswordRegex = /^(?=.*[A-Z])(?=.*\d).{8,}$/;

function checkPasswordStrength(password) {
  if (strongPasswordRegex.test(password)) return "strong";
  if (mediumPasswordRegex.test(password)) return "medium";
  return "weak";
}

console.log(checkPasswordStrength("Passw0rd!"));  // strong
console.log(checkPasswordStrength("Password1"));  // medium
console.log(checkPasswordStrength("password"));   // weak

How lookaheads work: (?=.*[A-Z]) says "look ahead and confirm at least one uppercase letter exists somewhere in the string" — without consuming characters. Each (?=...) is a separate requirement. The final .{8,} enforces minimum length.

⚠️ bcrypt gotcha: bcrypt silently truncates passwords at 72 bytes. If users set 100-character passphrases, only the first 72 characters are actually hashed. Worth mentioning in your security docs.

3. URL Validation

const urlRegex = /^https?:\/\/(www\.)?[-a-zA-Z0-9@:%._+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b([-a-zA-Z0-9()@:%_+.~#?&/=]*)$/;

console.log(urlRegex.test("https://webtoolshub.online"));          // ✅
console.log(urlRegex.test("https://sub.domain.co.uk/path?q=1"));  // ✅
console.log(urlRegex.test("ftp://not-http.com"));                   // ❌
console.log(urlRegex.test("just-text"));                            // ❌

Honest take: For complex URL parsing in production, use the built-in URL constructor — new URL(str) throws if invalid, easier to handle with try/catch. The regex is perfect for quick form validation.

4. Phone Number (International)

Phone numbers are where regex ambitions go to die. No single regex perfectly handles every international format. Here's what I actually use:

// Flexible — strip formatting first, then validate digit count
function isValidPhone(phone) {
  const digitsOnly = phone.replace(/[\s\-().+]/g, "");
  return /^\d{7,15}$/.test(digitsOnly);
}

console.log(isValidPhone("+92 300 1234567"));  // ✅
console.log(isValidPhone("(555) 867-5309"));   // ✅
console.log(isValidPhone("123"));              // ❌

Real talk: Strip non-digits first, count the digits, move on. Users type phone numbers in wildly different formats. This handles 95% of real-world input better than any strict pattern.

5. URL Slug (SEO-Friendly)

Essential for any CMS, blog, or content platform. A slug: lowercase letters, numbers, hyphens only.

const slugRegex = /^[a-z0-9]+(?:-[a-z0-9]+)*$/;

function slugify(text) {
  return text
    .toLowerCase()
    .trim()
    .replace(/[^\w\s-]/g, "")   // remove special chars
    .replace(/[\s_-]+/g, "-")   // spaces/underscores → hyphens
    .replace(/^-+|-+$/g, "");   // trim leading/trailing hyphens
}

console.log(slugify("My Blog Post Title!"));       // "my-blog-post-title"
console.log(slugify("  TypeScript & Next.js  "));  // "typescript-nextjs"
console.log(slugRegex.test("valid-slug-123"));      // ✅
console.log(slugRegex.test("Invalid Slug!"));       // ❌

The slugify function is more useful than just the validation regex — I use it everywhere in Next.js projects when auto-generating routes from titles.

6. Hex Color Code

For color pickers, CSS parsers, and theme generators. Handles 3-digit and 6-digit formats:

const hexColorRegex = /^#([A-Fa-f0-9]{6}|[A-Fa-f0-9]{3})$/;

// With alpha channel (8-digit and 4-digit)
const hexWithAlphaRegex = /^#([A-Fa-f0-9]{8}|[A-Fa-f0-9]{6}|[A-Fa-f0-9]{4}|[A-Fa-f0-9]{3})$/;

console.log(hexColorRegex.test("#fff"));       // ✅
console.log(hexColorRegex.test("#FF5733"));    // ✅
console.log(hexColorRegex.test("FF5733"));     // ❌ — missing #
console.log(hexColorRegex.test("#GGGGGG"));    // ❌ — G isn't hex

7. Date Format (ISO: YYYY-MM-DD)

What every API expects, what databases prefer. This validates format — not date logic:

const isoDateRegex = /^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$/;

// For logic validation, combine with Date constructor
function isValidDate(str) {
  if (!isoDateRegex.test(str)) return false;
  const d = new Date(str);
  return d instanceof Date && !isNaN(d);
}

console.log(isValidDate("2026-06-13")); // ✅
console.log(isValidDate("2026-02-30")); // ❌ — Feb 30 caught by Date constructor
console.log(isValidDate("2026-13-01")); // ❌ — month 13 caught by regex

Always use both: Regex catches format errors; new Date() catches impossible dates like Feb 30.

8. Username Validation

Standard rules: 3-20 characters, letters, numbers, underscores, hyphens — no spaces.

const usernameRegex = /^[a-zA-Z0-9_-]{3,20}$/;

// Stricter — must start with a letter
const strictUsernameRegex = /^[a-zA-Z][a-zA-Z0-9_-]{2,19}$/;

console.log(usernameRegex.test("muhammad_awais")); // ✅
console.log(usernameRegex.test("dev-42"));         // ✅
console.log(usernameRegex.test("ab"));             // ❌ — too short
console.log(usernameRegex.test("has spaces"));     // ❌

Adjust {3,20} to your requirements. The strict version prevents usernames like _admin — cleaner in URLs and @mentions.

9. IPv4 Address (Strict)

Basic patterns let 999.0.0.1 through. This one properly validates each octet (0-255):

const ipv4Regex = /^(25[0-5]|2[0-4]\d|1\d{2}|[1-9]\d|\d)\.(25[0-5]|2[0-4]\d|1\d{2}|[1-9]\d|\d)\.(25[0-5]|2[0-4]\d|1\d{2}|[1-9]\d|\d)\.(25[0-5]|2[0-4]\d|1\d{2}|[1-9]\d|\d)$/;

console.log(ipv4Regex.test("192.168.1.1"));   // ✅
console.log(ipv4Regex.test("255.255.255.0")); // ✅
console.log(ipv4Regex.test("999.0.0.1"));     // ❌
console.log(ipv4Regex.test("192.168.1"));     // ❌

How the octet math works: 25[0-5] → 250-255 | 2[0-4]\d → 200-249 | 1\d{2} → 100-199 | [1-9]\d → 10-99 | \d → 0-9. Always use the strict version — bad IPs cause cryptic downstream errors.

10. Credit Card Format

Format-only validation. For real validation, always combine with the Luhn algorithm:

const creditCardRegex = /^\d{13,19}$/;

const cardTypes = {
  visa:       /^4\d{12}(?:\d{3})?$/,
  mastercard: /^5[1-5]\d{14}$/,
  amex:       /^3[47]\d{13}$/,
  discover:   /^6(?:011|5\d{2})\d{12}$/,
};

function identifyCard(number) {
  const stripped = number.replace(/[\s\-]/g, "");
  if (!creditCardRegex.test(stripped)) return "invalid";
  for (const [type, regex] of Object.entries(cardTypes)) {
    if (regex.test(stripped)) return type;
  }
  return "unknown";
}

console.log(identifyCard("4111 1111 1111 1111")); // visa
console.log(identifyCard("5500 0000 0000 0004")); // mastercard
console.log(identifyCard("1234 5678"));           // invalid

⚠️ Production rule: Use a payment processor (Stripe, etc.) for actual card validation. Never store raw card numbers.

Common Mistakes That Ship to Production

I've made all of these. Some of them twice.

1. Forgetting ^ and $ anchors

Without anchors, your pattern matches anywhere in the string.

// ❌ Wrong — matches "I have 1234 in the middle"
const badPin = /\d{4}/;

// ✅ Correct — only matches exactly 4 digits
const goodPin = /^\d{4}$/;

2. Not escaping the dot

In regex, . means "any character". So example.com as a pattern also matches exampleXcom. Always escape: example\.com.

3. Catastrophic backtracking

Nested quantifiers like /(a+)+/ can hang your regex engine on long strings (ReDoS attack). Avoid nesting + or * inside groups that already have + or *.

4. Missing the i flag for case-insensitive matching

Email addresses are case-insensitive. User@Example.COM is the same mailbox as user@example.com. Use /pattern/i or normalize with .toLowerCase() first.

5. Using regex to parse HTML

Don't. Use DOMParser in the browser or cheerio in Node. Regex and HTML is a well-documented disaster.

Quick Reference Table

Use Case	Pattern	Flag
Email	`^[^\s@]+@[^\s@]+\.[^\s@]+$`	`i`
Strong Password	`^(?=.[a-z])(?=.[A-Z])(?=.\d)(?=.[!@#$%^&*]).{8,}$`	—
URL	`^https?:\/\/(www\.)?[-\w@:%._+~#=]{1,256}\.[a-zA-Z]{1,6}`	`i`
Phone	Strip non-digits → `^\d{7,15}$`	—
URL Slug	`^[a-z0-9]+(?:-[a-z0-9]+)*$`	—
Hex Color	`^#([A-Fa-f0-9]{6}\	[A-Fa-f0-9]{3})$`
ISO Date	`^\d{4}-(0[1-9]\	1[0-2])-(0[1-9]\
Username	{% raw %}`^[a-zA-Z0-9_-]{3,20}$`	—
IPv4	`^(25[0-5]\	2[0-4]\d\
Credit Card	Strip spaces → {% raw %}`^\d{13,19}$`	—

Test These Live

Before you ship any pattern, spend 2 minutes testing it. I use WebToolsHub's free Regex Tester — paste the pattern, add test strings including intentionally bad ones, see matches highlighted in real time. Everything runs in your browser, nothing gets sent to a server.

This two-minute habit has saved me from broken validation in production more times than I want to count.

Want to Go Deeper?

Complete Regex Guide for JavaScript — capture groups, lookaheads, flags, all of it
Next.js Server Actions Security Guide — where these patterns get used in real auth flows
MDN Regular Expressions — the authoritative reference

All tools on WebToolsHub are 100% client-side — no data is sent to any server. Your patterns and test strings stay in your browser.

Stop Guessing EM Values — Here's the Formula Every CSS Dev Needs (+ Free Tool)

Muhammad Awais — Fri, 12 Jun 2026 07:28:21 +0000

You've been there. Figma hands you 24px. Your component has a parent with font-size: 20px. You open some random px-to-em converter, type 24, and it spits out 1.5em.

Wrong. That's calculated against 16px, not your actual parent. You paste it in, something looks slightly off, you squint at it for 10 minutes, and eventually pull up DevTools to figure out what happened.

This post explains why em is context-dependent, how the formula actually works, and walks through the tool I built to fix this exact frustration.

The Formula (And Why It Trips People Up)

The math is simple:

em  = px ÷ parent font-size (px)
px  = em × parent font-size (px)

So 24px with a 16px parent = 1.5em. Clean.

But here's what most tutorials gloss over: em isn't relative to the browser default or the document root — it's relative to the computed font-size of the parent element.

That sounds obvious. But in practice?

html       { font-size: 16px; }
.card      { font-size: 1.25em; }   /* computed: 20px */
.card-body { font-size: 0.9em;  }   /* computed: 18px (20 × 0.9) */
.card-body p { font-size: 0.875em; } /* computed: 15.75px (18 × 0.875) */

Each level multiplies against its parent's computed size. This is called EM compounding, and it's why you sometimes end up with 11px text when you thought you set 0.875em.

The fix is to always check the actual computed font-size in DevTools, not the declared value — and use that as your parent reference when converting.

What Most PX→EM Tools Get Wrong

I tested every tool that shows up on Google for "px to em converter":

Tool	Live Formula?	Configurable Parent?	Bulk Convert?	Tailwind Output?
w3schools reference	❌	❌	❌	❌
nekocalc.com	❌	✅	❌	❌
pixelsconverter.com	❌	✅	❌	❌
giantfocal.com	❌	❌	❌	❌
WebToolsHub	✅	✅	✅	✅

The live formula display is the thing I care about most. When you see 24px ÷ 16px (parent) = 1.5em right there on screen, you understand what's happening — you're not treating the tool as a black box.

The Tool: What It Actually Does

I built this PX to EM converter with the workflow of an actual frontend developer in mind. Here's what makes it different:

1. Bidirectional Conversion with Swap

Toggle between PX → EM and EM → PX. The swap button (⇄) flips direction and moves your current result into the input — useful for chain conversions like "I have 1.5em, what's that in px at 20px parent, then convert that back to em at 14px parent."

2. Live Formula Bar

As you type, you see:

24px ÷ 16px (parent) = 1.5em

No black box. You see the math. You catch mistakes immediately.

3. Configurable Parent Font Size

This is the feature that makes the tool actually correct. Default is 16px, but you can set it to anything. Change it to 20px and your 24px becomes 1.2em — which is the right answer when your parent is 20px.

Every section (main converter, bulk rows, reference table) reacts to this setting instantly.

4. Quick-Copy Property Cards

Four cards appear after conversion:

font-size: 1.5em;   /* click to copy */
margin: 1.5em;      /* click to copy */
padding: 1.5em;     /* click to copy */
gap: 1.5em;         /* click to copy */

The card flashes green on copy. Small thing, but it's faster than manually typing the property name every time.

5. CSS Snippet + Tailwind Arbitrary Value

font-size: 1.5em; /* 24px */

text-[1.5em]   ← Tailwind arbitrary value

The comment preserving the original px value is intentional — keep it in your CSS. Six months later when you're debugging, you'll thank yourself.

6. Bulk Converter

For design systems, I usually need to convert an entire type scale at once:

Input:  16, 20, 24, 32, 48px
Output: 1em, 1.25em, 1.5em, 2em, 3em  (at 16px parent)

Add rows, edit values, hit "Copy All." If you're working with a custom parent, change the parent field and every row updates.

7. 1–100px Reference Table (3 paginated ranges)

Paginated into 1–20px, 21–50px, 51–100px so the page doesn't turn into a massive scroll. Every row has a copy icon. The whole table recalculates when you change the parent font size.

8. EM vs REM vs PX Explainer (Collapsible)

For those moments when you're onboarding a junior dev or just can't remember which unit anchors to root:

Unit	Relative To	Compounds?
`px`	Nothing (absolute)	N/A
`em`	Parent element font-size	✅ Yes
`rem`	Root `html` font-size	❌ No

em vs rem: My Practical Rule

I've settled on this:

rem for type scale and layout. em for component internals.

A button's font-size is 0.875rem (anchored to root, predictable). But its padding is 0.5em 1em — so if you want a "large button" you just change font-size: 1.1rem and the padding scales automatically with it.

That's the real power of em — not typography, but proportional spacing within a component.

Common Mistakes (Real Ones From Real Projects)

Mistake 1: Using default 16px when your parent isn't 16px

Every time you open a converter and just type a number without checking what the actual parent font size is, you might be wrong. 16px is a default, not a constant.

Mistake 2: Using em for font-size in nested components

Three levels of 1.2em = 1.728em effective. This is almost never what you want. Use rem for font sizes.

Mistake 3: Deleting the px comment from your CSS

font-size: 1.5em is meaningless without knowing it came from 24px at 16px parent. Keep the comment. Future you will not remember.

Mistake 4: The 62.5% trick messing up your calculations

Some codebases set html { font-size: 62.5%; } to make 1rem = 10px. If you're working in one of those, your em calculations are also off because parent sizes are now computed differently down the tree.

Try It

→ PX to EM Converter — WebToolsHub

100% client-side. No account. No data sent to a server. Works offline once loaded.

If you also work with rem, I built a PX to REM Converter with the same interface — same live formula, same bulk converter, but anchored to root instead of parent.

Quick Reference Table (16px parent)

px	em	px	em
10px	0.625em	24px	1.5em
12px	0.75em	32px	2em
14px	0.875em	40px	2.5em
16px	1em	48px	3em
18px	1.125em	64px	4em
20px	1.25em	80px	5em

What's your rule of thumb for when to use em vs rem? Drop it in the comments — I'm curious how others think about this.

css #webdev #frontend #tools

Stop Doing px rem Math in Your Head (Here's Why It's Killing Your Flow)

Muhammad Awais — Fri, 12 Jun 2026 04:59:21 +0000

You're 40 minutes deep into a component. Figma says font-size: 24px. You open a calculator, type 24 / 16, get 1.5, switch back to VS Code, type 1.5rem, close the calculator.

Three minutes later you need 36px. Calculator again. 36 / 16... is that 2.25? Let me double check...

Sound familiar? I've been there more times than I can count. And honestly — it's one of those tiny frictions that doesn't feel like a big deal until you realize you've done it 20 times in a single session.

Why We're Still Doing This Manually

The formula is stupid simple:

rem = px ÷ base font size
px  = rem × base font size

With a 16px base (browser default):

24px ÷ 16 = 1.5rem   ✓
36px ÷ 16 = 2.25rem  ✓
14px ÷ 16 = 0.875rem ✓

So yeah, the math isn't hard. The problem is context switching. Every time you leave your editor to calculate something, you're paying a mental overhead cost. Stack that 15–20 times per session and you've lost a solid chunk of deep work time.

The Quick Reference You Actually Need

Here are the values I reach for constantly — with a standard 16px base:

px	rem
10px	0.625rem
12px	0.75rem
14px	0.875rem
16px	1rem
18px	1.125rem
20px	1.25rem
24px	1.5rem
28px	1.75rem
32px	2rem
36px	2.25rem
40px	2.5rem
48px	3rem
56px	3.5rem
64px	4rem
80px	5rem
96px	6rem

Bookmark this section. Seriously.

Wait — Why rem At All?

If you're newer to CSS, you might be wondering why we bother with rem in the first place. Pixels work fine, right?

Here's the thing: px is an absolute unit. When you write font-size: 16px, that's always 16 pixels, regardless of what the user has set in their browser preferences.

rem is relative to the root <html> element's font size — which browsers default to 16px, but users can change. That one difference matters a lot for accessibility.

/* User sets browser font to "Large" (say, 20px) */

p { font-size: 16px; }   /* still renders at 16px — ignores user */
p { font-size: 1rem; }   /* renders at 20px — respects user */

WCAG 2.2 criterion 1.4.4 (Resize Text) requires that users can resize text up to 200% without breaking layout or losing content. rem handles this automatically. px doesn't.

Beyond accessibility, rem makes your spacing system predictable. Change the root font size once — everything scales proportionally.

The `html { font-size: 62.5% }` Trick (And Why It's Outdated)

You've probably seen this pattern in older codebases:

html {
  font-size: 62.5%; /* Makes 1rem = 10px */
}

h1 { font-size: 3.6rem; }  /* = 36px */
p  { font-size: 1.6rem; }  /* = 16px */

The appeal: round numbers. 36px = 3.6rem feels cleaner than 2.25rem.

The problem: setting font-size: 62.5% on html overrides the user's browser preference before anything can respond to it. You're essentially opting out of accessibility at the root level.

Modern best practice is to leave the html font size alone (or use 100%) and let 1rem = user's preference. Then use a converter tool to do the math — not a base-size hack.

Dealing With a Non-Standard Base in Your Project

Not every project uses 16px. You might inherit a codebase with:

html { font-size: 10px; }
/* or */
html { font-size: 18px; }

In these cases the standard conversion tables are wrong. 24px is NOT 1.5rem if your base is 10px — it's 2.4rem.

This is one reason I always use a proper px → rem converter with a configurable base rather than relying on memory or hardcoded tables. When I'm working on a project with a custom root font size, I just update the base field and every value recalculates correctly.

→ Free PX to REM Converter — bidirectional, custom base, bulk conversion

My Actual Workflow: Converting a Full Type Scale

When I'm starting a new design system or setting up typography tokens, I use the bulk converter instead of doing values one by one.

Say your designer gave you this type scale in Figma (all in pixels):

12 / 14 / 16 / 18 / 20 / 24 / 30 / 36 / 48 / 60 / 72

Throw all 11 values into the bulk converter, hit "Copy All", and you get:

12px = 0.75rem
14px = 0.875rem
16px = 1rem
18px = 1.125rem
20px = 1.25rem
24px = 1.5rem
30px = 1.875rem
36px = 2.25rem
48px = 3rem
60px = 3.75rem
72px = 4.5rem

Paste directly into your CSS custom properties or Tailwind config. Done in 30 seconds instead of 5 minutes.

:root {
  --text-xs:   0.75rem;   /* 12px */
  --text-sm:   0.875rem;  /* 14px */
  --text-base: 1rem;      /* 16px */
  --text-lg:   1.125rem;  /* 18px */
  --text-xl:   1.25rem;   /* 20px */
  --text-2xl:  1.5rem;    /* 24px */
  --text-3xl:  1.875rem;  /* 30px */
  --text-4xl:  2.25rem;   /* 36px */
  --text-5xl:  3rem;      /* 48px */
}

rem in Media Queries (The Part Nobody Talks About)

Here's something that trips people up: media queries accept rem too — and it's actually the better choice.

/* Works, but doesn't scale with user font preference */
@media (min-width: 768px) { ... }

/* Scales with user preference */
@media (min-width: 48rem) { ... }

With px breakpoints: if a user bumps their font size to 20px, your layout still breaks at 768 device pixels regardless of their preference.

With rem breakpoints: the breakpoint itself scales. At 20px root, 48rem = 960px — your layout adapts. The user's preference propagates all the way through your responsive design.

Quick conversion for the standard breakpoints:

480px  = 30rem
640px  = 40rem
768px  = 48rem
1024px = 64rem
1280px = 80rem
1440px = 90rem
1536px = 96rem

Tailwind Users: Arbitrary Values + rem

Tailwind's preset scale already uses rem internally — text-base is 1rem, text-xl is 1.25rem, and so on. But when a design spec calls for something off the preset scale, you need arbitrary values:

<h1 class="text-[2.25rem] leading-[2.75rem]">Heading</h1>
<div class="mt-[1.875rem] px-[1.5rem]">Content</div>

The converter I mentioned generates the Tailwind arbitrary value string automatically alongside the standard CSS — so you don't have to manually format it.

If you're on Tailwind v4 and building a custom @theme block, those tokens go in as rem values too:

@theme {
  --font-size-display: 3rem;      /* 48px */
  --font-size-heading: 2.25rem;   /* 36px */
  --spacing-section: 5rem;        /* 80px */
}

PostCSS Automation (For Large Codebases)

If you're migrating a legacy codebase with thousands of px declarations, doing it manually isn't realistic. There's a PostCSS plugin — postcss-pxtorem — that converts px to rem at build time.

npm install postcss-pxtorem --save-dev

// postcss.config.js
module.exports = {
  plugins: {
    'postcss-pxtorem': {
      rootValue: 16,
      propList: ['font-size', 'line-height', 'letter-spacing'],
      // Leave margins/paddings in px if you want
    }
  }
}

You write font-size: 24px in development, it outputs font-size: 1.5rem in production. Same formula this tool uses — just automated.

Be careful with the propList — don't blindly convert everything to rem. Borders, icon sizes, and elements that should never scale usually want to stay in px.

TL;DR

Use rem for font sizes and spacing — it respects user browser preferences and satisfies WCAG
Use px for borders, shadows, and things that genuinely shouldn't scale
rem = px ÷ base font size (default base = 16px)
Don't use the 62.5% html trick on new projects — it's an accessibility anti-pattern
rem works in media queries too — and it's better for accessibility
For bulk conversions or a non-standard base, use a proper tool

→ WebToolsHub — PX to REM Converter (free, bidirectional, bulk)

If you use CSS custom properties for design tokens, our CSS Variables & Dark Mode guide covers how to wire up a full token system in Next.js. And if you're migrating to Tailwind from a pixel-heavy codebase, the CSS to Tailwind converter handles the class-mapping layer.

Tags: css webdev frontend beginners

Google Antigravity IDE 2.0 Broke My Next.js Setup — Here's How I Fixed It (And Whether It's Worth Using)

Muhammad Awais — Thu, 11 Jun 2026 08:43:20 +0000

On May 20, 2026, I opened my project in Antigravity IDE and found something unexpected. My terminal was gone. The error indicators had disappeared. The familiar VS Code-style interface was replaced with a chat panel and a "Manager View" I hadn't asked for.

Google had auto-updated Antigravity to 2.0 overnight — without warning — and broken the workflow I'd spent three months building.

I spent the next few hours figuring out what changed and how to get back to productive work. This is everything I learned.

What Antigravity 2.0 Actually Is

Most developers think Antigravity 2.0 is just an updated AI editor. It's not.

Announced at Google I/O on May 19, 2026, it's now a five-surface agent orchestration platform:

Desktop App — the new default, rebuilt from scratch
Antigravity CLI — replaces Gemini CLI on June 18, 2026
SDK — for embedding agents in your own tools
Managed Agents API — hosted agent infrastructure inside Gemini API
Enterprise Agent Platform — Google Cloud integration layer

The original VS Code-based IDE still exists but you have to download it separately now. This is why thousands of devs woke up to broken setups — the auto-update installed 2.0 and removed the traditional IDE as the primary surface without any migration path.

If you're currently dealing with a blank screen or broken terminal after the update, I wrote a separate Antigravity IDE blank screen fix guide that covers the most common post-update issues step by step.

Manager View vs Editor View — The Key Mental Shift

The biggest adjustment in 2.0 is the interface split.

Manager View (new default) is a mission control dashboard. You describe a task in natural language, Antigravity dispatches agents to plan and execute, and you get review checkpoints before anything gets written to disk.

Editor View is the direct coding surface — closer to Antigravity 1.x. You access it from Manager View or the Editor tab.

The mental shift: you're no longer typing code with AI assistance. You're directing agents who write code on your behalf.

For repetitive scaffolding tasks this is faster. For precise, nuanced edits where you know exactly what you want — Editor View or Claude Code is more efficient.

Setting Up AGENTS.md for Next.js (The Most Important Step)

The single most important config step is your AGENTS.md file. Without it, agents default to generic Next.js conventions that probably don't match your project.

Here's what works well for a Next.js 15 App Router project:

# My Project (Next.js 15 App Router)

## Stack
Next.js 15.3 App Router, TypeScript 5.9 strict, Tailwind CSS v4,
MongoDB with Mongoose, deployed on Vercel

## Commands
- Dev: `npm run dev`
- Type check: `npm run typecheck`
- Lint: `npm run lint`
- Build: `npm run build`

## Conventions
- Named exports only, never default exports
- Server components by default, `'use client'` only when necessary
- TypeScript strict mode — no `any` types
- Tailwind utility classes only, no inline styles
- `@/` alias for all internal imports

## Boundaries
### Ask before doing
- Changes to `/src/models/` — schema changes affect all data
- New npm dependencies

### Never do
- Add TypeScript `any`
- Direct database edits
- Modify `.env.local` values in code

For a deeper dive, the complete AGENTS.md guide for Next.js has copy-paste templates for all five sections.

Running a Multi-Agent Mission (Real Example)

This is where Antigravity 2.0 genuinely shines. Here's a real mission I ran on my project:

Mission: "Add a new blog category called 'Tools' with its own
listing page, update the navigation, and add a category filter
to the existing blog listing page."

Without Antigravity, this is a 45-minute task across four files. With a well-scoped mission, Antigravity dispatches:

A planning agent that maps required changes across your codebase
A UI agent handling navigation update and filter component
A routing agent creating the new category page and dynamic route
A verification agent running your type checker and linter after each change

The checkpoint system is what makes this not "vibe coding." Before the agent writes to any file, it shows you a plan — what it intends to change and why. You approve, redirect, or reject before execution.

Tip: Keep missions scoped. "Add a blog category with listing page" = good mission. "Refactor the entire blog system" = too broad, parallel agents start touching overlapping files.

Antigravity 2.0 vs Cursor vs Claude Code — Honest Verdict

I use all three. Here's where each actually wins for Next.js:

Daily coding work

Cursor wins. Faster completions, more fluid chat, VS Code compatibility means your extensions and muscle memory work. Cursor has 18 months more polish on its editor experience.

Multi-file agentic tasks

Antigravity wins on parallel execution. For tasks spanning 5+ files with a clear spec, Manager View is genuinely faster. For accuracy on complex tasks, Claude Code still has the higher SWE-Bench score but runs sequentially.

Cost

Antigravity wins on free tier. Free includes Gemini 3.5 Flash, Claude Sonnet 4.6, and GPT-OSS 120B with rotating rate limits. Cursor's free tier is far more restricted.

Next.js App Router specifically

Claude Code + Cursor is still the strongest combo. Claude Code's understanding of App Router conventions, server components, and server actions is consistently more accurate than Gemini 3.5. For a TypeScript-heavy Next.js codebase, this matters a lot.

Want the full breakdown of all the 2026 AI coding tools? The complete comparison of Claude Code vs Cursor vs GitHub Copilot has benchmark scores and workflow recommendations.

Pricing (June 2026)

Tier	Models	Price
Free	Gemini 3.5 Flash, Claude Sonnet 4.6, GPT-OSS 120B	$0
Individual	+ Gemini 3.1 Pro, Claude Opus 4.8, background tasks	~$19/mo
Credit packs	Burst usage without subscription	Pay as you go

My recommendation: Start with the free tier for two weeks on your actual project before paying. The rate limits are annoying but sufficient for evaluating fit. Use the LLM API Cost Calculator to compare credit-pack costs vs direct API usage.

Known Issues Right Now (June 2026)

Terminal missing after update — The terminal panel was removed in 2.0. Use Editor View or run a separate terminal window. The post-update fix guide has recovery steps.

Context window lag — Long sessions accumulate history and slow the UI. Fix: restart session every 45-60 minutes. AGENTS.md reloads automatically.

Gemini CLI shutdown on June 18 — If you're using Gemini CLI, migrate to Antigravity CLI before the cutoff. Commands map directly, same functionality under the agy prefix.

No MCP support — Unlike Claude Code and GitHub Copilot Agent Mode, Antigravity 2.0 has no MCP server support. If your workflow uses MCP integrations (Stripe, Figma, databases), you'll need a different tool for those tasks.

Parallel agents overlapping files — In multi-agent missions, agents occasionally try to edit the same files and create conflicts. Keep mission scope tight — one feature area per mission.

Should You Switch from Cursor?

No, not as a full replacement. But as a complementary tool for specific tasks — yes.

The workflow I'm running right now: Antigravity 2.0 for scaffolding new pages, Cursor for component refinement, Claude Code for complex server actions and data layer work. Each one is clearly better at its lane, and a shared AGENTS.md means all three agents understand my project conventions from the first prompt.

If you're evaluating the full 2026 AI coding landscape, also check out the AWS Kiro IDE comparison and the Google I/O 2026 developer announcements for more context on where these tools are heading.

What's your setup right now? Still on Cursor, trying Antigravity, or using something else entirely? Drop it in the comments.

AGENTS.md: The One File That Makes AI Coding Agents Actually Understand Your Next.js Project

Muhammad Awais — Thu, 11 Jun 2026 07:38:59 +0000

You've been here. You open Claude Code, assign it a task — "add validation to the signup form" — and it comes back with a technically correct solution that uses the wrong validation library, breaks three of your naming conventions, and imports from a module you deprecated six months ago.

The fix isn't a better prompt. It's AGENTS.md.

One file at your repo root. Every AI coding agent reads it at session start. Projects with a properly written one average 35–55% fewer agent-generated bugs — and that number tracks with what I've seen in practice.

Here's everything you need to know, with copy-paste Next.js templates.

What AGENTS.md Actually Is

Plain Markdown. No YAML frontmatter. No special syntax. Just headings and bullet points that tell a coding agent:

What your stack is (exact versions)
Which commands to run
What conventions to follow
What to never touch

It lives at your repo root — same level as package.json. Every major AI coding tool reads it as of 2026:

Tool	Support
Claude Code	✅ Native (priority over CLAUDE.md)
GitHub Copilot Agent Mode	✅ Full (Agent HQ shared context)
Cursor	✅ Priority over .cursorrules
OpenAI Codex (Agent HQ)	✅ Full
Windsurf	⚠️ Partial

Why It Replaced .cursorrules and CLAUDE.md

Before AGENTS.md, you maintained a different file per tool:

.cursorrules                          ← Cursor
CLAUDE.md                             ← Claude Code
.github/copilot-instructions.md       ← Copilot
GEMINI.md                             ← Gemini

Every tool switch meant duplicating content. Instructions drifted. New teammates had to hunt for "the real rules."

AGENTS.md is the cross-tool standard — one file, every agent. You can keep your old files for backwards compatibility (tools still read them), but AGENTS.md takes priority when both exist.

The Minimal Structure That Actually Moves the Needle

# Project Name

## Stack
Next.js 15.3 App Router, TypeScript 5.9 strict, Tailwind CSS v4,
Prisma 6.x, PostgreSQL, Zod 3.x, NextAuth v5

## Commands
- Dev: `npm run dev`
- Type check: `npm run typecheck`
- Lint: `npm run lint`
- Test: `npm run test`
- Build: `npm run build`

## Conventions
- Named exports only — never default exports
- Server components by default, `'use client'` only when hooks/browser APIs needed
- Zod for all validation — never manual type guards
- `@/` alias for all internal imports

## Boundaries
### Ask before doing
- Changes to `prisma/schema.prisma`
- New npm dependencies
- `next.config.ts` changes

### Never do
- Add TypeScript `any`
- Modify `/lib/legacy/` — deprecated
- Use `localStorage` directly — use `/lib/storage/client.ts` wrapper

Under 60 lines. Prevents the most common class of AI agent failures.

The Five Sections That Matter

1. Stack — Be Specific About Versions

Next.js 15 App Router behaves completely differently from Next.js 14. An agent that doesn't know which you're on will generate server action syntax that doesn't compile.

## Stack
Next.js 15.3 App Router, TypeScript 5.9 (strict mode), Tailwind CSS v4,
Prisma 6.x with PostgreSQL, Zod 3.x, NextAuth v5, Vitest, Playwright,
deployed on Vercel

2. Commands — Exact Executables With Flags

Agents use these to verify their own work. They run your type checker and linter after making changes. If you don't provide exact commands, they guess — and guesses fail on custom setups.

## Commands
- Install: `npm install`
- Dev server: `npm run dev` (port 3000)
- Type check: `npm run typecheck` (tsc --noEmit)
- Lint: `npm run lint` (eslint + prettier check)
- Format: `npm run format`
- Test (unit): `npm run test`
- Test (e2e): `npm run test:e2e`
- Build: `npm run build`
- DB sync (dev only): `npx prisma db push`
- DB migrate: `npx prisma migrate dev --name <description>`

3. Conventions — Specific Rules, Not Generic Advice

"Write clean code" means nothing. "Named exports only" is a rule an agent can follow.

## Conventions
- Named exports only: `export function Foo()`, never `export default`
- Server components by default — add `'use client'` only for hooks/browser APIs
- Server actions in `/app/actions/` — one file per domain (auth.ts, user.ts)
- API routes in `/app/api/` — REST conventions
- Zod schema for every form and API input — no manual `as Type` assertions
- shadcn/ui components from `/components/ui/` only — extend with wrappers,
  never modify the source files
- DB queries only in `/lib/db/` — never inline in components or server actions
- Error boundaries at route segment level

4. Boundaries — Three Tiers

## Boundaries

### Ask before doing
- `prisma/schema.prisma` changes — migrations are version-controlled
- New npm dependencies — check if existing package covers the need
- `next.config.ts` changes — affects entire build
- Architectural changes across multiple modules

### Never do
- Add TypeScript `any` — fix the type or ask for help
- Import from `/lib/legacy/` — being phased out, do not touch
- Use `localStorage` or `sessionStorage` directly — use `/lib/storage/client.ts`
- Hardcode env values — validate everything through `/lib/env.ts`
- Modify `/components/ui/` files — these are shadcn sources, use wrappers

5. Testing — Framework + What Not to Mock

## Testing
- Framework: Vitest + @testing-library/react
- Unit: `/tests/unit/` — pure functions only
- Integration: `/tests/integration/` — full server actions, real DB,
  transactions roll back after each test
- E2E: Playwright in `/tests/e2e/`
- Never mock Prisma — use test DB with rollback transactions
- Mock external APIs with MSW (Mock Service Worker)
- Coverage: 80% for /lib/, 60% for /app/
- Always run `npm run typecheck && npm run lint && npm run test` before done

Complete Next.js App Router Template (Copy This)

# My Next.js App

## Stack
Next.js 15.3 App Router, TypeScript 5.9 strict, Tailwind CSS v4,
Prisma 6.x, PostgreSQL, NextAuth v5, Zod 3.x, Vitest, Playwright

## Project Structure
- `/app/` — Pages, layouts, route handlers
- `/app/actions/` — Server actions (one file per domain)
- `/app/api/` — REST API routes
- `/components/ui/` — shadcn/ui (do not modify)
- `/components/` — Custom components
- `/lib/` — Shared utilities
- `/lib/db/` — All Prisma queries live here only
- `/lib/env.ts` — Zod-validated env variables
- `/tests/` — unit/, integration/, e2e/

## Commands
- Dev: `npm run dev`
- Type check: `npm run typecheck`
- Lint: `npm run lint`
- Test: `npm run test`
- Build: `npm run build`
- DB push (dev): `npx prisma db push`
- DB migrate: `npx prisma migrate dev --name <description>`

## Conventions
- Named exports only, never default exports
- Server components by default, `'use client'` only when necessary
- All input validated with Zod before processing
- `@/` alias for all internal imports
- PascalCase for component files, camelCase for utility files
- No inline styles — Tailwind utility classes only

## Boundaries

### Ask before doing
- `prisma/schema.prisma` changes
- New npm dependencies
- `next.config.ts` changes

### Never do
- Add `any` type — fix it properly
- Touch `/lib/legacy/` — deprecated
- Use `localStorage` directly — use `/lib/storage/client.ts`
- Hardcode env values — use `/lib/env.ts`
- Modify `/components/ui/` — wrap instead

## Testing
- Vitest for unit + integration tests
- Playwright for E2E
- Never mock Prisma — use test DB with rollbacks
- MSW for external API mocking
- Run typecheck + lint + test before marking any task done

Monorepo Setup — Running Multiple Agents in Parallel

GitHub Agent HQ lets you run Claude, Codex, and Copilot simultaneously. Without scoped AGENTS.md files, two agents will edit the same file and create conflicts.

project/
├── AGENTS.md              # Shared: git conventions, CI commands, global rules
├── apps/
│   ├── web/
│   │   └── AGENTS.md      # "Frontend only. Don't touch /api/ or /packages/"
│   └── api/
│       └── AGENTS.md      # "API routes only. Don't touch /web/"
└── packages/
    └── ui/
        └── AGENTS.md      # "UI library only. No business logic here."

The agent reads the root file first (shared context), then the nearest scoped file (domain-specific rules). Root-level context + scoped boundaries = no cross-domain conflicts.

AGENTS.md vs CLAUDE.md vs .cursorrules — Migration Guide

If you're already using one of the older formats:

From .cursorrules:
Copy your content into AGENTS.md. Restructure into the five sections above. Delete .cursorrules or leave it — Cursor will ignore it once AGENTS.md exists.

From CLAUDE.md:
Keep CLAUDE.md if you want (Claude Code reads both). But put your main content in AGENTS.md and make CLAUDE.md a one-liner: @AGENTS.md — this tells Claude Code to read the shared file.

From copilot-instructions.md:
Keep it for non-Agent HQ Copilot workflows. Migrate your core content to AGENTS.md. Agent HQ sessions use AGENTS.md as the primary context.

The Biggest Mistakes (And How to Avoid Them)

Writing prose instead of rules
❌ "Follow best practices for error handling"
✅ "Throw typed errors in server actions, catch at the route segment error boundary"

Listing every possible command
Only include commands the agent actually uses during normal work. A 40-command list means the agent has to parse it every session — wasted context tokens.

Not updating it when the stack changes
An AGENTS.md that says "use Prisma 5" when you're on Prisma 6 will make the agent generate deprecated syntax confidently. Treat it like code — update it in the same PR that changes the dependency.

Making it too long
Under 150 lines is the target. If you're writing paragraphs, you've crossed from agent instructions into human documentation. Move that content to README.md.

Verify Your Setup

After writing your AGENTS.md, run this quick check with Claude Code or Cursor:

"Read my AGENTS.md and tell me: 
1. What command do you use to run tests?
2. Where do database queries live?  
3. What should you never modify without asking?
4. What validation library do you use?"

If the agent answers correctly from the file — you're done. If it gets any wrong — that section needs more clarity.

Tools That Work Well Alongside AGENTS.md

If you're building agentic workflows that go beyond single-file edits, here are two things worth setting up alongside your AGENTS.md:

MCP (Model Context Protocol) — connects Claude Code and other agents to external tools, databases, and APIs. Your AGENTS.md defines the project conventions; MCP gives agents the tools to act on them. The MCP complete guide on WebToolsHub covers setup from scratch.

Claude Code agent workflows — for multi-step autonomous tasks that go beyond what Copilot handles inline. The Claude Code skills guide covers how to structure long-running agent sessions so they stay aligned with your conventions — which is exactly what a good AGENTS.md enables.

For the broader picture of how AGENTS.md fits into a full agentic development workflow — task assignment, parallel agents, review loops — the agentic AI workflows guide on WebToolsHub covers the architecture end to end.

Quick Reference

AGENTS.md checklist:
✅ Stack section with exact versions
✅ Commands section with exact flags (not descriptions)
✅ Conventions: specific rules, not generic advice
✅ Boundaries: Ask / Never do tiers
✅ Testing: framework + what NOT to mock
✅ Under 150 lines total
✅ Committed to version control
✅ Updated in same PR as stack changes

That's the file. One-time 20-minute investment. Every agent that touches your project from now on starts with full project context.

Full guide with FAQ, Claude Fable 5 integration notes, and advanced monorepo patterns on WebToolsHub.

Stop Running Unvalidated SQL Against Production Use a Free Browser-Based Validator Instead

Muhammad Awais — Thu, 11 Jun 2026 03:47:14 +0000

Let me describe a workflow I've watched countless developers use - including myself, more times than I want to admit.

Write a SQL query in your editor
Eyeball it once
Copy-paste it directly into a production database client
Hit execute
Wait
Either relief or regret

If you've never felt the specific stomach-drop of watching a DELETE run without a WHERE clause, consider yourself lucky. It's an experience that tends to permanently change your habits — but ideally that change happens before the incident, not after.

This post is about building better SQL validation habits, understanding dialect differences that cause silent bugs, and introducing a free tool I built specifically for this problem.

The Validation Gap in Most Dev Workflows

Most modern development workflows have decent safety nets:

TypeScript catches type errors at compile time
ESLint flags code quality issues before you commit
Jest/Vitest runs tests before your CI pipeline deploys
Zod validates API payloads at runtime

But SQL? SQL often gets none of this. You write it, you read it once, and you run it. The "test environment" is frequently just production with a slightly nervous attitude.

This is particularly ironic because SQL errors are often more consequential than application code errors. A runtime error in your React component shows a broken UI. A malformed UPDATE with the wrong WHERE clause modifies data that you may never be able to fully recover.

The Tool: SQL Query Validator on WebToolsHub

I built the SQL Query Validator to close this gap. It's free, browser-based, and runs 100% client-side — your queries never leave your machine.

Here's what it does:

✅ Validates SQL syntax against your chosen dialect
✅ Shows errors with exact line numbers and plain-English messages
✅ Formats queries in one step (Format + Validate)
✅ Supports MySQL, PostgreSQL, SQLite, SQL Server
✅ No account, no signup, no server

Let me walk through the things that actually matter when using it.

Dialect Selection: The Step Everyone Skips

The most important thing to get right before validating is selecting the correct SQL dialect. This isn't optional — it fundamentally changes what's valid.

MySQL vs PostgreSQL: The Most Common Confusion

If you work across projects, you've probably written MySQL syntax in a PostgreSQL project (or vice versa) at least once. The errors are subtle:

-- ✅ Valid MySQL
SELECT * FROM products 
WHERE name LIKE '%keyboard%';

-- ✅ Valid PostgreSQL (case-insensitive version)
SELECT * FROM products 
WHERE name ILIKE '%keyboard%';

-- ❌ ILIKE doesn't exist in MySQL — silent failure or error

-- ✅ Valid MySQL
CREATE TABLE users (
  id INT AUTO_INCREMENT PRIMARY KEY,
  email VARCHAR(255)
);

-- ✅ Valid PostgreSQL equivalent
CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  email VARCHAR(255)
);

-- ❌ AUTO_INCREMENT in PostgreSQL → syntax error

When you select PostgreSQL in the validator and paste MySQL syntax, these are caught immediately with a clear error message — before you touch a real database.

SQL Server (T-SQL): A Different World

T-SQL has its own quirks that catch MySQL/PostgreSQL developers off guard:

-- ✅ SQL Server pagination
SELECT TOP 10 * FROM orders
ORDER BY created_at DESC;

-- ❌ TOP doesn't exist in MySQL or PostgreSQL
-- They use LIMIT instead

-- ✅ SQL Server OFFSET pagination (SQL Server 2012+)
SELECT * FROM orders
ORDER BY created_at DESC
OFFSET 0 ROWS FETCH NEXT 10 ROWS ONLY;

-- ✅ SQL Server string search
SELECT * FROM users 
WHERE CHARINDEX('@gmail.com', email) > 0;

-- ✅ PostgreSQL equivalent
SELECT * FROM users 
WHERE STRPOS(email, '@gmail.com') > 0;

-- These are NOT interchangeable

Selecting the right dialect in the validator means each of these is caught before you push code.

The Format + Validate Workflow

One of the most useful features is the Format + Validate button — it reformats your query and validates it in a single click.

Here's a realistic example of a query written in a hurry:

select u.id,u.name,u.email,o.id as order_id,o.total,o.status from users u left join orders o on u.id=o.user_id where o.status='pending' and o.total>50 order by o.total desc limit 20

After Format + Validate:

SELECT
    u.id
  , u.name
  , u.email
  , o.id AS order_id
  , o.total
  , o.status
FROM users u
LEFT JOIN orders o
  ON u.id = o.user_id
WHERE o.status = 'pending'
  AND o.total > 50
ORDER BY o.total DESC
LIMIT 20

Same query. Immediately readable. And confirmed valid MySQL syntax.

The formatting rules follow conventions that keep Git diffs clean — leading commas mean adding a column to the SELECT list touches one line, not two.

Common Syntax Errors the Validator Catches

These are the errors that waste the most developer time because they're subtle and easy to miss in a code review:

1. Wrong Clause Order

SQL has a mandatory clause order. This is wrong:

SELECT id, name, COUNT(orders.id) as order_count
FROM users
GROUP BY users.id
WHERE users.active = 1  -- ❌ WHERE must come before GROUP BY
HAVING order_count > 5;

Correct:

SELECT id, name, COUNT(orders.id) as order_count
FROM users
WHERE users.active = 1  -- ✅ WHERE before GROUP BY
GROUP BY users.id
HAVING order_count > 5;

The validator flags the first version immediately: "Unexpected WHERE after GROUP BY — WHERE clause must precede GROUP BY."

2. Unmatched Parentheses in Subqueries

SELECT * FROM orders
WHERE user_id IN (
  SELECT id FROM users
  WHERE created_at > (
    SELECT MIN(created_at) FROM users
    WHERE country = 'PK'
  -- ❌ Missing closing parenthesis for the IN subquery
);

In a long query, this is genuinely hard to spot manually. The database error message usually points to the end of the file, not the opening parenthesis. The validator shows the exact line.

3. Missing Table Alias on Ambiguous Columns

SELECT id, name, total  -- ❌ ambiguous: which table's 'id'?
FROM users
JOIN orders ON users.id = orders.user_id;

When both tables have an id column, this is ambiguous. Should be:

SELECT users.id, users.name, orders.total
FROM users
JOIN orders ON users.id = orders.user_id;

4. Dialect-Specific Function Names

-- ❌ NVL doesn't exist in PostgreSQL or MySQL
SELECT NVL(phone, 'N/A') FROM users;

-- ✅ Use COALESCE (works in all four dialects)
SELECT COALESCE(phone, 'N/A') FROM users;

Integrating SQL Validation Into Your Actual Workflow

A tool only helps if you actually use it. Here's how I've integrated this into my day-to-day:

Before running any migration: Every migration script gets pasted into the validator before it runs. This takes 30 seconds and has saved me multiple times. The Cron Job Generator on the same site is useful when those migrations are triggered by scheduled jobs.

During code review: Instead of just reading SQL queries in a PR, I paste each one into the validator. It takes 10 seconds per query and catches things your eyes miss after the third read.

When switching dialects: Any time I port a query from one database to another, I change the dialect selector and re-validate. Catches AUTO_INCREMENT vs SERIAL type issues immediately.

For learning: If you're newer to SQL, the error messages are written to explain what is wrong and why — not just throw a code at you. Write a query, see what's wrong, fix it, understand it. Faster feedback loop than spinning up a local database.

The Privacy Argument for Client-Side Tools

Most online SQL formatters and validators send your queries to a backend server. I'd argue this is a problem people underestimate.

Your SQL queries contain:

Table and column names (schema information)
Sample data values embedded in WHERE clauses
JOIN conditions that reveal data relationships
Business logic embedded in complex queries

Pasting production schema information into a third-party server-side tool is a real data governance question — especially if you're under any kind of compliance requirement (GDPR, SOC 2, HIPAA adjacent work).

With a client-side validator, the answer to that question is simple: the data never leaves your browser. No logs, no storage, no backend.

If you're interested in the architecture behind building client-side tools like this, there's a detailed breakdown on WebToolsHub: Why client-side processing is the right model for developer tools.

Quick Reference: Dialect Differences Cheat Sheet

Bookmark this:

Feature	MySQL	PostgreSQL	SQLite	SQL Server
Auto-increment	`AUTO_INCREMENT`	`SERIAL` / `GENERATED ALWAYS AS IDENTITY`	`INTEGER PRIMARY KEY`	`IDENTITY(1,1)`
Pagination	`LIMIT x OFFSET y`	`LIMIT x OFFSET y`	`LIMIT x OFFSET y`	`TOP n` / `OFFSET FETCH`
Case-insensitive search	`LIKE` (default)	`ILIKE`	`LIKE` + PRAGMA	`LIKE` (default)
String position	`LOCATE()`	`STRPOS()`	`INSTR()`	`CHARINDEX()`
Current time	`NOW()`	`NOW()` / `CURRENT_TIMESTAMP`	`datetime('now')`	`GETDATE()`
Identifier quoting	Backticks	Double quotes	Both	Square brackets
Boolean type	`TINYINT(1)`	`BOOLEAN`	`INTEGER`	`BIT`

If you're building regex patterns for REGEXP or SIMILAR TO clauses, the Regex Tester on WebToolsHub lets you test the pattern in isolation before embedding it in SQL.

What I'm Working on Next

The SQL Query Validator is live now at webtoolshub.online/tools/sql-query-validator.

Coming next:

Schema-aware validation — paste CREATE TABLE statements alongside your query to catch column-name typos before runtime
Open Graph Preview Tool — because broken social share cards are the other category of "should have caught this before deploying"

If you found this useful, the WebToolsHub blog also covers the full cron job syntax guide for 2026 — useful if your SQL runs in scheduled jobs — and there's a solid breakdown of TypeScript mistakes that kill Next.js performance if that's your stack.

Try It

🔗 SQL Query Validator — Free, browser-based, no signup

What's your current SQL validation workflow? Drop it in the comments — I'm genuinely curious whether anyone has a better system than "paste and pray."

AWS Kiro IDE: Amazon's Spec-Driven AI Coding Tool Explained (2026 Review)

Muhammad Awais — Wed, 10 Jun 2026 06:51:38 +0000

Amazon made a quiet but significant move on May 7, 2026: Amazon Q Developer was officially retired and replaced with AWS Kiro — a fundamentally different take on AI-assisted development.

I spent the first week using Kiro on real production work. This is what I found.

TL;DR

Kiro = Amazon's new AI IDE, replaces Q Developer entirely
Core idea: spec-driven development — AI writes specs before writing code
Free tier + $20/mo Pro (same price as Cursor)
Best for: AWS teams, complex feature development, GovCloud compliance
Not ideal for: JetBrains/VS users, pure speed-focused workflows, non-AWS stacks

The Core Concept: Spec-Driven Development

Every other AI coding tool follows the same basic loop: prompt → code → review → iterate.

Kiro breaks that loop. Instead:

You describe what you want to build in natural language
Kiro generates a structured specification — user stories, data models, API contracts, edge cases, dependency list
You review, edit, and approve the spec
Only then does code generation begin

The first time I saw this I thought "extra friction." Then I caught an authentication edge case at the spec stage that would have been a subtle production bug two weeks later. That changed my opinion fast.

// Traditional AI flow:
prompt("Add JWT auth with refresh tokens") → code → discover edge cases → rework → ...

// Kiro Spec Mode flow:
describe("Add JWT auth with refresh tokens")
→ Kiro generates spec with user stories, data models, error scenarios
→ you spot the edge case in the spec
→ approve → clean code on first generation

Q Developer Migration Timeline

If you're still on Q Developer, here's what matters:

Date	Event
May 7, 2026	Kiro launches, Q Developer retired
May 15, 2026	New Q Developer sign-ups blocked
May 29, 2026	Latest models (Claude Opus 4.7+) exclusive to Kiro
April 30, 2027	Q Developer Pro end of support

The real problem with staying on Q Developer isn't the deadline — it's that you're locked to an older model stack right now. That gap widens every month.

Kiro's Two Modes Explained

Spec Mode ($0.20/credit)

For complex features. Full spec generation before any code is written. Catches ambiguities at planning stage, not debugging stage.

When to use: New features, architectural changes, anything where rework is expensive.

Vibe Mode ($0.04/credit)

Traditional AI coding flow — prompt, code, iterate. Fast, no overhead.

When to use: Quick scripts, prototypes, simple tasks, anything you'd normally tab-complete your way through.

Most developers split roughly 60% Spec / 40% Vibe once they get comfortable with both modes.

Kiro vs Cursor vs GitHub Copilot

I've written a full Cursor vs Windsurf vs GitHub Copilot comparison if you want the deep dive, but here's the Kiro-specific breakdown:

Feature	AWS Kiro	Cursor	GitHub Copilot
Type	Standalone IDE	VS Code fork	Extension
Philosophy	Spec-first	Code-first	AI-assisted
Price	Free + $20/mo	Free + $20/mo	$10/mo
Tab Completion	⚠️ Slower	✅ Best-in-class	✅ Fast
Complex Features	✅ Spec mode	✅ Composer	⚠️ Context limits
AWS Native	✅ Yes	❌ No	⚠️ GitHub only
Open Source	✅ Yes	❌ No	❌ No
GovCloud	✅ Yes	❌ No	❌ No

The honest version: Cursor wins on tab completion speed — Kiro's own supporters admit this. But for complex AWS feature work, Kiro's spec workflow saves time Cursor can't match.

The emerging pattern in 2026: Cursor for daily editing, Kiro for complex features, Claude Code for deep terminal reasoning. Not replacement — specialization. More on how these tools relate in my Claude Code vs Cursor vs GitHub Copilot 2026 breakdown.

Pricing — Is the Free Tier Enough?

Free tier: Enough for genuine evaluation. Not unlimited, but enough to know if the workflow fits.

Pro ($20/month): ~225 vibe-mode + 125 spec-mode requests/month.

That's fewer raw requests than Q Developer's ~1,000/month at the same price. But the math works differently: one spec-mode session building a complex feature can replace 15–20 vibe-mode iterations. Quality per credit is higher, raw volume is lower.

For enterprise: GovCloud support is a genuine differentiator. If your org has compliance requirements that block standard cloud tools, Kiro clears that bar. Cursor and Copilot don't.

Agent Hooks — Kiro's Most Underrated Feature

Agent Hooks let you define automation triggers inside your development workflow:

# Example: auto type-check on save
on_save:
  - run: tsc --noEmit
  - notify: "Type errors found" if exit_code != 0

# Example: auto-generate docs on PR create
on_pr_create:
  - run: kiro doc-gen ./src
  - commit: "docs: auto-generated from PR"

With native AWS integration, this gets powerful — Lambda updates, CloudFormation changes, and serverless deployments can hook directly into your coding workflow. This is the feature that makes "native AWS IDE" mean something real rather than just marketing.

Quick Setup Guide

# 1. Download from kiro.dev (Windows/macOS/Linux)
# 2. Connect AWS account or create Kiro account
# 3. Import VS Code profile on first launch (~80% transfers cleanly)
# 4. Open project — Kiro scans and builds context automatically
# 5. Try first spec: Command Palette → "New Spec"

JetBrains: CLI-based ACP integration available, no native plugin.

Visual Studio / Eclipse: No native support. This is a real blocker, worth knowing before planning a migration.

Browser-based tools stay useful alongside any IDE regardless of environment — I use JWT Decoder & Verifier, Regex Tester, Unix Timestamp Converter, and JWT Secret Key Generator as IDE-independent companions throughout.

Who Should Actually Switch?

✅ Switch if:

You're on Q Developer (migration is inevitable, sooner is better given the model gap)
You work with AWS regularly (Lambda, Bedrock, ECS, RDS, CloudFormation)
You build complex features where spec-driven planning reduces rework
GovCloud compliance is a requirement
Open-source tooling matters to your team

⚠️ Hold off if:

Your IDE is JetBrains, Visual Studio, or Eclipse — native support isn't there yet
Tab completion speed is your primary metric
Your stack is primarily GCP or Azure
You're solo and mostly prototyping — Cursor or Vibe Mode alone serves that better

The Broader Context: Why This Approach Is Gaining Ground

Kiro isn't just a new tool — it's a bet on agentic development becoming the professional default. Gartner tracked a 1,445% surge in multi-agent system inquiries between Q1 2024 and Q2 2025.

I've written about where this is heading in Autonomous AI Agents and Agentic Workflows, and about vibe coding as a philosophy — both connect to what Kiro is building toward. The Google I/O 2026 announcements also showed how the broader industry is moving in this direction.

Amazon's logic is clear: they have the model infrastructure on Bedrock. Kiro is the developer-facing interface that routes that infrastructure directly into coding workflows. If agentic development becomes the professional default — and the trend lines point that way — Kiro is positioned ahead of most competitors.

Verdict

For AWS developers building complex features: worth it, with real evidence behind that claim.

For everyone else: no urgent reason to switch your full setup. But trying Spec Mode on one real feature you're planning to build — that 15-minute experiment will tell you more than any review, including this one.

Are you on Q Developer or have you already migrated? What's your experience with spec-driven development? Drop a comment — genuinely curious how different teams are handling this.

Awais is a developer and builder behind WebToolsHub — a growing collection of free browser-based tools for developers. No sign-up, no server-side data processing, just tools that work.

DEV Community: Muhammad Awais

How to Add WebMCP to Your Next.js App (Complete 2026 Guide)

WebMCP vs MCP — Clear This Up First

The Two APIs — Declarative vs Imperative

Declarative API — HTML Attributes (2 minutes to ship)

Imperative API — registerTool()

Step-by-Step: Next.js App Router Implementation

Step 1 — Install the Polyfill

Step 2 — Initialize in Root Layout

Step 3 — Register Tools in Page Components

Step 4 — Enable the Chrome Flag and Test

Gotchas That Bit Me (So They Don't Bite You)

1. Single-Tab Scope

2. provideContext() Is Gone

3. Tightly Coupled React State Won't Work

4. The 50-Tool Soft Limit

5. HTTPS Is Mandatory in Production

Browser Support — Honest Picture (June 2026)

Is It Worth Building Now?

Resources

Antigravity IDE Black Screen After 2.0 Update - All Fixes (Windows, Mac, Linux)

The Problem Nobody Warned Us About

What Antigravity 2.0 Actually Changed (And Why It Broke Things)

Version Timeline (Find Where You Are)

Fix 1: Update to 2.0.11

Fix 2: Clear Cache and Logs (2 Minutes)

Fix 3: Clean Reinstall

Fix 4: Open IDE Button Doing Nothing

Fix 5: File Explorer Missing — AppData Migration

Fix 6: Antivirus Causing Instant Black Screen (Windows)

Quick Decision Guide

While Your IDE Was Down

Full Guide + FAQ

How to Use OpenCode — The 160K-Star Free Cursor Alternative (2026)

🤔 Wait, What Even Is OpenCode?

📦 Installation (Pick Your Method)

Method 1: Official Script — Fastest Option

Method 2: npm

Method 3: Homebrew (macOS)

Method 4: Go Install (Advanced / Compile from Source)

⚙️ Configure Your AI Provider

🔍 The Feature Nobody Talks About: LSP Integration

⚔️ OpenCode vs Claude Code: The Honest Take

Where Claude Code Wins

Where OpenCode Wins

🚀 Real Next.js Workflow with OpenCode

Step 1: Initialize Project Context

Step 2: Use Planning Mode for New Features

Step 3: Give Explicit Scoped Instructions

Step 4: Use /undo Liberally

💸 What Does OpenCode Actually Cost?

❌ Mistakes I See Beginners Make

🔮 What's Coming in OpenCode

⭐ TL;DR

How to Calculate LLM API Cost: Tokens, Pricing & the Formula Every Dev Needs (2026)

What Is a Token? (The Version That Actually Helps)

Input Tokens vs Output Tokens — The Pricing Split

LLM API Pricing Table — Mid-2026

The Formula

How to Count Tokens Before You Send

5 Mistakes Silently Inflating Your Bill

1. Sending Full Conversation History Every Turn

2. Bloated System Prompts

3. No max_tokens Set

4. Flagship Model for Everything

5. Not Using Prompt Caching

Real-World Monthly Cost Estimates

Monitoring in Production

Quick Reference

How to Decode a JWT Token Online: The Debug Guide Every Developer Needs (2026)

What You'll Learn

Every JWT Is Three Base64 Strings Separated by Two Dots

Part 1: The Header

Part 2: The Payload (Claims)

Part 3: The Signature

The 5 JWT Errors That Waste the Most Time

Error 1: jwt expired

Error 2: invalid signature

Error 3: jwt malformed

Error 4: Claims mismatch (iss/aud invalid)

3. No `max_tokens` Set

Error 1: `jwt expired`

Error 2: `invalid signature`

Error 3: `jwt malformed`

Error 4: Claims mismatch (`iss`/`aud` invalid)

Error 5: `alg:none` attack

The `html { font-size: 62.5% }` Trick (And Why It's Outdated)