Forem: GDS K S

I Built a Self-Hosted AI Agent That Runs on a Raspberry Pi

GDS K S — Sun, 05 Apr 2026 04:48:25 +0000

Most AI coding tools live in someone else's cloud. Cursor, Devin, GitHub Copilot: useful, but your context and conversations flow through a third-party server. For some teams that's fine. For others it's a non-starter.

I wanted an AI agent engine I could deploy on my own hardware, connect to whatever model I wanted, and extend without waiting for a vendor to ship the feature. So I built profClaw.

The problem with the current landscape

There are roughly two categories of AI dev tools right now:

Cloud-only agents (Cursor, Devin, Claude Code web, Copilot Chat): polished and easy to start, but you're locked into their infra, their model selection, and their pricing. No offline mode, no control over what gets logged.

Single-purpose CLIs (Aider, shell wrappers around OpenAI): simpler and self-hosted, but narrow. They do one thing, usually code editing, and don't compose well with the rest of your workflow.

profClaw sits in a different spot: a self-hosted, multi-provider agent engine with a proper TUI, a task queue, multi-agent orchestration, and integrations across 22 chat platforms.

What profClaw actually is

profClaw is a Node.js agent runtime you install and run yourself. Here's the short version of what it ships with:

35 AI providers: Anthropic, OpenAI, Google, Ollama, Groq, DeepSeek, Bedrock, Azure, xAI, OpenRouter, Together, Fireworks, Mistral, LM Studio, and 21 more. Switch between them per-task, not per-account.
72 built-in tools: file operations, git, browser automation, cron scheduling, web search, canvas, voice I/O — all available to agents without writing glue code.
50 skills (slash commands): /commit, /review-pr, /deploy, /summarize, /web-research, /analyze-code, /ticket, /image, and more. These are composable, repeatable agent workflows you run with a single command.
22 chat channels: Slack, Discord, Telegram, WhatsApp, iMessage, Matrix, Teams, Google Chat, Signal, and 13 more. Your agent can receive tasks from wherever your team already works.
MCP server: connects profClaw as a tool provider to Claude Desktop, Cursor, or any MCP-compatible client.
Voice I/O: Whisper for speech-to-text, ElevenLabs or OpenAI TTS for responses, plus a Talk Mode for hands-free use.
REST API + headless mode: for CI/CD pipelines and scripting.
Plugin SDK: extend with third-party plugins via npm.

The task queue is backed by BullMQ with dead-letter queues, retry logic, and priority scheduling — not an in-memory queue that drops work if the process restarts.

Cost tracking is built in. You can set per-token budgets per provider and get alerts when you're approaching limits.

The TUI

The interactive terminal UI is where most of my daily use happens. Streaming markdown with syntax highlighting, a slash command picker, a live model selector, and a tool execution panel that shows what the agent is doing in real time.

┌─────────────────────────────────────────────────────────────────┐
│  profClaw  [claude-sonnet]  [tools: 72]  [$0.0023 / $5.00]     │
├─────────────────────────────────────────────────────────────────┤
│                                                                   │
│  > /review-pr 142                                                 │
│                                                                   │
│  Fetching PR #142...                                              │
│  ✓ git fetch origin pull/142/head                                 │
│  ✓ git diff main...FETCH_HEAD (847 lines)                        │
│  Running analysis...                                              │
│                                                                   │
│  ## PR Review: feat/user-auth                                     │
│                                                                   │
│  **Risk: Medium**                                                 │
│                                                                   │
│  The JWT signing key is read from `process.env.SECRET` without   │
│  a fallback check. If the env var is missing in production...     │
│                                                                   │
├─────────────────────────────────────────────────────────────────┤
│  [/] commands  [tab] models  [ctrl+t] tools  [ctrl+v] voice      │
└─────────────────────────────────────────────────────────────────┘

You can switch models mid-conversation without losing context. The tool panel on the right shows tool calls as they execute so you can see exactly what the agent is doing.

The Raspberry Pi angle

This is the part people find surprising. profClaw has three deployment modes:

Mode	RAM	Use case
Pico	~140MB	Raspberry Pi Zero 2W, $5 VPS, constrained environments
Mini	~145MB	General low-resource use
Pro	Full	All features enabled

Pico mode runs the core agent loop, tool execution, and API — just without some of the heavier integrations. It fits on a Raspberry Pi Zero 2W with headroom to spare. I run a personal instance on a Pi 4 that handles Slack messages from my team and runs scheduled git tasks overnight.

It also runs on old laptops, Docker, and Android phones via Termux if you want to go that route.

Concrete usage examples

Install and start chatting:

npm install -g profclaw
profclaw init
profclaw chat --tui

One-liner install:

curl -fsSL https://raw.githubusercontent.com/profclaw/profclaw/main/install.sh | bash

Docker:

docker run -it --rm \
  -v ~/.profclaw:/root/.profclaw \
  ghcr.io/profclaw/profclaw:latest chat --tui

Run a skill from the CLI:

profclaw run /review-pr 142
profclaw run /web-research "best practices for database connection pooling in 2025"
profclaw run /summarize --file ./meeting-notes.txt

Headless for CI/CD:

profclaw exec --prompt "Analyze test failures in the last run and open issues for regressions" \
  --provider anthropic --model claude-sonnet-4-5 --no-tty

Multi-agent routing — profClaw can route subtasks to different models based on capability scoring. Send the cheap fast model to handle file reads and the stronger model to handle reasoning:

profclaw chat --tui --orchestrate

How it compares

Tool	Self-hosted	Multi-provider	TUI	Chat channels	Task queue
profClaw	Yes	35 providers	Yes	22	BullMQ
Claude Code	No	No	Yes (basic)	No	No
Cursor	No	Limited	No (editor)	No	No
Aider	Yes	Yes	No	No	No
Devin	No	No	No	Limited	No

Aider is the closest comparison — open source, works with multiple providers, self-hosted. The differences: profClaw has a full TUI, chat channel integrations, the task queue, voice I/O, the plugin SDK, and the MCP server. Aider is focused on code editing. profClaw is trying to be a general-purpose agent runtime.

Claude Code is the strongest single-session coding agent I've used. But it requires Anthropic's API, doesn't run a persistent server, and doesn't integrate with Slack or your other tooling. profClaw isn't trying to beat it at pair programming. It's trying to be the agent infrastructure layer that ties everything together.

Architecture notes

Under the hood:

Runtime: Node.js, TypeScript
Task queue: BullMQ (Redis-backed)
MCP: Model Context Protocol server for tool exposure to external clients
Plugin system: npm packages with a defined SDK — install a plugin, it registers its tools and skills automatically
Storage: local-first, your data stays on disk unless you configure otherwise
License: AGPL-3.0

The multi-agent orchestration layer scores tasks by required capability (reasoning depth, tool use, context length) and routes to the configured model that best fits. You define the model pool; profClaw handles routing.

Current state

This is an early open-source release. The core loop is stable — I use it daily. Some integrations are more polished than others. The plugin SDK is functional but the documentation is still thin.

If you run into issues, the GitHub issues tracker is the right place. There's also a Discord if you want to ask questions or share what you're building with it.

Getting started

npm install -g profclaw && profclaw init && profclaw chat --tui

If you're building something with it or have questions, drop them in the comments or open an issue.

Why I stopped uploading files to random websites (and what I use instead)

GDS K S — Sat, 04 Apr 2026 16:27:42 +0000

I found https://filagram.com/ and this is what happened -

Last month I needed to cut the background out of a photo for a client deck. Opened the first Google result, dragged the image in, watched it fly off to a server in... wherever. Got my result. Looked fine. Moved on.

Then it hit me. That photo had someone's face in it. It just went to a server I know nothing about. Stored how long? Who has access? What are they doing with it?

This is what most of us do every week. Compress a PNG? Upload. Merge two PDFs? Upload. Convert HEIC to JPG? Upload.

We hand files to strangers constantly and never think twice.

The upload problem

Tools most developers have bookmarked:

TinyPNG for image compression
ILovePDF for PDF stuff
CloudConvert for format conversion
remove.bg for background removal
Whatever random converter Google spits out first

All of them upload your file to a remote server. Some tell you about it. Some don't. Most privacy policies say something like "we may retain your file temporarily" which could mean anything.

For memes? Whatever. For client contracts, medical records, tax documents? Different story.

Browsers can handle this now

WebAssembly changed the math here. You can run the same compression algorithms that power server-side tools directly in a browser tab. Near-native speed, zero network round trip.

I went looking for tools that process files locally. Found some good single-purpose ones - Squoosh handles image compression well, pdf-lib works for basic PDF operations. But I wanted one tool that replaced the whole bookmarks folder.

Filagram does that. 70 tools covering images, PDFs, format conversion, background removal, and some developer utilities. All browser-based, nothing uploads anywhere.

The ones I reach for most:

Image compression - drop a PNG in, get a smaller one back. Took a 4MB file down to 400KB without visible quality loss.
PDF merge - combine documents without uploading them. Handles big files fine.
Background removal - runs a full AI model locally in the browser. Takes a few seconds to load the first time, then it's fast. This was the one that surprised me.
Format conversion - HEIC to JPG, PNG to WebP, the usual stuff.
Dev tools - base64, JSON formatting, hash generators. Nothing fancy, just saves time.

Check for yourself

Open DevTools (F12), go to the Network tab, clear it, then process a file. If you see your file getting sent as a POST request somewhere, that tool uploads your files. If the network log stays empty during processing, it's running locally.

I ran this test on Filagram. Nothing goes out during processing. The only network request is the AI model file for background removal, which downloads once and runs locally after that.

It's not perfect

Big files (50MB+) can lag on older hardware. Server-side tools have more raw compute available. And some things like OCR still work better in the cloud.

But most daily file work - compressing, converting, merging - happens faster locally because there's no upload/download overhead. And your files stay yours.

Who actually needs to care about this?

If you handle client data, probably you. Healthcare, finance, legal - definitely. If you're compressing screenshots for a blog post, probably doesn't matter.

But once you start paying attention to where your files go, it's hard to stop. I check the network tab reflexively now.

Filagram has a free tier (3 uses/day). $5/mo for unlimited if you need it. But the bigger point is worth thinking about regardless of which tool you pick. Open your bookmarks and check - how many of those file tools are uploading your stuff to servers you've never looked into?

5 open source auth libraries that actually handle AI agents (2026)

GDS K S — Mon, 30 Mar 2026 19:52:00 +0000

I hit this problem a few months back. About 50 agents, each talking to different MCP tool servers, and I couldn't answer a basic question: which agent did what, and who said it could?

Most auth libraries didn't help. They were built for humans logging into web apps. Sessions, cookies, redirect flows. My agents don't have browsers. They need their own tokens, scoped permissions, and when one spins up a sub-agent, I need some way to track that chain. Without it you're just staring at logs guessing which agent made which call.

I tried five libraries. Here's what I found.

TL;DR -- KavachOS is the only one on this list built for agents. Quickstart here. Read on if you want the full picture.

At a glance

Library	Agent identity	MCP OAuth	Delegation chains	Self-host	Edge runtime	License
Better Auth	-	-	-	✅	-	MIT
KavachOS	✅	✅	✅	✅	✅	MIT
Lucia	-	-	-	✅	-	MIT
Keycloak	-	-	-	✅	-	Apache 2.0
Supabase Auth	-	-	-	✅	-	Apache 2.0

Agent capabilities

This is where things get thin. Only one library was actually built with agents in mind.

Feature	Better Auth	KavachOS	Lucia	Keycloak	Supabase
Agent identity tokens	-	✅	-	-	-
Per-agent permission scoping	-	✅	-	Partial	-
Delegation chains	-	✅	-	-	-
Trust scoring	-	✅	-	-	-
Agent audit trail	-	✅	-	-	-
MCP OAuth 2.1 (PKCE, RFC 9728)	-	✅	-	-	-

Human auth (all roughly equal here)

Feature	Better Auth	KavachOS	Lucia	Keycloak	Supabase
Email/password	✅	✅	✅	✅	✅
Social OAuth	✅	✅	✅	✅	✅
Passkeys	✅	✅	-	✅	-
Magic link	✅	✅	-	-	✅
MFA	✅	✅	-	✅	✅
Enterprise SSO (SAML)	✅	✅	-	✅	Paid

Infrastructure and DX

Feature	Better Auth	KavachOS	Lucia	Keycloak	Supabase
TypeScript native	✅	✅	✅	-	-
Edge runtime (Workers, Deno)	-	✅	-	-	-
SQLite / D1	✅	✅	✅	-	-
PostgreSQL	✅	✅	✅	✅	✅
npm install setup	✅	✅	✅	Docker	Hosted

The core problem, visualized

Human auth (what most libraries give you):

  Browser ──> Login page ──> Session cookie ──> API calls
                                 └── expires, user re-authenticates

Agent auth (what you actually need):

  Orchestrator Agent
       │
       ├── Token (kv_abc..., scoped, 24h TTL)
       │     └── Permissions: [repo:read, pr:comment]
       │
       ├── Delegates to Sub-Agent
       │     └── Token (kv_xyz..., subset, 1h TTL)
       │           └── Permissions: [repo:read] only
       │
       └── Audit Trail
             └── Every authorize() logged: agent, action, result, timestamp

See the gap? Most libraries only handle the top half.

Better Auth

github.com/better-auth/better-auth

Best TypeScript auth library for regular apps, full stop. The plugin system covers basically anything you'd want for human auth. I've used it on two other projects and never had complaints.

import { betterAuth } from "better-auth";

const auth = betterAuth({
  database: { provider: "sqlite", url: "./auth.db" },
  emailAndPassword: { enabled: true },
  plugins: [twoFactor(), organization()],
});

I tried making it work for agents by creating "service users" with restricted roles. Got basic tokens going within a day. But then I needed delegation, agent A passing a subset of its permissions to agent B, and there's just no clean way to do that. The abstractions assume a human on the other end.

Also no MCP OAuth support. If you're running MCP tool servers, you'd need to build that layer yourself.

Perfectly good library. Wrong problem.

KavachOS

github.com/kavachos/kavachos

This is what I ended up using. I'll be upfront: I'm biased because it solved my problem. But I'll be honest about the rough edges too.

The difference is that agents are the primary concept here, not users. You create an AgentIdentity with scoped permissions, not a session with a cookie.

import { createKavach } from "kavachos";

const kavach = await createKavach({
  database: { provider: "sqlite", url: "./kavach.db" },
});

const agent = await kavach.agent.create({
  ownerId: "user-123",
  name: "code-reviewer",
  type: "autonomous",
  permissions: [
    { resource: "mcp:github:*", actions: ["read"] },
    { resource: "mcp:github:pull_requests", actions: ["read", "comment"] },
  ],
});

// logged to audit trail automatically
const result = await kavach.authorize(agent.id, {
  action: "read",
  resource: "mcp:github:repos",
});

// delegate a subset to a sub-agent, 1h expiry, max 2 hops
await kavach.delegate({
  fromAgent: agent.id,
  toAgent: subAgent.id,
  permissions: [{ resource: "mcp:github:issues", actions: ["read"] }],
  expiresAt: new Date(Date.now() + 3600_000),
  maxDepth: 2,
});

The delegation part is what got me. My orchestrator creates sub-agents for specific tasks, each gets a time-limited slice of permissions that auto-expires. When a compliance person asked "show me every action this agent took last Tuesday" I exported the CSV in about 10 seconds. That felt good.

MCP OAuth 2.1 works out of the box. PKCE S256, resource indicators, server metadata discovery, dynamic client registration. I'm running the whole thing on Cloudflare Workers.

Now the bad parts. Community is small. If you hit a weird edge case you're reading source code, not Stack Overflow. The plugin ecosystem is thin compared to Better Auth. Docs are getting better but there are still gaps. If you only need human auth, don't use this, it's more machinery than the job needs.

Lucia

github.com/lucia-auth/lucia

I'd used Lucia before and always liked the simplicity. Small API, clean types, no magic. The creator deprecated it in late 2024 in favor of oslo and arctic, but plenty of projects still run it.

import { Lucia } from "lucia";
import { DrizzleSQLiteAdapter } from "@lucia-auth/adapter-drizzle";

const adapter = new DrizzleSQLiteAdapter(db, sessionTable, userTable);
const lucia = new Lucia(adapter, {
  sessionCookie: { attributes: { secure: true } },
});

const session = await lucia.createSession(userId, {});

For what it does, nothing to criticize. Clean session auth with no extra weight.

For agents it's a dead end. Sessions are a browser concept. There's no token model for background agents, no permissions, no audit trail. I thought about storing agent tokens in the session table for about five minutes before realizing I'd be fighting the library the whole way. And since it's deprecated, nothing new is coming.

Good for simple human auth. Wrong tool for agents.

Keycloak

github.com/keycloak/keycloak

The enterprise standard. Java, Red Hat-backed, been around since 2014. If you work at a company with more than 500 people, there's a decent chance Keycloak is running somewhere.

Keycloak keycloak = KeycloakBuilder.builder()
    .serverUrl("http://localhost:8080")
    .realm("master")
    .clientId("admin-cli")
    .username("admin")
    .password("admin")
    .build();

ClientRepresentation client = new ClientRepresentation();
client.setClientId("my-agent-service");
client.setServiceAccountsEnabled(true);
keycloak.realm("my-realm").clients().create(client);

You can model agents as service accounts with client credentials grants. I've seen teams do it and it works fine for basic cases. But there's no delegation, no agent-specific audit, no MCP support. And you can't run it on edge infrastructure because JVM.

The real barrier is complexity. Setting up Keycloak takes a week if you're doing it properly. Minimum 512MB RAM. Config happens through an admin UI, not code. For a team of three building an agent system, it felt like way too much.

If your company already runs Keycloak, use it. If you're starting from scratch, don't.

Supabase Auth

github.com/supabase/auth

GoTrue under the hood, written in Go, deeply integrated with Supabase and PostgreSQL. Free tier gives you 50K MAU. If you're already on Supabase, auth comes for free.

import { createClient } from "@supabase/supabase-js";
const supabase = createClient(SUPABASE_URL, SUPABASE_ANON_KEY);

const { data, error } = await supabase.auth.signUp({
  email: "dev@example.com",
  password: "secure-password-123",
});

Row-level security is the interesting part. Policies on Postgres tables, enforced automatically. For data authorization this works well.

For agents, not so much. Auth is coupled to PostgreSQL, so if you're using SQLite or D1, you're importing a whole database engine just for auth. The service role key is all-or-nothing. RLS handles "can this user read this row" but not "can this agent run a deployment." No delegation, no MCP support.

Good if you're already on Supabase. Not worth adopting just for auth.

The short version

Your situation	Use this
Regular web app, no agents	Better Auth
Agent infrastructure, MCP servers	KavachOS
Enterprise with Java/SSO already	Keycloak (service accounts)
Already on Supabase	Supabase Auth + KavachOS
Need MCP OAuth 2.1	KavachOS (only option right now)

The tradeoff with KavachOS is a smaller community and docs that are still catching up. If that's a dealbreaker, you'll end up building agent auth on top of Better Auth or Keycloak yourself. Most teams are doing that right now, honestly.

Agent auth tooling is early. Most of the industry is duct-taping human auth onto agent systems and hoping nobody asks hard questions. That works for a while.

Links:

KavachOS on GitHub -- star it if this was useful
Quickstart (5 min)
Install: pnpm add kavachos

If you're using something else for agent auth, or you've rolled your own, I'd like to hear about it in the comments.

Add auth to your AI agents in 5 minutes with KavachOS

GDS K S — Mon, 30 Mar 2026 03:08:30 +0000

Auth libraries handle human sign-in. But what happens when your AI agent needs to read from GitHub, deploy to production, or call another agent's API? You end up building a custom permissions layer, rolling your own tokens, and hoping your audit trail holds up.

I got tired of building that layer from scratch for every project, so I built KavachOS. It handles both human auth and agent identity in one library. Here's how to get it running.

What you'll build

┌─────────────────────────────────────────────┐
│                  Your App                   │
│                                             │
│  ┌──────────┐   ┌──────────┐   ┌──────────┐ │
│  │  Human   │   │  Agent   │   │  Agent   │ │
│  │  (Ada)   │   │ (reader) │   │ (deploy) │ │
│  └────┬─────┘   └────┬─────┘   └────┬─────┘ │
│       │              │              │       │
│       ▼              ▼              ▼       │
│  ┌──────────────────────────────────────┐   │
│  │          KavachOS Auth Layer         │   │
│  │  sessions · tokens · permissions ·   │   │
│  │  delegation · audit · MCP OAuth      │   │
│  └──────────────────────────────────────┘   │
│       │                                     │
│       ▼                                     │
│  ┌──────────┐                               │
│  │ SQLite / │                               │
│  │ Postgres │                               │
│  └──────────┘                               │
└─────────────────────────────────────────────┘

A Node.js API where humans sign in with email/password, AI agents get their own identity with scoped permissions, and every action is authorized and logged.

About 5 minutes if you type fast.

Setup

mkdir my-app && cd my-app
npm init -y
npm install kavachos @kavachos/hono hono

Create index.ts:

import { createKavach } from "kavachos";
import { emailPassword } from "kavachos/auth";
import { createHonoAdapter } from "@kavachos/hono";
import { Hono } from "hono";

const kavach = await createKavach({
  database: { provider: "sqlite", url: "kavach.db" },
  plugins: [emailPassword()],
});

const app = new Hono();
app.route("/api/auth", createHonoAdapter(kavach));

That gives you a full auth API. Sign-up, sign-in, sign-out, session management. The SQLite database is created automatically.

Create a user

curl -X POST http://localhost:3000/api/auth/sign-up/email \
  -H "Content-Type: application/json" \
  -d '{"email": "ada@example.com", "password": "secret123", "name": "Ada"}'

Response:

{
  "data": {
    "token": "kv_sess_abc123...",
    "user": { "id": "user-1", "email": "ada@example.com", "name": "Ada" }
  }
}

Now the interesting part: agent identity

This is where KavachOS is different from other auth libraries. You can give AI agents their own identity with scoped permissions.

// Create an agent that can read GitHub repos but needs approval to deploy
const agent = await kavach.agent.create({
  ownerId: "user-1",
  name: "github-reader",
  type: "autonomous",
  permissions: [
    { resource: "mcp:github:*", actions: ["read"] },
    {
      resource: "mcp:deploy:production",
      actions: ["execute"],
      constraints: { requireApproval: true },
    },
  ],
});

console.log(agent.token); // kv_agent_xyz789...

The agent gets a cryptographic bearer token and a set of permissions. The permissions use wildcard matching, so mcp:github:* matches mcp:github:repos, mcp:github:issues, and anything else under that namespace.

How wildcard matching works

Permission:  mcp:github:*

  mcp:github:repos      ✅ match
  mcp:github:issues     ✅ match
  mcp:github:pulls      ✅ match
  mcp:deploy:staging    ❌ no match
  mcp:slack:send        ❌ no match

Authorize agent actions

Before your agent does something, check if it's allowed:

const result = await kavach.authorize(agent.id, {
  action: "read",
  resource: "mcp:github:repos",
});

if (result.allowed) {
  // Go ahead, read the repos
  console.log("Authorized. Audit ID:", result.auditId);
} else {
  console.log("Denied:", result.reason);
}

Every authorization check is logged with an audit ID. You can trace what any agent did, when, and whether it was allowed.

Delegation chains

Agents can delegate permissions to other agents, with limits:

Ada (human)
  └── github-reader (agent)
        permissions: [mcp:github:* → read, mcp:deploy:* → execute]
        │
        └── repo-scanner (sub-agent)
              permissions: [mcp:github:repos → read]
              ↑ subset of parent's permissions only

const subAgent = await kavach.agent.create({
  ownerId: agent.id, // owned by another agent, not a human
  name: "repo-scanner",
  type: "autonomous",
  permissions: [
    { resource: "mcp:github:repos", actions: ["read"] },
  ],
});

The sub-agent can only have permissions that are a subset of its parent's permissions. If the parent agent gets revoked, all its sub-agents lose access too. You can also set depth limits to prevent chains from going too deep.

Wire it to MCP

If you're using the Model Context Protocol, KavachOS ships an OAuth 2.1 authorization server:

import { mcpOAuth } from "kavachos/mcp";

const kavach = await createKavach({
  database: { provider: "sqlite", url: "kavach.db" },
  plugins: [emailPassword(), mcpOAuth()],
});

This gives you PKCE S256, dynamic client registration (RFC 7591), and resource indicators (RFC 8707). Your MCP tools can authenticate through standard OAuth flows.

What the MCP OAuth flow looks like

MCP Client                    KavachOS                    MCP Server
    │                            │                            │
    │  1. Authorization Request  │                            │
    │  (PKCE + code_challenge)   │                            │
    │ ─────────────────────────► │                            │
    │                            │                            │
    │  2. Auth Code              │                            │
    │ ◄───────────────────────── │                            │
    │                            │                            │
    │  3. Token Exchange         │                            │
    │  (code + code_verifier)    │                            │
    │ ─────────────────────────► │                            │
    │                            │                            │
    │  4. Access Token           │                            │
    │ ◄───────────────────────── │                            │
    │                            │                            │
    │  5. API Call with Token    │                            │
    │ ──────────────────────────────────────────────────────► │
    │                            │                            │

Add more auth methods

Want magic links? Passkeys? OAuth with Google? They're all plugins:

import {
  emailPassword,
  magicLink,
  passkey,
  totp,
} from "kavachos/auth";

const kavach = await createKavach({
  database: { provider: "postgres", url: process.env.DATABASE_URL },
  plugins: [
    emailPassword(),
    magicLink({
      sendMagicLink: async (email, url) => {
        await resend.emails.send({
          to: email,
          subject: "Sign in to MyApp",
          html: `<a href="${url}">Click to sign in</a>`,
        });
      },
    }),
    passkey(),
    totp(),
  ],
});

All 14 auth methods

Method	Plugin	Notes
Email + password	`emailPassword()`	HIBP breach checking built in
Magic link	`magicLink()`	Bring your own email sender
Email OTP	`emailOtp()`	6-digit code via email
Phone SMS	`phoneOtp()`	Bring your own SMS sender
Passkey/WebAuthn	`passkey()`	Passwordless biometric
TOTP 2FA	`totp()`	Google Authenticator, Authy
Anonymous	`anonymous()`	Guest sessions
Google One-tap	`googleOneTap()`	One-click sign-in
Username/password	`usernamePassword()`	For non-email systems
Sign In With Ethereum	`siwe()`	Web3 wallet auth
Device authorization	`deviceAuth()`	TV/CLI flows (RFC 8628)
Captcha	`captcha()`	Turnstile, reCAPTCHA
Password reset	`passwordReset()`	Signed, expiring tokens
Session freshness	`sessionFreshness()`	Re-auth for sensitive ops

Framework adapters

KavachOS runs on whatever you're using:

Framework	Install	Adapter
Hono	`npm i @kavachos/hono`	`createHonoAdapter(kavach)`
Express	`npm i @kavachos/express`	`createExpressRouter(kavach)`
Next.js	`npm i @kavachos/nextjs`	`createNextjsHandler(kavach)`
Fastify	`npm i @kavachos/fastify`	`kavachPlugin(kavach)`
Nuxt	`npm i @kavachos/nuxt`	`createNuxtHandler(kavach)`
SvelteKit	`npm i @kavachos/sveltekit`	`createSvelteKitHandler(kavach)`
Astro	`npm i @kavachos/astro`	`createAstroHandler(kavach)`
NestJS	`npm i @kavachos/nestjs`	`KavachModule.register(kavach)`
SolidStart	`npm i @kavachos/solidstart`	`createSolidHandler(kavach)`
TanStack Start	`npm i @kavachos/tanstack`	`createTanStackHandler(kavach)`

React hooks

On the frontend:

import { KavachProvider, useSession, useSignIn } from "@kavachos/react";

function App() {
  return (
    <KavachProvider>
      <LoginPage />
    </KavachProvider>
  );
}

function LoginPage() {
  const { signIn } = useSignIn();
  const { session } = useSession();

  if (session) return <p>Signed in as {session.user.email}</p>;

  return (
    <button onClick={() => signIn("ada@example.com", "secret123")}>
      Sign in
    </button>
  );
}

Also available: @kavachos/vue, @kavachos/svelte, @kavachos/expo (React Native), @kavachos/electron.

Deploy to the edge

Three runtime dependencies: drizzle-orm, jose, zod. That's it. Runs on Cloudflare Workers, Deno, Bun, and Node without code changes.

Runtime support:

  Node.js 20+          ✅
  Cloudflare Workers   ✅  (D1 database)
  Deno                 ✅
  Bun                  ✅

Dependencies:

  drizzle-orm    ORM + query builder
  jose           JWT signing/verification
  zod            Schema validation

  Total: 3

// Cloudflare Workers + D1
const kavach = await createKavach({
  database: { provider: "d1", binding: env.KAVACH_DB },
  plugins: [emailPassword()],
});

What's next

KavachOS is MIT licensed and open source. The full docs are at docs.kavachos.com.

Code: github.com/kavachos/kavachos

#gdsks #glincker #kavachOS #askverdict #auth0 #authlibrary

Build Your First MCP Server in 20 Minutes, Give Any LLM Access to Your App's Data

GDS K S — Sat, 14 Mar 2026 05:38:55 +0000

I Built an MCP Server in 20 Minutes. Now Claude, GPT, and Gemini All Talk to My Database

You've got an app. You've got data. You want Claude (or GPT, or Gemini) to actually use that data — not through copy-pasting context, not through janky API wrappers, but through a clean protocol that any AI client can connect to.

That's exactly what MCP (Model Context Protocol) does.

If you haven't heard of it yet: MCP is an open standard created by Anthropic that lets AI models connect to external tools, databases, and APIs through a universal interface. Think of it like USB-C for AI — one protocol, every model, any tool.

In this tutorial, I'll walk you through building a real MCP server in TypeScript that exposes your PostgreSQL database to any LLM. By the end, you'll have a working server that Claude Desktop, Cursor, or any MCP-compatible client can connect to.

TL;DR: Install @modelcontextprotocol/sdk, define your tools, run the server. Any MCP client connects instantly. Skip to Quick Start

Why MCP? The Problem It Solves
How MCP Works (30-Second Version)
What We're Building
Quick Start
Step 1: Project Setup
Step 2: Define Your Tools
Step 3: Add Resources
Step 4: Connect to Claude Desktop
Step 5: Test It
Going Further: Real-World Patterns
The Full Server (Copy-Paste Ready)
FAQ

Why MCP? The Problem It Solves

Right now, if you want an LLM to interact with your app, you have three bad options:

Approach	What Happens	The Problem
Copy-paste context	Dump data into the prompt manually	Doesn't scale. Manual. Stale data.
Custom function calling	Build tool schemas per model	Different for OpenAI vs Anthropic vs Google. Maintain 3 integrations.
RAG pipeline	Embed everything, search, inject	Overkill for structured data. Expensive. Lossy.

MCP fixes all three. You build one server, and every MCP-compatible client connects to it. When Anthropic updates Claude, when OpenAI adds MCP support, when Cursor ships a new version — your server keeps working. Zero changes.

	Custom Integration	MCP Server
Models supported	1 per integration	All MCP-compatible models
Maintenance	Per-model updates	Zero — protocol handles it
Data freshness	Depends on pipeline	Real-time queries
Setup time	Hours per model	20 minutes, once
Client support	Your app only	Claude Desktop, Cursor, Windsurf, Claude Code, any MCP client

How MCP Works (30-Second Version)

Your App's Data
      ↓
┌─────────────────────┐
│   MCP Server        │  ← You build this (TypeScript/Python)
│                     │
│  Tools:             │  → "query_users" — run SQL queries
│  Resources:         │  → "schema://tables" — expose DB schema
│  Prompts:           │  → "analyze_data" — pre-built analysis prompt
└─────────┬───────────┘
          │ JSON-RPC over stdio/SSE
          ↓
┌─────────────────────┐
│   MCP Client        │  ← Claude Desktop / Cursor / Your App
│   (Any LLM)         │
└─────────────────────┘

Three core concepts:

Tools → Functions the LLM can call (like "run this SQL query")
Resources → Data the LLM can read (like "here's the database schema")
Prompts → Pre-built prompt templates (like "analyze this table")

That's it. Let's build one.

What We're Building

A MCP server that connects to PostgreSQL and exposes:

A query_database tool — LLM can run read-only SQL queries
A list_tables tool — LLM can discover what tables exist
A describe_table tool — LLM can inspect any table's schema
A schema://tables resource — auto-exposes full DB schema
An analyze_table prompt — pre-built analysis template

By the end, you'll be able to open Claude Desktop and say: "What are the top 10 customers by revenue this quarter?" — and Claude will query your actual database and answer.

Quick Start

If you just want to get running:

# Create project
mkdir my-mcp-server && cd my-mcp-server
npm init -y

# Install dependencies
npm install @modelcontextprotocol/sdk pg zod
npm install -D typescript @types/node @types/pg tsx

# Init TypeScript
npx tsc --init --target es2022 --module nodenext --moduleResolution nodenext --outDir dist

Then create src/index.ts (full code below) and run:

npx tsx src/index.ts

Want the full walkthrough? Keep reading.

Step 1: Project Setup

mkdir mcp-database-server && cd mcp-database-server
npm init -y

Install what we need:

npm install @modelcontextprotocol/sdk pg zod
npm install -D typescript @types/node @types/pg tsx

Here's what each package does:

Package	Purpose
`@modelcontextprotocol/sdk`	The official MCP SDK — handles protocol, transport, everything
`pg`	PostgreSQL client
`zod`	Schema validation for tool inputs
`tsx`	Run TypeScript directly without compiling

Create your project structure:

mkdir src
touch src/index.ts

Step 2: Define Your Tools

This is the core of it. Each tool is a function the LLM can call.

// src/index.ts
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
import pg from "pg";

// Database connection
const pool = new pg.Pool({
  connectionString: process.env.DATABASE_URL || "postgresql://localhost:5432/myapp",
});

// Create MCP server
const server = new McpServer({
  name: "database-server",
  version: "1.0.0",
});

// Tool 1: List all tables
server.tool(
  "list_tables",
  "List all tables in the database with row counts",
  {},
  async () => {
    const result = await pool.query(`
      SELECT schemaname, tablename,
             n_tup_ins - n_tup_del AS estimated_rows
      FROM pg_stat_user_tables
      ORDER BY estimated_rows DESC
    `);
    return {
      content: [{
        type: "text",
        text: JSON.stringify(result.rows, null, 2),
      }],
    };
  }
);

// Tool 2: Describe a table's schema
server.tool(
  "describe_table",
  "Get the schema (columns, types, constraints) for a specific table",
  {
    table_name: z.string().describe("Name of the table to describe"),
  },
  async ({ table_name }) => {
    // Prevent SQL injection — only allow valid identifiers
    if (!/^[a-zA-Z_][a-zA-Z0-9_]*$/.test(table_name)) {
      return {
        content: [{ type: "text", text: "Invalid table name." }],
        isError: true,
      };
    }

    const result = await pool.query(`
      SELECT column_name, data_type, is_nullable,
             column_default, character_maximum_length
      FROM information_schema.columns
      WHERE table_name = $1
      ORDER BY ordinal_position
    `, [table_name]);

    return {
      content: [{
        type: "text",
        text: JSON.stringify(result.rows, null, 2),
      }],
    };
  }
);

// Tool 3: Run a read-only SQL query
server.tool(
  "query_database",
  "Execute a read-only SQL query against the database. Only SELECT queries are allowed.",
  {
    sql: z.string().describe("The SQL SELECT query to execute"),
  },
  async ({ sql }) => {
    // Safety: only allow SELECT statements
    const trimmed = sql.trim().toUpperCase();
    if (!trimmed.startsWith("SELECT") && !trimmed.startsWith("WITH")) {
      return {
        content: [{ type: "text", text: "Only SELECT queries are allowed." }],
        isError: true,
      };
    }

    try {
      const result = await pool.query(sql);
      return {
        content: [{
          type: "text",
          text: JSON.stringify({
            rows: result.rows,
            rowCount: result.rowCount,
            fields: result.fields.map(f => f.name),
          }, null, 2),
        }],
      };
    } catch (error: any) {
      return {
        content: [{ type: "text", text: `Query error: ${error.message}` }],
        isError: true,
      };
    }
  }
);

Three things to notice:

Zod schemas define what inputs each tool accepts — the MCP client shows these to the LLM
Safety checks prevent write queries — the LLM can only read
Error handling returns structured errors the LLM can understand

Step 3: Add Resources

Resources are data the LLM can read before deciding what to do. Think of them as context the model gets automatically.

// Resource: Expose the full database schema
server.resource(
  "db-schema",
  "schema://tables",
  async (uri) => {
    const result = await pool.query(`
      SELECT table_name, column_name, data_type, is_nullable
      FROM information_schema.columns
      WHERE table_schema = 'public'
      ORDER BY table_name, ordinal_position
    `);

    // Group by table
    const schema: Record<string, any[]> = {};
    for (const row of result.rows) {
      if (!schema[row.table_name]) schema[row.table_name] = [];
      schema[row.table_name].push({
        column: row.column_name,
        type: row.data_type,
        nullable: row.is_nullable === "YES",
      });
    }

    return {
      contents: [{
        uri: uri.href,
        mimeType: "application/json",
        text: JSON.stringify(schema, null, 2),
      }],
    };
  }
);

Now add a prompt template — pre-built instructions the LLM can use:

// Prompt: Data analysis template
server.prompt(
  "analyze_table",
  { table_name: z.string().describe("Table to analyze") },
  ({ table_name }) => ({
    messages: [{
      role: "user",
      content: {
        type: "text",
        text: `Analyze the "${table_name}" table. First, describe its schema using the describe_table tool. Then run a few queries to understand the data distribution: row count, null percentages for each column, and the top 5 most common values for text/enum columns. Summarize your findings.`,
      },
    }],
  })
);

Step 4: Connect to Claude Desktop

Add the transport and start the server:

// Start the server
async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
  console.error("MCP Database Server running on stdio");
}

main().catch(console.error);

Now tell Claude Desktop about your server. Open your Claude Desktop config:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "my-database": {
      "command": "npx",
      "args": ["tsx", "/full/path/to/mcp-database-server/src/index.ts"],
      "env": {
        "DATABASE_URL": "postgresql://localhost:5432/myapp"
      }
    }
  }
}

Restart Claude Desktop. You should see a hammer icon in the chat input — that means your tools are connected.

Step 5: Test It

Open Claude Desktop and try these:

"What tables are in my database?"

Claude will call list_tables and show you every table with row counts.

"Show me the schema for the users table"

Claude calls describe_table with table_name: "users" and displays the columns.

"What are the top 10 customers by total order value this quarter?"

Claude will:

Read the schema://tables resource to understand your data model
Call describe_table on relevant tables
Write and execute a SQL query using query_database
Format the results into a clean answer

No prompt engineering. It just works.

Going Further: Real-World Patterns

Pattern 1: Add Authentication

Don't expose your production database without auth. Use environment variables and connection pooling:

const pool = new pg.Pool({
  connectionString: process.env.DATABASE_URL,
  max: 5,              // Limit connections
  idleTimeoutMillis: 30000,
  connectionTimeoutMillis: 5000,
});

// Add a query timeout to prevent long-running queries
async function safeQuery(sql: string) {
  const client = await pool.connect();
  try {
    await client.query("SET statement_timeout = '10s'");
    return await client.query(sql);
  } finally {
    client.release();
  }
}

Pattern 2: Multiple Data Sources

One MCP server can expose tools for multiple services:

// Tool: Search your API
server.tool("search_products", "Search products by name or category", {
  query: z.string(),
  category: z.string().optional(),
}, async ({ query, category }) => {
  const response = await fetch(`${API_URL}/products/search?q=${query}&cat=${category || ""}`);
  const data = await response.json();
  return { content: [{ type: "text", text: JSON.stringify(data) }] };
});

// Tool: Get analytics
server.tool("get_metrics", "Get app metrics for a date range", {
  start_date: z.string().describe("ISO date string"),
  end_date: z.string().describe("ISO date string"),
  metric: z.enum(["revenue", "signups", "churn", "active_users"]),
}, async ({ start_date, end_date, metric }) => {
  // Query your analytics service
  const data = await analyticsClient.query(metric, start_date, end_date);
  return { content: [{ type: "text", text: JSON.stringify(data) }] };
});

Pattern 3: SSE Transport for Remote Servers

The stdio transport works for local development. For production, use Server-Sent Events so remote clients can connect:

import express from "express";
import { SSEServerTransport } from "@modelcontextprotocol/sdk/server/sse.js";

const app = express();

app.get("/sse", async (req, res) => {
  const transport = new SSEServerTransport("/messages", res);
  await server.connect(transport);
});

app.post("/messages", async (req, res) => {
  // Handle incoming messages
  await transport.handlePostMessage(req, res);
});

app.listen(3001, () => {
  console.log("MCP server running on http://localhost:3001");
});

The Full Server (Copy-Paste Ready)

Here's the complete src/index.ts — one file, fully working:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
import pg from "pg";

const pool = new pg.Pool({
  connectionString: process.env.DATABASE_URL || "postgresql://localhost:5432/myapp",
  max: 5,
  idleTimeoutMillis: 30000,
});

const server = new McpServer({
  name: "database-server",
  version: "1.0.0",
});

// --- Tools ---

server.tool("list_tables", "List all tables with row counts", {}, async () => {
  const result = await pool.query(`
    SELECT schemaname, tablename, n_tup_ins - n_tup_del AS estimated_rows
    FROM pg_stat_user_tables ORDER BY estimated_rows DESC
  `);
  return { content: [{ type: "text", text: JSON.stringify(result.rows, null, 2) }] };
});

server.tool("describe_table", "Get table schema", {
  table_name: z.string().describe("Table name"),
}, async ({ table_name }) => {
  if (!/^[a-zA-Z_][a-zA-Z0-9_]*$/.test(table_name)) {
    return { content: [{ type: "text", text: "Invalid table name." }], isError: true };
  }
  const result = await pool.query(`
    SELECT column_name, data_type, is_nullable, column_default
    FROM information_schema.columns WHERE table_name = $1
    ORDER BY ordinal_position
  `, [table_name]);
  return { content: [{ type: "text", text: JSON.stringify(result.rows, null, 2) }] };
});

server.tool("query_database", "Run a read-only SQL query (SELECT only)", {
  sql: z.string().describe("SQL SELECT query"),
}, async ({ sql }) => {
  const trimmed = sql.trim().toUpperCase();
  if (!trimmed.startsWith("SELECT") && !trimmed.startsWith("WITH")) {
    return { content: [{ type: "text", text: "Only SELECT queries allowed." }], isError: true };
  }
  try {
    const client = await pool.connect();
    try {
      await client.query("SET statement_timeout = '10s'");
      const result = await client.query(sql);
      return {
        content: [{
          type: "text",
          text: JSON.stringify({ rows: result.rows, rowCount: result.rowCount }, null, 2),
        }],
      };
    } finally {
      client.release();
    }
  } catch (error: any) {
    return { content: [{ type: "text", text: `Error: ${error.message}` }], isError: true };
  }
});

// --- Resources ---

server.resource("db-schema", "schema://tables", async (uri) => {
  const result = await pool.query(`
    SELECT table_name, column_name, data_type, is_nullable
    FROM information_schema.columns WHERE table_schema = 'public'
    ORDER BY table_name, ordinal_position
  `);
  const schema: Record<string, any[]> = {};
  for (const row of result.rows) {
    if (!schema[row.table_name]) schema[row.table_name] = [];
    schema[row.table_name].push({
      column: row.column_name, type: row.data_type, nullable: row.is_nullable === "YES",
    });
  }
  return {
    contents: [{ uri: uri.href, mimeType: "application/json", text: JSON.stringify(schema, null, 2) }],
  };
});

// --- Prompts ---

server.prompt("analyze_table", { table_name: z.string() }, ({ table_name }) => ({
  messages: [{
    role: "user",
    content: {
      type: "text",
      text: `Analyze the "${table_name}" table. Describe its schema, run queries to understand data distribution (row count, null percentages, top values for text columns), and summarize findings.`,
    },
  }],
}));

// --- Start ---

async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
  console.error("MCP Database Server running");
}

main().catch(console.error);

package.json additions:

{
  "type": "module",
  "scripts": {
    "start": "tsx src/index.ts",
    "build": "tsc && node dist/index.js"
  }
}

FAQ

Q: Does this work with GPT / OpenAI?
MCP was created by Anthropic, but the protocol is open. OpenAI has announced MCP support for ChatGPT and their API. It also works with Cursor, Windsurf, Cline, and any client that implements the protocol. You build once.

Q: Is it safe to let an LLM query my database?
The example above only allows SELECT queries and has a 10-second timeout. For production: use a read-only database replica, create a restricted Postgres role with SELECT-only permissions, and add row-level security if needed.

Q: How is this different from function calling?
Function calling is model-specific — you define schemas differently for OpenAI vs Anthropic. MCP is universal. Build the server once, connect any client. It also supports resources (context) and prompts (templates), not just function calls.

Q: Can I use Python instead of TypeScript?
Yes. The MCP SDK has official Python support via mcp package. The patterns are identical — just different syntax:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("database-server")

@mcp.tool()
def list_tables() -> str:
    """List all tables in the database"""
    # Your query logic here
    return json.dumps(tables)

Q: Can I deploy this to production?
Absolutely. Use the SSE transport (shown above) for remote access. Deploy to any Node.js host — Railway, Render, AWS Lambda, a VPS. The server is stateless, so it scales horizontally.

Resources

Building MCP servers for production? We've been working on similar patterns at Glincker — our orchestration layer uses MCP-compatible tooling to connect AI models with app data in real time. If you're building in this space, I'd love to hear what you're connecting.

Published by GDSKS • Lead Architect, Founder at GLINCKER • Building GLINR STUDIOS | AskVerdict.ai

Found this helpful? Give it a ❤️ and follow for more Dev + AI tutorials!

I Tested Every Open-Source Brand SVG Library So You Don't Have To (2026 Edition)

GDS K S — Tue, 10 Mar 2026 18:10:06 +0000

Every developer hits the same wall.

You need a Stripe logo for your integrations page. Or a GitHub icon for your login button. Or 30 brand logos for a "Powered by" section.

So you Google it. You find a blurry PNG. You try the brand's press kit and hit a login wall. You check Figma Community and find something from 2021 with the old logo. An hour later, you're tracing vectors manually.

I got tired of this loop. So I tested every major open-source brand SVG library to figure out which ones are actually worth integrating into a real project.

Here's what I found.

TL;DR -- The Comparison Table

	theSVG	Simple Icons	Font Awesome	svgl	Super Tiny Icons
Brand icons	4,000+	3,400+	~500 free	400+	475
Color variants	5 (color, mono, light, dark, wordmark)	1 (mono)	1	2 (light, dark)	1
npm package	`thesvg`	`simple-icons`	`@fortawesome/fontawesome-free`	--	--
Tree-shakeable	Yes	Yes	Partial	--	--
React components	`@thesvg/react`	Community	Official	Community	--
Vue components	`@thesvg/vue`	--	Official	Community	--
Svelte components	`@thesvg/svelte`	--	--	Community	--
CLI	`@thesvg/cli`	--	--	--	--
REST API	Yes	--	--	Yes	--
CDN URLs	Yes	Yes	Yes	Yes	Yes (GitHub raw)
MCP server (AI)	Yes	--	--	--	--
Figma plugin	In progress	Yes	Yes	Yes	--
Raycast	Yes	Yes	--	Yes	--
Avg. file size	3-8 KB	1-3 KB	2-5 KB	3-10 KB	~534 bytes
GitHub stars	Growing	24.6K	76.4K	5.6K	15.3K
License	MIT	CC0 1.0	OFL/MIT/CC BY	MIT	MIT

If you want the full breakdown of each, keep reading.

1. theSVG -- The Largest Multi-Variant Brand Library

Website: thesvg.org
GitHub: GLINCKER/thesvg
Icons: 4,000+ across 20+ categories

theSVG is the newest library on this list. With over 4,000 brand icons, it has the largest collection of any brand-focused SVG library. But the icon count isn't what makes it interesting.

What sets theSVG apart is multi-variant support. Most libraries give you one version of each icon. theSVG gives you up to five:

Variant	Use case
`default`	Full brand colors -- the standard logo
`mono`	Single-color silhouette for themed UIs
`light`	Optimized for light backgrounds
`dark`	Optimized for dark backgrounds
`wordmark`	Full text logo with brand name

If you've ever shipped a dark-mode app and realized half your brand logos are invisible, you know why this matters.

The developer toolchain

Click to expand: npm packages

npm install thesvg

import github from 'thesvg/github';

github.svg;       // raw SVG string
github.title;     // "GitHub"
github.hex;       // "181717"
github.variants;  // { default, mono, light, dark }

Tree-shakes to only the icons you import. One icon is ~3KB, not 12MB.

Framework packages:

npm install @thesvg/react    # Typed React components with forwardRef
npm install @thesvg/vue      # Vue 3 components
npm install @thesvg/svelte   # Svelte components

import { Github, Stripe, Figma } from '@thesvg/react';

<Github width={24} height={24} className="text-gray-900" />

Click to expand: CLI

npx @thesvg/cli search "payment"
# Returns: stripe, paypal, square, razorpay, klarna...

npx @thesvg/cli add stripe paypal square --format jsx
# Drops JSX components into your project

Click to expand: CDN (zero install)

<img src="https://thesvg.org/icons/github/default.svg" width="32" height="32" />
<img src="https://thesvg.org/icons/github/dark.svg" width="32" height="32" />
<img src="https://thesvg.org/icons/stripe/wordmark.svg" height="20" />

Every icon has a permanent URL. Use them in README files, docs, emails, Notion pages, dashboards -- anywhere you can embed an image.

Click to expand: MCP server for AI coding assistants

{
  "mcpServers": {
    "thesvg": {
      "command": "npx",
      "args": ["@thesvg/mcp-server"]
    }
  }
}

Claude, Cursor, Windsurf, and other AI coding assistants can search and embed 4,000+ brand icons natively. Ask your assistant "add a GitHub icon" and it pulls the real SVG. This is the only brand icon library with MCP support.

Best for: Projects that need brand logos with dark/light/wordmark variants. Teams on React/Vue/Svelte. AI-assisted workflows.

Honest limitations: Newer project, smaller community than Simple Icons. No Figma plugin yet. Some niche brands may be missing.

2. Simple Icons -- The Established Standard

Website: simpleicons.org
GitHub: simple-icons/simple-icons
Stars: 24,600+ | Icons: 3,400+ | npm: ~200K/week

Simple Icons is the library most developers already know. 24K+ stars, 200K weekly npm downloads, and years of community trust.

Every icon is a single monochrome SVG path paired with the brand's official hex color. The consistency is impressive -- every icon follows identical visual guidelines.

import { siGithub } from 'simple-icons';

siGithub.svg;   // SVG string
siGithub.hex;   // "181717"
siGithub.title; // "GitHub"
siGithub.path;  // SVG path data only

The ecosystem is mature: community React wrapper (@icons-pack/react-simple-icons, 87K weekly downloads), Figma plugin, Raycast extension, Alfred workflow. The Iconify integration means Simple Icons work anywhere Iconify does.

Simple Icons runs a strict "Great Icon Review" audit. Icons that fall below popularity thresholds get removed. This keeps the collection sharp but means niche brands may not qualify.

Best for: Projects needing monochrome brand icons. The most battle-tested, community-backed option.

Honest limitations: Mono only. No color, light, dark, or wordmark variants. If you need the actual full-color brand logo, you need another library. No CLI. No REST API.

3. Font Awesome -- The Industry Standard (With Brand Icons)

Website: fontawesome.com
GitHub: FortAwesome/Font-Awesome
Stars: 76,400+ | Free brand icons: ~500 | npm: ~1.8M/week

Font Awesome is the most widely adopted icon library on the web. 76K stars. 1.8 million weekly npm downloads. Version 7 shipped in 2025 with 300+ new icons and 30 styles.

The free tier includes ~500 brand icons alongside 1,500+ UI icons. All brand icons are free across every tier, which is generous.

npm install @fortawesome/fontawesome-free

Official components for React, Vue, and Angular. The ecosystem is enormous.

The trade-off: Font Awesome is a general-purpose library. Brand icons are a subset, not the focus. The free brand collection covers major companies but has gaps compared to dedicated brand libraries. Originated as a font-based system, so SVGs can be heavier.

Font Awesome Pro ($99/year) unlocks 63,000+ icons. If you need UI icons and brand icons from one source, Pro is comprehensive.

Best for: Projects already using Font Awesome for UI icons. Teams wanting one library for everything.

Honest limitations: Only ~500 brand icons free. No multi-variant support. Heavier bundles. Pro requires paid license.

4. svgl -- The Beautiful Browser

Website: svgl.app
GitHub: pheralb/svgl
Stars: 5,600+ | Icons: 400+

svgl focuses on being the most pleasant to use rather than the biggest.

Built with SvelteKit and Tailwind CSS, the website is genuinely beautiful. Browsing icons feels more like a design tool than a developer utility. Each icon has light/dark variants with a clean toggle. Search is fast. Copy-to-clipboard is smooth.

GET https://svgl.app/api/svgs
GET https://svgl.app/api/svgs?category=Framework

The community has built extensions for React, Vue, Svelte, Figma, Raycast, and VS Code. Impressive for a project this young.

The trade-off is collection size. At ~400 icons, svgl has a fraction of Simple Icons or theSVG.

Best for: Designers wanting a beautiful browse-and-copy experience. Quick grabs of popular logos.

Honest limitations: ~400 icons. No npm package. No CLI. No tree-shaking.

5. Super Tiny Icons -- The Performance Play

Website: github.com/edent/SuperTinyIcons
Stars: 15,300+ | Icons: 475

Super Tiny Icons has one rule: every SVG must be under 1 kilobyte.

The average icon is 534 bytes. Some are 180 bytes. Hand-optimized with stripped metadata, simplified paths, and rounded coordinates.

No npm package, no CLI, no components. Just a folder of incredibly small SVG files.

<!-- This entire GitHub SVG is ~500 bytes -->
<img src="https://raw.githubusercontent.com/edent/SuperTinyIcons/master/images/svg/github.svg" width="32" />

A typical brand SVG elsewhere is 3-10KB. Super Tiny Icons delivers recognizable logos at 10-20x smaller file sizes. For email templates, IoT dashboards, or bandwidth-constrained environments, nothing else comes close.

The icons are simplified by necessity. Fine detail is sacrificed for the 1KB target. At 16-32px sizes, the visual difference is negligible.

Best for: Email templates. IoT dashboards. PWAs on slow networks. Anywhere bytes matter.

Honest limitations: 475 icons. Simplified designs. No variants. No tooling. Not for large-size display.

Detailed Feature Comparison

Installation & Setup

Method	theSVG	Simple Icons	Font Awesome	svgl	Super Tiny
npm install	`thesvg`	`simple-icons`	`@fortawesome/fontawesome-free`	--	--
CDN link	Direct URL per icon	jsDelivr / unpkg	cdnjs / jsDelivr	--	GitHub raw URL
Download ZIP	GitHub release	GitHub release	GitHub release	--	GitHub clone
Copy from website	One-click (SVG, JSX, Vue, URI)	One-click (SVG)	Requires account	One-click (SVG)	--
CLI install	`npx @thesvg/cli add <icon>`	--	--	--	--

Variant Support

Variant type	theSVG	Simple Icons	Font Awesome	svgl	Super Tiny
Full color (brand colors)	Yes	No (mono + hex code)	No	Yes	Yes (tiny)
Monochrome / single-color	Yes	Yes (primary format)	Yes	No	No
Light background optimized	Yes	No	No	Yes	No
Dark background optimized	Yes	No	No	Yes	No
Wordmark (logo + text)	Yes	No	No	Partial	No
Brand hex color data	Yes	Yes	No	No	No
Brand guidelines link	Yes	No	No	No	No

Framework Support

Framework	theSVG	Simple Icons	Font Awesome	svgl	Super Tiny
React	`@thesvg/react` (official)	`@icons-pack/react-simple-icons` (community)	`@fortawesome/react-fontawesome` (official)	Community wrapper	--
Vue 3	`@thesvg/vue` (official)	--	`@fortawesome/vue-fontawesome` (official)	Community wrapper	--
Svelte	`@thesvg/svelte` (official)	--	--	Native (SvelteKit)	--
Angular	--	--	`@fortawesome/angular-fontawesome` (official)	--	--
Vanilla JS/TS	`thesvg`	`simple-icons`	`@fortawesome/fontawesome-svg-core`	API fetch	Direct SVG

Ecosystem & Integrations

Integration	theSVG	Simple Icons	Font Awesome	svgl	Super Tiny
Figma plugin	In progress	Yes	Yes	Yes	--
Raycast extension	Yes	Yes	--	Yes	--
VS Code extension	--	--	Yes	Yes	--
Alfred workflow	--	Yes	--	--	--
MCP server (AI assistants)	Yes	--	--	--	--
Iconify integration	--	Yes (official)	Yes (official)	--	--
REST API	Yes (`/api/icons`)	--	--	Yes (`/api/svgs`)	--
PHP/Composer	Yes	Yes	Yes	--	--

The "When Should I Use What?" Decision Tree

Do you need BRAND logos specifically?
├── YES
│   ├── Do you need dark mode / light mode variants?
│   │   ├── YES --> theSVG (only library with 5 variants at scale)
│   │   └── NO
│   │       ├── Is monochrome fine?
│   │       │   ├── YES --> Simple Icons (24K stars, battle-tested)
│   │       │   └── NO (need full color)
│   │       │       ├── Need 100+ brands? --> theSVG
│   │       │       └── Need < 50 popular brands? --> svgl
│   │       └── Is file size critical (email, IoT)?
│   │           └── YES --> Super Tiny Icons
│   └── Do you also need UI icons from the same library?
│       └── YES --> Font Awesome (UI + ~500 brands)
└── NO (need UI icons)
    └── Use Lucide, Heroicons, or Phosphor instead

The Bigger Picture

The brand SVG ecosystem has matured. In 2020, your options were "Google it and hope." In 2026, there are multiple well-maintained libraries with npm packages, CDN support, and active communities.

Three trends are shaping what comes next:

1. Multi-variant support is becoming table stakes. Dark mode is not optional in 2026. If a library can't give you light and dark versions of a logo, you end up creating them in Figma yourself. Right now, theSVG is the only library solving this at scale.

2. Tree-shaking matters more as collections grow. With libraries hitting 3,000-4,000+ icons, naive barrel exports would ship megabytes to users. Per-icon entry points (theSVG, Simple Icons) let bundlers drop everything you don't import.

3. AI integration is the next frontier. Developers increasingly work with AI coding assistants. The ability for Claude, Cursor, or Windsurf to search and embed brand icons natively (via MCP) saves real time. Only theSVG offers this today, but expect others to follow.

Try Them All

Library	Website	Install
theSVG	thesvg.org	`npm i thesvg`
Simple Icons	simpleicons.org	`npm i simple-icons`
Font Awesome	fontawesome.com	`npm i @fortawesome/fontawesome-free`
svgl	svgl.app	Copy from website
Super Tiny Icons	SuperTinyIcons	Clone repo

Every library on this list is open source and free. Pick what fits your project, or mix and match.

No reason to manually hunt for brand SVGs in 2026.

All brand icons and logos mentioned are the property of their respective trademark holders. These libraries make them accessible -- they do not grant trademark rights.

Compare all 7 libraries side-by-side with an interactive feature matrix: thesvg.org/compare

I Got Tired of Hunting for SVG Logos. So I Open-Sourced 4,000 of Them

GDS K S — Mon, 09 Mar 2026 20:13:37 +0000

A few days ago, we launched theSVG on DEV with ~3,847 brand SVG icons.

Since then:

4,007 icons (160+ new brands added)
56 categories (up from 20+)
Dedicated dark and light variants for hundreds of icons
Enhanced search with category, page, and extension results
MCP server so Claude, Cursor, and Windsurf can fetch icons natively

Here's what's new and what we learned building it.

The icon count problem nobody warns you about

When we launched, people asked: "Why not just use Simple Icons?"

Fair question. Simple Icons is a great project. But here's what happens in practice:

You need the Stripe logo on a dark background. Simple Icons gives you a monochrome SVG. You need the colored version. You go to Stripe's press page. They give you a PNG. You convert it. The viewBox is wrong. You fix it. You repeat this for 15 more brands.

theSVG gives you up to 5 variants per icon:

default - brand colors, the standard logo
mono - single color, works with any theme
light - optimized for light backgrounds
dark - optimized for dark backgrounds
wordmark - full text logo with the brand name

No conversion. No hunting. Just pick the variant you need.

What's new since launch

Dedicated dark and light variants

Most icon libraries give you one file and wish you luck on dark backgrounds. We ship separate dark and light variants for hundreds of icons, so you always get a version that's designed to look right on your background - not a hacky CSS inversion.

https://thesvg.org/icons/github/default.svg   <- brand colors
https://thesvg.org/icons/github/dark.svg       <- built for dark bg
https://thesvg.org/icons/github/light.svg      <- built for light bg

The website automatically shows the right variant based on your theme. In code, just pick the variant you need.

Search got smarter

The search bar (Cmd+K) now returns grouped results:

Icons - with variant badges showing what's available (mono, dark, wordmark...)
Categories - type "design" and the Design category appears with its icon count
Pages - Extensions, API Docs, Submit are all searchable
Extensions - find the React package, Figma plugin, CLI, or MCP server
Recent searches - your last 5 searches persist across sessions

MCP server for AI coding

This is the one people didn't expect to care about, then couldn't stop using.

{
  "mcpServers": {
    "thesvg": {
      "command": "npx",
      "args": ["@thesvg/mcp-server"]
    }
  }
}

Tell Claude "add the GitHub logo to my navbar" and it pulls the actual SVG from theSVG. No copy-pasting URLs. No leaving your editor.

Works with Claude Code, Cursor, Windsurf, and any MCP-compatible tool.

The developer toolkit (quick refresher)

If you missed the first post, here's the full stack:

npm packages

# Core library - all 4,007 icons, tree-shakeable
npm install thesvg

# React components with forwardRef + TypeScript
npm install @thesvg/react

# CLI - shadcn-style icon installer
npx @thesvg/cli add github stripe figma

React usage

import { Github, Figma, Stripe } from "@thesvg/react";

function Footer() {
  return (
    <div className="flex gap-4">
      <Github className="h-5 w-5" />
      <Figma className="h-5 w-5" />
      <Stripe className="h-5 w-5" />
    </div>
  );
}

Every component is individually importable. Your bundler only ships what you use. One icon is ~3KB, not 12MB.

CDN - zero install

<img src="https://thesvg.org/icons/github/default.svg" width="32" />
<img src="https://thesvg.org/icons/github/dark.svg" width="32" />

Use these in READMEs, docs, emails, dashboards, Notion pages. No API key, no account.

REST API

# Search
curl https://thesvg.org/api/icons?q=stripe&category=Finance

# Get one icon with all metadata
curl https://thesvg.org/api/icons/stripe

# List categories
curl https://thesvg.org/api/categories

Open, free, no auth required. Build custom icon pickers, internal tools, or CI pipelines that validate brand assets.

What we learned

1. Variants matter more than quantity

We could have shipped 10,000 monochrome icons. Instead we focused on quality variants. A single icon with default, dark, mono, and wordmark covers 95% of real use cases. Developers don't need 10 versions of a logo. They need the right 4.

2. Dark mode needs dedicated variants, not hacks

CSS filter: invert() seems like a quick fix for dark backgrounds, but it breaks brand colors. A blue logo becomes orange. A red badge turns cyan. The only reliable solution is shipping actual dark-optimized SVGs. We now have dedicated dark and light variants for the most popular brands, and we're growing that coverage with every release.

3. AI integration drives adoption

The MCP server was an experiment. It turned out to be one of the most-used features. Developers who use AI coding tools want their tools to have access to real assets, not hallucinated URLs. If you maintain an open-source library, consider building an MCP server. It's a distribution channel most people haven't discovered yet.

4. CDN links are the silent hero

The npm packages get the attention, but the CDN links drive the most traffic. People drop thesvg.org/icons/react/default.svg into GitHub READMEs, Notion docs, and Slack messages. Every usage is a backlink. Build your assets to be directly linkable.

The full package list

thesvg - all icons, one import
@thesvg/icons - core data + TypeScript types
@thesvg/react - 4,007 typed React components
@thesvg/cli - CLI: search, add, export
@thesvg/mcp-server - MCP server for AI assistants

Try it

Browse: thesvg.org
Install: npm install @thesvg/react
Star: github.com/GLINCKER/thesvg

MIT licensed. Brand icons remain the property of their respective trademark holders.

Missing a brand? Submit it or open a PR.

If theSVG saved you time, a star on GitHub helps more than you'd think.

This is a follow-up to our launch post. theSVG is maintained by GLINCKER.

I built an open-source library of 3,847 brand SVG icons. Here's the full developer toolkit

GDS K S — Mon, 09 Mar 2026 03:19:13 +0000

Every time I start a new project, the same thing happens.

I need a GitHub logo. I Google it. I find a 64x64 PNG from 2019. I try the press kit - login wall. I check Simple Icons - they only have monochrome. I check svgl - close, but missing the variant I need.

30 minutes later I'm manually tracing an SVG in Figma.

Sound familiar?

So I built theSVG

thesvg.org is a free, open-source collection of 3,847 brand SVG icons you can search, copy, and drop into any project.

But it's not just a website with a search bar. It's a full developer toolkit.

The npm packages

npm install @thesvg/icons

import github from "@thesvg/icons/github";

github.svg; // raw SVG string
github.title; // "GitHub"
github.hex; // "181717"
github.variants; // { default, mono, light, dark, wordmark }

Only the icons you import end up in your bundle. The package generates individual entry points per icon, so your bundler drops everything else. One icon costs ~3KB, not 12MB.

React components

npm install @thesvg/react

import { Github, Figma, Stripe } from '@thesvg/react';

<Github width={24} height={24} className="text-gray-900" />
<Figma width={32} height={32} aria-label="Figma" />

Every component has:

Full SVGProps<SVGSVGElement> typing
forwardRef support
Zero runtime dependencies
Individual imports for bundlers without tree-shaking (@thesvg/react/github)

CLI

npx @thesvg/cli add github vercel nextjs --format jsx

Drops SVG files (or JSX/Vue components) directly into your project. Auto-detects your directory structure - public/icons/ for Next.js, src/icons/ otherwise.

CDN - zero install

<img src="https://thesvg.org/icons/github/default.svg" width="32" />

Every icon has a direct URL. Use it in README files, docs, emails, dashboards. No API key, no account.

Pro tip - use these as tech stack badges in your GitHub README:

![React](https://thesvg.org/icons/react/default.svg)
![TypeScript](https://thesvg.org/icons/typescript/default.svg)
![Next.js](https://thesvg.org/icons/nextjs/default.svg)

MCP server for AI assistants

{
  "mcpServers": {
    "thesvg": {
      "command": "npx",
      "args": ["@thesvg/mcp-server"]
    }
  }
}

Claude, Cursor, and Windsurf can search and embed brand icons natively. Ask your AI assistant "add a GitHub icon" and it pulls the real SVG.

5 variants per icon

Most icon libraries give you one version. We give you up to five:

Variant	Use case
`default`	Brand colors - the standard logo
`mono`	Single color - works with any theme
`light`	Optimized for light backgrounds
`dark`	Optimized for dark backgrounds
`wordmark`	Full text logo with brand name

import github from "@thesvg/icons/github";

const darkLogo = github.variants["dark"];
const wordmark = github.variants["wordmark"];

Not every icon has all variants, but default is always present.

20+ categories

AI, Software, Framework, Language, Design, Cloud, Browser, CMS, Analytics, Auth, Database, DevOps, E-commerce, Finance, Gaming, Music, Social, Streaming... and more.

Filter by category on the site or via the API:

GET https://thesvg.org/api/icons?category=AI&limit=50

The engineering bits

A few problems I had to solve that might be interesting:

SVG security. SVGs from the wild can contain embedded <script> tags, onload event handlers, or javascript: URIs. The build pipeline scans every SVG and strips anything dangerous before it enters the repo.

Tree-shaking at scale. With 3,847 icons and 5 variants each, the naive approach (one barrel export) would ship ~12MB to every user. Instead, the build generates per-icon entry points. Your bundler only touches the icons you import.

OIDC publishing. No npm tokens stored as GitHub secrets. The release workflow authenticates directly with npm via OpenID Connect. Every published package gets a provenance signature.

Variant normalization. Different sources name variants differently - logo-dark, dark-mode, inverted, on-light. Everything gets normalized to a consistent {slug}/{variant}.svg structure.

The full package list

Package	What
`thesvg`	All icons, one import
`@thesvg/icons`	Core data + TypeScript types
`@thesvg/react`	3,847 typed React components
`@thesvg/cli`	CLI: search, add, export
`@thesvg/mcp-server`	MCP server for AI assistants

Try it

Browse: thesvg.org
GitHub: github.com/GLINCKER/thesvg
Install: npm install @thesvg/icons

The codebase is MIT licensed. Brand icons remain the property of their respective trademark holders.

Missing a brand? Submit it or open a PR. Every brand deserves a place.

If this saves you time, a star on GitHub helps more than you'd think.

FeatureDrop v3 — Your App Now Decides When and How to Show Features

GDS K S — Sun, 01 Mar 2026 05:58:01 +0000

GitHub | Docs | npm | shadcn Components | Example App

Every product adoption tool — Pendo, Appcues, Chameleon — works the same way: collect weeks of server-side analytics, then tell you which users to nudge. They charge $250–$7,000/month for it.

We built a 4 kB client-side engine that makes the same decisions from session one. No server. No data collection. MIT licensed.

This is FeatureDrop v3. (v2 launch post here if you want the backstory — it blew up, so I kept building.)

TL;DR:

Client-side behavioral engine, 4 kB, zero servers
Picks the right format (badge / toast / modal) per user automatically
Free, MIT licensed, 479 tests, works with Next.js / Remix / Astro / Nuxt + shadcn

The Problem With "Just Show It"

Every product adoption tool works the same way: you define a feature, pick a format (badge, modal, toast), set a date, and hope for the best.

But your power users don't need a modal. Your new users don't need a tiny badge. Someone who just dismissed three announcements doesn't want a fourth.

Pendo, Appcues, and Chameleon solve this with server-side analytics pipelines that take weeks to collect enough data.

We solved it with client-side analytics — in 4 kB, from the first session.

The Numbers

Before diving into the how — here's what v3 ships:

Metric	v2.7	v3.0
Core bundle (gzip)	3.01 kB	3.02 kB
Engine bundle (gzip)	—	4.08 kB
Tests	374	479
Subpath exports	20	26
Framework integrations	7	11
shadcn components	0	5
CLI commands	9	10

The core didn't grow. Zero runtime dependencies. The engine is an opt-in 4 kB add-on. If you don't import it, you don't pay for it.

Meet the AdoptionEngine

npm install featuredrop@3

The AdoptionEngine is a plugin that tracks behavior locally and makes smart decisions:

┌─────────────────────────────────────────┐
│           AdoptionEngine                │
├──────────────┬──────────────────────────┤
│ Behavior     │ Tracks sessions, dismiss │
│ Tracker      │ patterns, engagement     │
├──────────────┼──────────────────────────┤
│ Timing       │ Cooldowns, fatigue       │
│ Optimizer    │ detection, optimal gaps  │
├──────────────┼──────────────────────────┤
│ Format       │ Badge vs toast vs modal  │
│ Selector     │ based on user behavior   │
├──────────────┼──────────────────────────┤
│ Adoption     │ A-F grading, breakdown,  │
│ Scorer       │ recommendations          │
└──────────────┴──────────────────────────┘

Here's how you use it:

import { FeatureDropProvider } from 'featuredrop/react'
import { createAdoptionEngine } from 'featuredrop/engine'
import { LocalStorageAdapter } from 'featuredrop'
import features from './features.json'

const engine = createAdoptionEngine()

function App() {
  return (
    <FeatureDropProvider
      manifest={features}
      storage={new LocalStorageAdapter()}
      engine={engine}
    >
      <YourApp />
    </FeatureDropProvider>
  )
}

That's it. The engine now observes user behavior and makes decisions. No config.

useSmartFeature — The Hook That Thinks

Instead of manually deciding "show a badge for this feature," you ask the engine:

import { useSmartFeature } from 'featuredrop/react/hooks'

function Sidebar() {
  const { show, format, feature, dismiss, confidence } =
    useSmartFeature('ai-search')

  if (!show) return null

  // Engine decided: badge for power users, toast for new users
  if (format === 'badge') return <Badge onClick={dismiss}>{feature.label}</Badge>
  if (format === 'toast') return <Toast onClose={dismiss}>{feature.description}</Toast>
  if (format === 'banner') return <Banner onDismiss={dismiss}>{feature.label}</Banner>
}

The confidence score tells you how sure the engine is. First session? Low confidence, conservative format. Tenth session with clear patterns? High confidence, optimal format.

Without the engine, the hook gracefully degrades — always shows, always uses badge format. Zero breaking changes.

SmartAnnouncement — Zero-Config Component

Don't want to write conditional rendering? One component handles everything:

import { SmartAnnouncement } from 'featuredrop/react'

// Engine picks the format automatically
<SmartAnnouncement featureId="dark-mode" />

// Or bring your own UI with render props
<SmartAnnouncement featureId="dark-mode">
  {({ feature, format, dismiss }) => (
    <MyCustomCard title={feature.label} onClose={dismiss} />
  )}
</SmartAnnouncement>

Six built-in format renderers: badge, toast, banner, inline, modal, spotlight. Each adapts to the user.

Framework-Native, Not Framework-Adjacent

v3 ships first-class integrations for every major meta-framework. Not wrappers — native patterns.

Next.js (App Router + RSC)

// app/layout.tsx — Server Component
import { getNewCountServer, FeatureDropScript } from 'featuredrop/next'

export default async function Layout({ children }) {
  const manifest = await getManifest()
  const dismissed = await getDismissedIds(userId)
  const newCount = getNewCountServer(manifest, dismissed)

  return (
    <html>
      <body>
        {/* Hydrates client provider — no flash of "0 new" */}
        <FeatureDropScript manifest={manifest} dismissedIds={dismissed} />
        <nav>
          What's New {newCount > 0 && <span>{newCount}</span>}
        </nav>
        {children}
      </body>
    </html>
  )
}

Also ships native integrations for Remix, Astro, and Nuxt — each creates a fresh MemoryAdapter per request, no shared state, no race conditions.

shadcn Registry — Copy-Paste React Components

If you use shadcn/ui, you can now install FeatureDrop components directly:

# Changelog widget for React — yours to customize
npx shadcn@latest add https://featuredrop.dev/r/changelog-widget.json
npx shadcn@latest add https://featuredrop.dev/r/new-badge.json
npx shadcn@latest add https://featuredrop.dev/r/tour.json
npx shadcn@latest add https://featuredrop.dev/r/checklist.json
npx shadcn@latest add https://featuredrop.dev/r/feedback-widget.json

The shadcn registry turns FeatureDrop into a React component library that lives in your codebase. They use your existing shadcn primitives (Badge, Sheet, Dialog), your Tailwind theme, your design tokens. Not our CSS — yours.

AI-Native Developer Experience

Every AI coding assistant now understands FeatureDrop:

npx featuredrop ai-setup

This auto-detects your editor and creates the right context:

Editor	What it creates
Claude Code	`.claude/skills/featuredrop.md` + MCP config
Cursor	`.cursorrules` + `.cursor/mcp.json`
VS Code	`.vscode/mcp.json`

The MCP server gives your AI assistant 5 tools (scaffold features, validate manifests, suggest components) and 6 resources (hooks reference, component catalog, adapter guide).

Tell Claude "add a changelog to my sidebar" and it generates correct imports, hooks, and provider setup — first try.

The Open Source Pendo Alternative

If you're evaluating product adoption tools, here's what the market charges:

Capability	Pendo	FeatureDrop v3
Feature announcements	Yes	Yes
Product tours	Yes	Yes
Checklists	Yes	Yes
NPS/Surveys	Yes	Yes
Feedback collection	Yes	Yes
Smart timing	Server-side, weeks of data	Client-side, session 1
Format adaptation	Manual rules	Automatic
Adoption scoring	Dashboard only	In-app hooks
Bundle size	100-300 kB	3 kB core + 4 kB engine
Data collection	Their servers	Your browser. That's it.
Price	$7,000+/year	$0
Vendor lock-in	Yes	MIT licensed

Key takeaway: You don't need a $7k analytics pipeline to make smart adoption decisions. A 4 kB client-side engine with localStorage is enough.

Get Started in 5 Minutes

npm install featuredrop

Create features.json with your features
Wrap your app in <FeatureDropProvider>
Drop <SmartAnnouncement featureId="..." /> wherever you want
Done. The engine handles the rest.

GitHub | Docs | shadcn Components | Example App

FeatureDrop Cloud (hosted dashboard for teams) is coming soon. The open-source library stays free forever.

If you've used Pendo, Appcues, or Beamer — what made you pay for them vs. building in-house? I'd love to hear in the comments.

I'm GDS K S, building FeatureDrop at GLINR Studios. Star the repo if this is useful.

How I Replaced $3,000/Year of SaaS With 50 Lines of Code - Building FeatureDrop

GDS K S — Sat, 28 Feb 2026 01:54:13 +0000

How I Replaced $3,000/Year of SaaS With 50 Lines of Code

Every SaaS product eventually needs the same thing: a way to tell
users about new features. A "New" badge. A changelog popup. A
guided tour for complex flows.

The standard playbook is to buy a third-party tool, embed a script
tag, and configure it through a dashboard. It works. But it also
costs $50–600/month, ships 100–300 kB of JavaScript to your users,
and locks your feature data in someone else's database.

I decided to see how much of that I could replace with a library.

The answer turned out to be: all of it.

The Core Insight

Product adoption tools are fundamentally simple at the data layer.
Every one of them does the same thing:

features[] → isNew(featureId) → render UI

A list of features with dates and metadata. A function that checks
whether a specific feature is "new" to the current user. And a set
of UI components that react to that state.

The complexity lives in the vendor dashboard, the analytics pipeline,
and the billing system — not in the client-side code. Strip all that
away and you're left with something surprisingly small.

FeatureDrop in 50 Lines

Here's a complete product adoption setup — changelog, badges, and
an onboarding tour:

// features.json
const features = [
  {
    id: 'dark-mode',
    label: 'Dark Mode',
    description: 'Full dark theme support across every surface.',
    releasedAt: '2026-02-20',
    showNewUntil: '2026-04-20',
    category: 'ui',
  },
  {
    id: 'csv-export',
    label: 'CSV Export',
    description: 'Export any report to CSV with one click.',
    releasedAt: '2026-02-25',
    category: 'data',
  }
]

// App.tsx
import {
  FeatureDropProvider,
  NewBadge,
  ChangelogWidget,
  Tour,
  Checklist,
} from 'featuredrop/react'

const tourSteps = [
  { id: 'sidebar', target: '#sidebar-nav', title: 'Navigation',
    content: 'Find all your tools in the sidebar.' },
  { id: 'reports', target: '#reports-btn', title: 'Reports',
    content: 'Click here to generate CSV exports.' },
]

const tasks = [
  { id: 'profile', title: 'Complete your profile' },
  { id: 'invite', title: 'Invite a teammate' },
  { id: 'first-report', title: 'Run your first report' },
]

export function App() {
  return (
    <FeatureDropProvider manifest={features}>
      <nav>
        Settings <NewBadge id="dark-mode" />
        Reports <NewBadge id="csv-export" />
      </nav>
      <ChangelogWidget title="What's New" />
      <Tour id="welcome" steps={tourSteps} />
      <Checklist id="onboarding" tasks={tasks} />
    </FeatureDropProvider>
  )
}

50 lines. Changelog, badges, guided tour, onboarding checklist.
No API keys. No build plugins. No external scripts.

The isNew() Pipeline

Here's how FeatureDrop decides whether to show a "New" badge:

isNew(featureId)
  │
  ├─ Has the user dismissed this specific feature?
  │   → Yes: not new (dismissed IDs layer)
  │
  ├─ Is it before the publishAt date?
  │   → Yes: not new (not released yet)
  │
  ├─ Is it past the showNewUntil date?
  │   → Yes: not new (expired)
  │
  └─ Was it released after the user's watermark?
      → Yes: it's new!
      → No: not new (user has seen everything up to this point)

The watermark is the key innovation. It's a timestamp that
advances when users open the changelog. Everything released before
that timestamp is considered "seen" — without individually tracking
every feature ID.

This means you can add 100 features to your manifest and users who
have already opened the changelog won't suddenly see 100 "New" badges.
Only features released after their last visit show up.

The dismissed IDs layer handles individual overrides — if a user
dismisses a specific badge without opening the full changelog, only
that feature is marked as seen.

Storage Is Pluggable

State has to persist somewhere. FeatureDrop ships 12 adapters:

// Browser
import { LocalStorageAdapter } from 'featuredrop'
import { IndexedDBAdapter } from 'featuredrop'

// Server
import { RedisAdapter } from 'featuredrop'
import { PostgresAdapter } from 'featuredrop'

// Testing (no side effects)
import { MemoryAdapter } from 'featuredrop'

Writing your own adapter takes ~20 lines:

import type { StorageAdapter } from 'featuredrop'

export class MyApiAdapter implements StorageAdapter {
  async get(key: string): Promise<string | null> {
    const res = await fetch(`/api/storage/${key}`)
    return res.ok ? res.text() : null
  }

  async set(key: string, value: string): Promise<void> {
    await fetch(`/api/storage/${key}`, {
      method: 'PUT',
      body: value
    })
  }

  async remove(key: string): Promise<void> {
    await fetch(`/api/storage/${key}`, { method: 'DELETE' })
  }
}

Bundle Size: The Part I'm Proudest Of

The core engine is under 3 kB gzipped. Zero dependencies.

$ npm install featuredrop
added 1 package in 0.4s
0 vulnerabilities

Everything uses subpath exports for tree-shaking:

// Only imports what you use
import { isNew } from 'featuredrop'           // ~1 kB
import { NewBadge } from 'featuredrop/react'   // ~3 kB
import { Tour } from 'featuredrop/react'       // ~4 kB

For comparison, enterprise adoption tools ship 100–300 kB of
JavaScript to your users. FeatureDrop's entire React bundle is
smaller than most tools' loading spinner GIF.

8 Frameworks, Idiomatic APIs

FeatureDrop isn't React-only. The core is framework-agnostic, and
we ship native bindings for 8 frameworks:

React:

const count = useNewCount()
<NewBadge id="dark-mode" />

Vue 3:

<script setup>
const { newCount, isNew } = useFeatureDrop()
</script>

Svelte 5:

<script>
  import { featureDropStore } from 'featuredrop/svelte'
  const { newCount } = featureDropStore(manifest)
</script>

Solid.js:

const [newCount] = createFeatureDrop(manifest)

Each binding uses the framework's native patterns — composables for
Vue, stores for Svelte, signals for Solid. Not thin wrappers.

Testing Included

374 tests. Core logic, React components, storage adapters, edge
cases. We ship test utilities too:

import { makeFeature, makeStorage } from 'featuredrop/testing'

test('badge shows for new feature', () => {
  const feature = makeFeature({ releasedAt: '2026-02-20' })
  const storage = makeStorage()
  // ... assertions
})

Plus CI integration — validate manifests, check bundle budgets, and
run security audits before merge:

# .github/workflows/ci.yml
- run: npx featuredrop validate ./features.json
- run: npx featuredrop check-size --budget 15kb

Quick Wins — Copy-Paste Snippets

Show a "New" badge on a nav item

<NavItem>
  Settings <NewBadge id="dark-mode" />
</NavItem>

Count unread features

function HeaderBell() {
  const count = useNewCount()
  return <Bell>{count > 0 && <span>{count}</span>}</Bell>
}

Auto-dismiss badge after click

const { dismiss } = useNewFeature('dark-mode')
<button onClick={() => { navigate('/settings'); dismiss() }}>
  Settings
</button>

Show features by category

const uiFeatures = useNewFeaturesByCategory('ui')
const dataFeatures = useNewFeaturesByCategory('data')

Tab title notification

useTabNotification({
  template: '({{count}}) My App',
  defaultTitle: 'My App'
})
// Browser tab shows "(3) My App" when 3 features are unread

What's Next

FeatureDrop v2.0 is the foundation. Coming next:

Theming engine — CSS custom properties, dark mode, animations
i18n — multi-language support for feature descriptions
A/B testing bridge — show different features to test groups
Server components — React Server Components compatibility
Database sync — sync dismiss state across devices

Try It Now

npm install featuredrop

Docs: featuredrop.dev
GitHub: github.com/GLINCKER/featuredrop
Playground: featuredrop.dev/playground
Quickstart (10 min): featuredrop.dev/docs/quickstart

MIT licensed. Free forever. Zero dependencies. 374 tests.

If you're paying monthly for product adoption tools, try FeatureDrop
for a week. I'd love to hear what you think — drop a comment or open
an issue on GitHub.

GDS K S — @thegdsks
Founder at Glincker / AskVerdict AI

OpenClaw and Moltbook: $3,600/Month, WhatsApp Bans, and 923 Exposed Gateways. An Engineer's Breakdown.

GDS K S — Sat, 07 Feb 2026 08:03:34 +0000

I ran OpenClaw for about two weeks. Set it up on a VPS, connected it to Telegram and WhatsApp, tested skills, tuned heartbeats, monitored token burn, and read every security report I could find.

The tech is genuinely impressive. The hype is also genuinely misleading.

This post is my full breakdown of what OpenClaw and Moltbook actually look like after the YouTube demos end and the API bills start arriving. Not a hit piece. I think OpenClaw is one of the most interesting open-source projects out there right now. But there's a gap between the highlight reel and daily reality, and that gap has real dollar amounts attached to it.

What OpenClaw Actually Is (30 Seconds)

OpenClaw is an open-source, self-hosted AI agent built by Peter Steinberger (PSPDFKit founder). It runs locally on your hardware, connects to your messaging apps, and talks to an LLM to reason and execute tasks. It has real system access: shell, browser, files, cron jobs.

The architecture in a nutshell:

You (Phone/Desktop)
      |
      v
+---------------------+
|  Messaging Channel   |  <-- WhatsApp, Telegram, Discord, etc.
|  (your interface)    |
+----------+----------+
           |
           v
+---------------------+
|     Gateway          |  <-- Local Node.js service (ws://127.0.0.1:18789)
|  (control plane)     |
|  Routes messages,    |
|  manages sessions,   |
|  stores memory       |
+----------+----------+
           |
     +-----+-----+
     v           v
+---------+ +----------+
| LLM API | |  Tools   |  <-- Shell, Browser, Files, Skills, Cron
| (Claude,| |          |
|  GPT,   | +----------+
|  etc.)  |
+---------+

The persistent memory across sessions and multi-platform presence is what makes it feel like a genuine step change from browser-tab chatbots. I've had it search files, draft emails, manage calendar entries, and run shell commands, all from a WhatsApp message.

So where's the catch? Mostly in three places: cost, security, and WhatsApp.

The Token Economics Nobody Wants to Talk About

OpenClaw itself is free. Open source, MIT license. But AI agents with full system access and persistent memory are ravenously hungry for tokens.

Every time you message OpenClaw, the entire conversation history gets sent to the LLM. Every heartbeat check (a periodic "wake up and check if anything needs doing") sends the full context window. Every tool call output gets appended to the session and re-sent on the next interaction.

Here's what a single heartbeat actually costs:

+-----------------------------------------------------+
|           WHAT A SINGLE HEARTBEAT COSTS              |
+-----------------------------------------------------+
|  System prompt:              ~5,000-10,000 tokens    |
|  Session history:            ~50,000-120,000 tokens  |
|  Tool definitions (skills):  ~5,000-15,000 tokens    |
|  Reasoning + response:       ~500-2,000 tokens       |
+-----------------------------------------------------+
|  TOTAL per heartbeat:        ~60,000-147,000 tokens  |
|                                                       |
|  At Claude Opus rates ($15/M input, $75/M output):   |
|  ~ $0.75 per heartbeat                               |
|                                                       |
|  Common config: every 30 min = 48/day                |
|  Daily heartbeat cost alone: ~$36                    |
+-----------------------------------------------------+

The system prompt token range comes from Apiyi's cost analysis. The $0.75 per heartbeat and $18.75 overnight figures come from NotebookCheck's investigation.

These aren't hypothetical numbers. Real people have posted real bills:

$18.75 overnight from heartbeat checks asking "is it daytime yet?" (NotebookCheck)
$100+ in a single day of testing by the German tech magazine c't
$3,600 in one month by tech blogger Federico Viticci (referenced in Apiyi analysis)
$300+ in two days on "basic tasks" (Hacker News user, referenced in clawdbot-cost-monitor)
5.7 million tokens overnight from a simple scheduled task, on Haiku, not Opus (GitHub Discussion #1949)

The common rebuttal is "just use Claude Max at $100/month, it's unlimited." That's fair. If you already pay for Claude Max, you can authenticate via claude-cli and piggyback on your subscription. Same with ChatGPT Plus via codex-cli. But most people following the tutorials are pasting API keys, and the onboarding wizard defaults to that path. Nobody reads the fine print until the Anthropic dashboard sends the first bill notification.

The practical range for API users: $5-25/day for moderate use, $100-500+/month for power users. If a cron job gets stuck in a loop or the context window bloats, you can burn through $100 in a single day without realizing it.

"Just Run Local Models" - The Hardware Reality

The natural response to token costs is running models locally. Ollama, LM Studio, vLLM. Zero marginal cost per token.

In practice, OpenClaw's best features (multi-step reasoning, nuanced tool use, autonomous decision-making) only work well with frontier-class models. When you drop to smaller local models, the quality cliff is steep.

A DEV Community post documented this directly: they tried GPT-4o-mini to save money. It couldn't fix basic TypeScript build errors that any intermediate developer would resolve in 60 seconds. Five failed runs later, they switched back to GPT-4o, which fixed it in one shot. The "cheap" model cost more.

To run models that actually compete with cloud APIs (DeepSeek 37B, Kimi K2.5, Qwen 72B), you need real hardware:

Hardware	RAM	Approx. Cost
Mac Mini M4 (base)	32 GB	~$400-600
Mac Mini M4 Pro	48-64 GB	~$800-1,100
Mac Mini M4 Pro (maxed)	96 GB	~$1,300+
Mac Studio M4 Ultra	128-256 GB	~$3,000-6,000
GPU VPS (A100/H100)	80 GB VRAM	~$50-100/day

The Mac Mini sales spike in January wasn't coincidental. YouTube creators were telling people to buy one to run OpenClaw locally. What they glossed over: a 32GB Mac Mini can maybe run a 7-8B parameter model smoothly. For the agentic workflows that make OpenClaw impressive, you need at least 64GB to run a 30B+ model comfortably, and realistically 96GB+ for the larger models. Add electricity costs for running 24/7 and you're not saving as much as the thumbnail promised.

The WhatsApp Problem Everyone Is Ignoring

This one genuinely worries me.

OpenClaw's WhatsApp integration is its most popular channel. It's the demo everyone leads with. But it's built on Baileys, a community library that reverse-engineers the WhatsApp Web protocol.

This is not sanctioned by Meta. It violates WhatsApp's Terms of Service.

From WhatsApp's perspective, your carefully configured personal AI assistant looks identical to a spam bot. Meta actively fights against unofficial automation. Every WhatsApp protocol update risks breaking Baileys entirely.

I've seen multiple reports of users getting their personal WhatsApp accounts suspended after connecting OpenClaw. One blog post documented a Google Voice number getting banned within 48 hours. Another user described a mass-pairing incident where pairing mode accidentally messaged 12 contacts before WhatsApp's rate limiter kicked in.

Even the official OpenClaw docs recommend using a separate phone number. Their own documentation states:

"WhatsApp requires a real mobile number for verification. VoIP and virtual numbers are usually blocked."

So you need a cheap eSIM ($5-10/month from Tello, Mint Mobile, etc.) and ideally a spare phone or WhatsApp Business on your primary device with a different number.

If you want messaging integration without ban risk: use Telegram. Official Bot API, zero ban risk, easier setup. Discord also works with its official bot API. Both are boring answers, but honest ones. This channel security comparison breaks down the differences in detail.

Security: The Part That Actually Scares Me

I'm not a security researcher, but the published findings are hard to ignore.

CrowdStrike found 923+ OpenClaw gateways completely exposed on the public internet with no authentication, no password. Since OpenClaw often runs with shell access, browser control, and stored API keys, anyone who finds an exposed instance can hijack it, steal API keys, and run arbitrary commands on the host machine.

Cisco's AI threat research team ran a deliberately malicious skill ("What Would Elon Do?", which had been artificially boosted to #1 in ClawHub's skill rankings) against OpenClaw and found nine security vulnerabilities including two critical. One of them was active data exfiltration: the skill silently ran a curl command to send data to an external server without the user's knowledge.

Palo Alto Networks described OpenClaw as a "lethal trifecta" of risks: access to private data, exposure to untrusted content, and the ability to communicate externally. They added a fourth risk: persistent memory that enables delayed-execution attacks, where malicious payloads look benign when ingested, get written to long-term memory, and later assemble into executable instructions.

In late 2025, researchers also reported a malicious npm package mimicking Baileys that stole WhatsApp tokens and messages. Supply chain risk is real.

If you're running OpenClaw, treat it like an untrusted application with admin privileges. Because that's functionally what it is.

Run it in an isolated environment. Don't bind the gateway to 0.0.0.0. Use Cloudflare Tunnel or SSH forwarding instead of exposing ports. Don't connect it to your primary email or bank-connected accounts.

Moltbook: Fascinating Experiment or Elaborate Meme?

Moltbook is a Reddit-style social network "exclusively for AI agents." Created by Matt Schlicht (Octane AI co-founder) and built, by his own admission, entirely by his OpenClaw agent. He said he "didn't write one line of code" for it.

And it shows.

404 Media discovered an unsecured database that let anyone commandeer any agent on the platform. Wiz's security review found unauthenticated access to the entire production DB and exposed tens of thousands of email addresses. The platform was taken offline to patch and force-reset all agent API keys.

The "AI-only social network" claims 1.5 million agent users, 110K posts, 500K comments. But Wikipedia's own article on Moltbook notes there's no actual verification that posts come from autonomous agents. The API accepts standard cURL commands any human can replicate. Multiple people on X have called out that viral screenshots come from humans posting through the API while pretending to be agents, often with promotional conflicts of interest.

Even the people who initially praised it walked it back:

Andrej Karpathy (former Tesla AI director): initially called it fascinating, then added "it's a dumpster fire, and I also definitely do not recommend that people run this stuff on their computers."
Simon Willison: called the content "complete slop" while acknowledging agents are getting more powerful.
The Economist: suggested the agents are simply mimicking social media patterns from training data.

A MOLT crypto token launched alongside Moltbook and pumped 1,800% in 24 hours, amplified after Marc Andreessen followed the account. The Adaptavist Group's investigation reported an $8 million crypto scam connected to the OpenClaw/Moltbook hype cycle.

The Creator Economy Behind the Hype

This is the part I really want people to understand.

Every YouTube video showing OpenClaw doing magical things is burning real API tokens to produce that content. A creator testing features, recording demos, and re-running workflows for good takes can easily burn $50-100 in a single recording session on Claude Opus. The video earns it back in ad revenue and sponsorships. But the cost-benefit math they're living is fundamentally different from yours.

Creator:    $50 in tokens --> YouTube video --> $500+ in revenue  OK
You:        $50 in tokens --> ???           --> organized calendar  ???

I'm not saying creators are lying. The demos are real. OpenClaw can do those things. But when someone shows you a 10-minute highlight reel of autonomous magic and doesn't mention they spent $200 in API costs and 6 hours configuring it, that's a misleading picture.

Same applies to the "run it on a Mac Mini" advice. Creators recommending this are either running cloud APIs (eating the cost as a business expense) or have $3,000+ Mac Studios with 128GB+ RAM. The $400 base Mac Mini is a foot in the door, not the whole story.

Setup: What It Actually Takes

If you've managed Docker containers and APIs before: 1-2 hours for a basic setup. The openclaw onboard wizard is legitimately good. You'll be chatting via Telegram or WebChat quickly. Add another hour for WhatsApp (eSIM setup, QR linking, DM policy configuration).

If you're deploying on a VPS: Add 1-2 hours for security hardening. Cloudflare Tunnel, SSH-only access, making sure you're not binding the gateway to all interfaces. The DigitalOcean 1-Click Deploy ($24/month) saves time but you're still responsible for API key management and security.

If you want a "production" setup (dedicated number, model routing, cost controls, skill auditing, heartbeat tuning, session pruning): A full day, minimum. Plus ongoing maintenance. WhatsApp sessions expire every few weeks and need re-linking, skills need updating, session files need pruning to prevent context bloat.

If you're setting up fresh hardware (new Mac Mini, new accounts to isolate from personal stuff): Add another 2-4 hours for OS setup, new Apple ID/email, Node.js installation, and initial configuration.

My Honest Take After Two Weeks

OpenClaw is the most interesting open-source project I've worked with in a long time. The persistent memory, multi-platform presence, and genuine autonomous capabilities make it feel like something from 2028 that leaked early. Peter Steinberger and the community have built something real.

But right now, it's a power tool for power users. The gap between the demo reel and daily reality includes unpredictable API costs that require active monitoring, legitimate security risks that demand infrastructure knowledge, a WhatsApp integration built on a reverse-engineered protocol that can get your number banned, and a hype cycle turbocharged by content creators whose economics don't match yours.

If you're a developer with a clear automation use case and you understand the token economics, absolutely try it. Start with Telegram, use Sonnet instead of Opus, set hard spending limits at your API provider, and tune the heartbeat interval.

If you're a non-technical person who saw a TikTok and wants a JARVIS, wait six months. The project is moving fast and the rough edges will smooth out. But today is not the day to connect your primary WhatsApp to an agent running with shell access on a machine bound to the open internet.

The future this points to is real. The present requires caution.

If this was useful, I'm building something in this space that addresses several of these pain points. More on that soon. Follow me here for updates.

Sources:

Claude Opus 4.6 for Developers: Agent Teams, 1M Context, and What Actually Matters

GDS K S — Thu, 05 Feb 2026 22:22:22 +0000

Anthropic just shipped Claude Opus 4.6. The headlines focus on benchmarks and the 1M token context window — both impressive — but as someone who ships production code with AI assistants daily, I want to focus on what actually changes your workflow.

Let's cut through the noise.

TL;DR — What's New

Feature	What It Does	Why You Care
1M token context	Process ~30K lines of code in one shot	Full codebase understanding, not snippets
Agent teams	Multiple Claude instances work in parallel	Code review in 90 seconds, not 30 minutes
Adaptive thinking	4 effort levels (low -> max)	Pay less for simple tasks, go deep when needed
Context compaction	Auto-summarizes old context	Long-running sessions without context rot
128K output tokens	4x more output	Complete implementations, not truncated fragments

1. Agent Teams (Research Preview)

This is the headline feature for Claude Code users.

Before: One agent, sequential processing. You ask it to review a PR, it goes file by file.

After: You describe the team structure, Claude spawns multiple agents that work independently and coordinate.

How to enable:

// settings.json
{
  "experimental": {
    "agentTeams": true
  }
}

Or set the env var:

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=true

Best use cases:

Code review across layers -- security agent + API agent + frontend agent
Debugging competing hypotheses -- each agent tests a different theory in parallel
New features spanning multiple services -- each agent owns its domain
Large-scale refactoring -- divide and conquer across modules

How it actually works:

One session acts as team lead. It:

Breaks the task into subtasks
Spawns teammate sessions (each with its own context window)
Teammates work independently and communicate results
Team lead synthesizes findings

You can jump into any sub-agent with Shift+Up/Down or via tmux.

Pro tip: Agent teams shine on read-heavy tasks. For write-heavy tasks where agents might conflict on the same files, single-agent is still more reliable.

2. The 1M Context Window That Actually Works

Other models have had large context windows before. The difference is retrieval quality.

Anthropic published MRCR v2 scores — a benchmark that tests whether a model can find and reason about specific information buried in massive context:

Opus 4.6:   76.0%  ████████████████████████████████████████
Sonnet 4.5: 18.5%  █████████

This isn't just "more tokens." It's the difference between a model that remembers what's in its context and one that forgets.

How this changes your daily workflow

Task	Before (200K)	After (1M)
Bug tracing	Feed files one by one, re-explain architecture	"Trace the bug from queue to API" -- sees everything
Code review	Summarize the PR yourself	Feed the entire diff + surrounding code
New feature	Describe your codebase in the prompt	Let the model read it directly
Refactoring	Lose context after ~15 files	All 47 files live in one session

Practical example:

# Load your entire service into Claude Code
cat src/**/*.ts | wc -l
# 28,000 lines -- fits comfortably in 1M tokens

# Ask Claude to trace a bug across the full codebase
> "The /api/tasks endpoint sometimes returns stale data.
>  Trace the data flow from the queue processor through
>  the cache layer to the API response handler."

Pricing note: Standard pricing ($5/$25 per million tokens) applies up to 200K tokens. Beyond that, premium pricing kicks in at $10/$37.50. For most dev workflows, you'll stay under 200K.

3. Adaptive Thinking & Effort Levels

New API parameter: thinking.budget_tokens combined with effort levels.

// Quick rename -- don't overthink it
const response = await anthropic.messages.create({
  model: "claude-opus-4-6",
  thinking: { type: "enabled", effort: "low" },
  messages: [{ role: "user", content: "Rename userId to accountId across this module" }]
});

// Complex architectural decision -- go deep
const response = await anthropic.messages.create({
  model: "claude-opus-4-6",
  thinking: { type: "enabled", effort: "max" },
  messages: [{ role: "user", content: "Design the migration strategy for moving from REST to GraphQL" }]
});

Four levels: low, medium, high (default), max.

In adaptive mode, the model decides effort level automatically. Simple questions get fast, cheap answers. Complex reasoning gets the full treatment.

Why this matters for costs: If you're running AI-powered tools in production, not every request needs maximum intelligence. We use a similar pattern at Glinr — routing simple queries to faster models and complex tasks to Opus. Adaptive thinking builds this intelligence directly into the model.

4. Context Compaction (Beta)

For long-running agentic sessions, context compaction automatically summarizes older turns to free up space.

const response = await anthropic.messages.create({
  model: "claude-opus-4-6",
  context_compaction: { enabled: true },
  // ... long conversation history
});

Why it matters: Without compaction, a 2-hour refactoring session would blow past any context limit. With compaction, the model keeps a summary of earlier work and full detail on recent turns. It's like git squash for conversation history.

5. Benchmarks That Matter for Developers

Skip the academic benchmarks. Here's what matters for writing code:

Benchmark	Opus 4.6	Opus 4.5	What It Tests
Terminal-Bench 2.0	65.4%	59.8%	Real agentic coding tasks
SWE-bench Verified	80.8%	~72%	Resolving real GitHub issues
MRCR v2 (1M)	76.0%	N/A	Long-context retrieval
HLE	#1	--	Hardest reasoning problems

The Terminal-Bench score is particularly significant. It measures how well a model performs when given access to a full terminal environment — running tests, debugging, iterating. 65.4% means the model can autonomously resolve nearly two-thirds of complex coding tasks.

6. Security: 500+ Zero-Days Found

Before launch, Anthropic's team had Opus 4.6 hunt for vulnerabilities in open-source codebases. It found 500+ previously unknown zero-day vulnerabilities — ranging from crash bugs to memory corruption. In one case, Claude proactively wrote its own proof-of-concept exploit to validate the finding.

If you're using AI for security auditing, this is a step change.

The Bottom Line

Opus 4.6 isn't a marginal upgrade. The combination of:

Context that actually works (1M tokens with 76% retrieval accuracy)
Parallel agent teams (divide and conquer)
Adaptive effort (pay for what you need)
Context compaction (sessions that last hours, not minutes)

...creates a qualitatively different tool. It's less "AI autocomplete" and more "AI development team."

The model is available now via claude-opus-4-6 in the API, Claude Code, and claude.ai.

We're integrating Opus 4.6's capabilities into Glinr — an AI task orchestration platform that intelligently routes between models, manages multi-agent workflows, and tracks everything from tickets to deployments. If you're building AI-powered dev tools, we should talk.

Tags: ai, webdev, programming, productivity, Claude4.6, GLINR

Follow and throw a like for more content

Medium - https://medium.com/@gdsks
Linkedin - https://www.linkedin.com/in/gdsks/
Site - https://www.glincker.com/