DEV Community: TheKitBase

I Open-Sourced the Engine Behind One of My Paid Next.js Templates

TheKitBase — Tue, 27 Oct 2026 02:58:50 +0000

I sell Next.js templates for a living, which made this a slightly odd decision: I just gave away a real, complete piece of one of them for free.

DocsKit is a documentation-site template I sell for $39. A few weeks ago I pulled out everything that makes it a genuinely usable docs site on its own - MDX rendering with real components, dark and light mode, a sidebar and table-of-contents layout - and published it as DocsKit Free, MIT licensed, on GitHub.

Why give part of it away

The honest answer: because it split cleanly. A docs site has a natural line in it that a lot of other template types don't. The engine - rendering MDX, navigating between pages, looking right in dark mode - is infrastructure. The polish - syntax-highlighted code blocks, full-text search, a marketing homepage to sell the thing - is what people are actually paying for.

So the free version isn't a crippled trial with a paywall bolted on. It's the real engine. You can clone it, deploy it, and have a working documentation site in about five minutes. What you don't get is Shiki syntax highlighting, Pagefind search, the marketing homepage, and the deeper config/API reference sections - those stayed in the paid version, and the README says so directly rather than making you find out by hitting a wall.

What's actually in it

MDX content with Callout, CodeBlock, Steps, and Tabs components
Sidebar navigation and an auto-generated table of contents
Dark and light mode, no flash on load
Static export - deploy to Vercel, Netlify, Cloudflare Pages, or any static host
TypeScript strict, no YAML/JSON config file to fight with

One thing I didn't expect to end up caring about

While I was auditing accessibility across my whole paid catalog, I ran the same check against this free one. It's now WCAG 2.2 AA audited in both themes, at desktop and phone widths, with the check itself shipped in the repo (npm run test:a11y) so it doesn't just pass once and silently rot the next time someone edits it.

Try it

Live demo: https://docskit-free.vercel.app/
Repo (MIT licensed): https://github.com/thekitbase/docskit-free
One-click deploy to Vercel from the README

If you use it for something, I'd genuinely like to see it - reply here or find me on X.

Accessible Next.js Templates: We Audited All 13 to WCAG 2.2 AA (and Ship the Check)

TheKitBase — Mon, 26 Oct 2026 09:15:21 +0000

Our homepage used to say every template was "accessible by default". When we went back to check that claim properly, it was mostly untrue. Two templates, Chit and Relay, had real accessibility work behind them. For the other eleven we had good intentions and no evidence, and when we ran a proper check, 11 of the 13 templates passed one check or none. So we audited all 13, fixed everything the audit found, and made the check part of the product.

What the audit checks

axe-core 4.13 with every WCAG 2.0, 2.1 and 2.2 A and AA rule, plus axe's best-practice rules
Every page type in the template, in each theme it ships (light and dark for 12 of the 13), at a 1280px desktop width and a 390px phone width
Menus, drawers, panels, tabs and dialogs checked open, not just the page as it first loads
Text contrast measured from the rendered pixels wherever axe gives up, which is most text over photos, gradients and gradient text
A keyboard pass that tabs through the page and fails any focus stop with no visible focus indicator, or focus landing on something hidden

One check is one route or open state, in one theme, at one screen width. Across the 13 templates that comes to 526 checks, and all of them pass.

What it found

Almost nothing was exotic. The same few problems came up template after template, which is probably the most useful thing to know if you're auditing your own project:

One colour doing two jobs

A brand accent that looks great as a button fill under white text is often too light to use as small text on the page background, and vice versa. Most contrast failures were this. Tweaking one token only moves the failure somewhere else, so the fix was to split it: one token for fills, one for text. Agency Studio's red, Chit's flame red and Marginalia's terracotta all work this way now, and each template's CLAUDE.md says which token is which.

Closed menus you could still tab into

A slide-out drawer that is moved off-screen when closed is still in the page, so its links stay in the tab order. A keyboard user presses Tab and focus disappears into a menu they can't see. This turned up in mobile menus, a docs sidebar, a cart drawer and two dashboard detail panels. The fix: closed panels are inert, focus moves into a panel when it opens, Escape closes it, and focus goes back to the button that opened it.

Text over photos

axe can't work out the contrast of text sitting on a photo or a gradient, so it marks it for review instead of failing it. Measuring the rendered pixels found real failures: index numbers over Stockwell's product photos, category labels over Fashion Storefront's images, and white text on Keel's gold gradient. These got darker scrims, small solid chips behind the text, or dark text instead of white.

Structure and motion

Missing h1s, skipped heading levels, pages with no main landmark, icon buttons with no name, and scroll-reveal sections that stayed invisible for anyone using reduced motion. Every template now respects the reduced-motion setting.

The bug our first pass missed

After the first round of fixes, every template passed. Then, while fixing lint findings in SaaS Dashboard Pro, we spotted something in a screenshot that the audit hadn't: in the light theme, the sidebar's section labels (Overview, Manage, Account) were invisible. The class on them pointed at a colour name that doesn't exist, so the labels inherited the page's dark text colour and sat on a sidebar of exactly the same colour.

Our check missed it for two reasons. axe treats text that is exactly the colour of its background as possibly hidden on purpose, so it doesn't fail it. And our pixel measurement looks for the rendered letters, but there were none to find. Now the check fails any text that matches its background. The same round of review found that SaaS Dashboard Pro's settings tabs and dialogs had never been opened by the check at all. Adding them took it from 40 checks to 62, and immediately caught a delete button that was unreadable in dark mode. A check only covers what it opens.

Every template, checked

Template	Checks passed	What the check covers
Agency Studio	22/22	5 page types, light and dark, phone and desktop, plus the open mobile menu
AI SaaS Landing	40/40	10 page types including docs, blog and auth, light and dark, phone and desktop
AI Tools Directory	58/58	13 page types, light and dark, phone and desktop, plus the mobile menu and search
Chit	40/40	9 page types, dark and light, phone and desktop, plus the open ordering assistant
Creative Portfolio	18/18	4 page types, light and dark, phone and desktop, plus the open mobile menu
DocsKit	30/30	7 page types, light and dark, phone and desktop, plus the open docs drawer
Elite CRM	46/46	9 page types, dark and light, phone and desktop, plus the mobile menu and the deal and contact panels
Fashion Storefront	18/18	6 page types, phone and desktop (light-only template), plus the cart drawer, a missing-size error and a filled bag
Keel SaaS Starter Kit	64/64	13 page types signed in and out, dark and light, phone and desktop, plus menus, command menu and assistant
Marginalia	52/52	11 page types, light and dark, phone and desktop, plus both menus and an open citation
Relay	36/36	6 page types signed in and out, dark and light, phone and desktop, plus menus, model picker and citations
SaaS Dashboard Pro	62/62	9 page types, light and dark, phone and desktop, plus every settings tab, the mobile menu, the user detail panel, the invite panel and the delete dialog
Stockwell	40/40	10 page types, light and dark, phone and desktop

Why the check ships with the template

An audit is a snapshot. The day you change the brand colour, or your coding agent adds a settings page, the snapshot is out of date. So the audit isn't a report we ran once and kept: it's the same script every template ships as npm run test:a11y, and the routes and open states it checks live in a plain config file next to package.json:

// a11y.config.mjs (SaaS Dashboard Pro, trimmed)
export default {
  routes: ["/login", "/dashboard", "/dashboard/users", "/dashboard/settings"],
  themes: { storageKey: "theme", values: ["light", "dark"] },
  states: [
    {
      name: "delete account dialog open",
      route: "/dashboard/settings",
      steps: [
        { click: 'button:has-text("Security")' },
        { click: 'button:has-text("Delete Account")' },
      ],
    },
  ],
};

Run it after a build and it prints one line per check, then exits non-zero if anything fails, so it works in CI as is:

$ npm run build && npm run test:a11y

pass / (desktop light) (15 focus stops)
pass /about (desktop light) (27 focus stops)
pass /services (desktop light) (8 focus stops)
...
pass / [mobile menu open] (mobile dark)

22/22 checks passed (axe-core 4.13.0, wcag2a, wcag2aa, wcag21a, wcag21aa, wcag22aa, best-practice)

Each template's CLAUDE.md, AGENTS.md and .cursorrules now has an Accessibility section too: run the check before finishing, which token to use for text and which for fills, and how closed panels must behave. When you add a route or a dialog, you add it to the config, and the check covers it from then on.

What it doesn't cover

Automated checks catch a lot, but not everything. Whether alt text actually describes the image, whether the reading order makes sense, and how a screen reader announces a custom widget still need a person. These templates have not been through a full manual screen reader audit, and we don't claim they have. What we do claim is narrower and checkable: every page type, in every theme, at both widths, with its menus and dialogs open, passes WCAG 2.2 AA automated checks, and you can run the same check yourself.

Every template's results, coverage and fixes are on one page: see every template's accessibility results, or browse the full catalog.

The 6 Best Next.js AI Chat UI Kits in 2026 (Compared)

TheKitBase — Sat, 24 Oct 2026 06:38:02 +0000

Every AI product now needs a chat surface, and the chat surface is where users decide whether the product feels finished. Smooth token streaming, sources you can actually check, code that opens somewhere better than the middle of a transcript, a stop button that works mid-answer - none of it is hard on its own, but getting all of it to feel right takes weeks. That's why "AI chat UI kit" has become its own category. The options split into two very different kinds of thing, though, and picking the wrong kind costs more time than it saves. This is an honest comparison of six worth your time.

Templates vs. component libraries

Before the list, the split that matters most. A chat template is a whole working app you fork: routes, layout, thread sidebar, settings, a design. A component library gives you the pieces - a message list, a prompt input, a markdown renderer - and you assemble the app yourself. Neither is better. Templates get you to a finished-looking product fastest; libraries fit into an app you already have without bringing their opinions about layout along.

Token streaming - text rendering as it arrives, with a stop control, not a spinner that dumps the whole reply at once.
Citations - inline markers you can click to see the quoted source, not a decorative list of links at the bottom.
A canvas or artifact panel - generated code or documents open beside the chat, the way ChatGPT Canvas and Claude Artifacts work.
A model seam - one obvious place to point the UI at a real model, without rewriting the components.
Backend honesty - whether chat history, auth, and model calls are real, or mocked so the UI runs without keys.

The 6 best Next.js AI chat UI kits in 2026

1. Vercel Chatbot - Best free full-stack chat app

Vercel's official open-source Chatbot template is the reference implementation for the AI SDK, and it's a real, working full-stack app: Auth.js for sign-in, Neon Serverless Postgres for chat history, Vercel Blob for file uploads, AI Gateway for model access, and a shadcn/ui interface. It also ships its own artifacts feature for working on generated content beside the chat. If you want a chatbot that is genuinely wired to a database and a model on day one, and you're happy with the stock shadcn look, this is the default answer and it costs nothing.

Free and open source, maintained by Vercel alongside the AI SDK
Real backend: auth, Postgres chat history, file storage, AI Gateway
Needs a database and an AI Gateway key (or Vercel OIDC) to run
Design is clean but generic shadcn/ui - expect to restyle it to make it yours

2. Relay - Best designed chat UI to fork

Relay is our entry, and it sits in the template column: a complete threaded chat app (home, /app, per-thread routes, settings, login and signup) built on Next.js 16, React 19, and Tailwind v4. Where it differs from Vercel's template is that the interface is the product. Token-by-token streaming with a working stop button, inline citation markers that open a popover with the quoted passage and source link, a Sources card under each reply, and a canvas: give a message an artifact and it opens in a side panel with a live sandboxed preview for HTML (sandbox="allow-scripts" without allow-same-origin, so the preview can run its own scripts but can't read the app's cookies or storage) and a read-only code view for everything else. It also ships a working Cmd+K, Markdown export, share, and a model picker that uses plain "provider/model" strings in the AI Gateway style.

The tradeoff, stated plainly: Relay is a UI kit, not a SaaS starter or a full-stack app. The streaming is real UI behavior running on canned replies - a timer in one hook reveals mock messages a few tokens at a time, and threads are stored in localStorage. No model is called and no key is needed, which is why the whole thing runs the moment you install it. To go live, you replace that one hook's timer with a streamed call to your endpoint; the components only read the hook's output, so nothing else changes. If you want Postgres and auth already connected, Vercel Chatbot is the better pick.

// src/lib/use-chat-stream.ts - the one file you change to go live
// Today: a timer reveals canned segments from mock-data.ts.
// Live: read a ReadableStream from your endpoint instead
// (for example an AI SDK route using an AI Gateway model string).
// ChatWindow only reads visibleSegments and isStreaming,
// so the UI does not change when the source of tokens does.

See Relay - token streaming, citation popovers, a sandboxed code canvas, and a full threaded chat app. Runs with zero keys, swaps to a real model in one hook. From $79, one-time.

3. AI Elements - Best component library for AI SDK projects

AI Elements is Vercel's open-source component library for AI interfaces, built on shadcn/ui and designed to pair with the AI SDK's useChat hook. You install it through its CLI or the shadcn registry, and it copies real source files into your project - Conversation, Message, PromptInput, Reasoning, Tool, and many more - so you own and can edit every line. If you're already on shadcn/ui and the AI SDK, this is the most natural way to add a chat surface to an existing app. What it doesn't give you is the app: no thread sidebar, no routes, no layout decisions made for you.

4. assistant-ui - Best for fully custom chat UX

assistant-ui is an MIT-licensed TypeScript/React library of composable chat primitives, with an API modeled on shadcn/ui and cmdk. The library handles the fiddly parts - auto-scrolling, streaming state, accessibility - while you control every pixel of the look. It integrates with the Vercel AI SDK and LangGraph, works with custom backends, and supports generative UI, where tool calls render as your own components. There's also an optional hosted service, assistant-cloud, for chat history. Pick it when your chat UX is unusual enough that a finished template would fight you.

5. CopilotKit - Best for an in-app copilot

CopilotKit solves a slightly different problem: adding an AI copilot inside an existing app rather than building a chat product. Its MIT-licensed React UI package ships three ready layouts - CopilotChat (embedded), CopilotPopup, and CopilotSidebar - plus a headless mode, and the wider framework is built around letting agents read app state and drive generative UI. If your product is a dashboard or editor that needs an assistant in the corner, this fits better than any full-page chat template.

6. prompt-kit - Best lightweight shadcn add-ons

prompt-kit is an open-source set of AI chat components built on shadcn/ui: a prompt input, an auto-scrolling chat container, a markdown renderer, a Shiki-highlighted code block, a response-stream component, and a few more. It's smaller in scope than AI Elements, which is the point - grab the two or three pieces you need, install them with the shadcn CLI, and keep everything else your own.

Side-by-side comparison

Kit	Type	Backend	Citations / canvas	Runs without keys	Price
Vercel Chatbot	Full app	Auth, Postgres, Blob, AI Gateway	Artifacts	No	Free
Relay	Full app (UI kit)	Mocked, swap one hook	Citation popovers + sandboxed canvas	Yes	From $79
AI Elements	Component library	Bring your own (AI SDK)	Components to assemble	N/A	Free
assistant-ui	Component library	Bring your own	Build your own	N/A	Free (optional cloud)
CopilotKit	In-app copilot	Bring your own	Not the focus	N/A	Free (MIT)
prompt-kit	Component library	Bring your own	Not included	N/A	Free

How to choose

You want a free chatbot that's really wired to a database and a model on day one - Vercel Chatbot.
You want a finished, distinctive chat product UI with streaming, citations, and a canvas, and you'll connect your own model - Relay.
You already have a shadcn/ui + AI SDK app and want to add a chat surface - AI Elements, or prompt-kit for something lighter.
Your chat UX is unusual and you want primitives, not opinions - assistant-ui.
You're adding an assistant to an existing dashboard or editor, not building a chat product - CopilotKit.

These aren't always either/or. A common pattern is to fork a template for the product shell and design, then use the AI SDK on the server for the actual model call. Relay's stream hook is built for exactly that swap.

See Relay - the Next.js AI chat UI kit. Streaming replies, citation popovers, a sandboxed code canvas, Cmd+K, export, and a full threaded chat app. Light and dark, zero config to run.

Every TheKitBase Template Ships AI-Ready: CLAUDE.md, AGENTS.md, and .cursorrules

TheKitBase — Wed, 21 Oct 2026 01:54:56 +0000

Open an unfamiliar codebase in a coding agent and the first few prompts are rarely about the feature you actually want. They're spent on reconnaissance: where does the data live, what's the token system called, is this a server component by default, which file would a human on this team touch to add a page. A generic template leaves the agent to guess at all of it, and a wrong guess costs you a revert.

What ships in every template

CLAUDE.md - read by Claude Code on open. Commands, routes, where things live, the design-token system, conventions, how to add a page, and what not to touch.
AGENTS.md - the same instructions in the shared format a growing list of agents read, OpenAI Codex among them.
.cursorrules - the same instructions again, as the rules file Cursor loads for the project.

All three carry identical content. They're generated from one shared structure per template, so the conventions stay consistent across the whole catalog rather than drifting from one template to the next depending on who wrote the docs that week. Open the project in whichever agent you use, and it loads the file it already knows how to read. Nothing to paste in, nothing to remember to attach.

What's actually in the file

Not a generic AI disclaimer. Here's a trimmed, real excerpt from Stockwell's CLAUDE.md, our largest storefront template:

## Commands

- `npm run dev` - local dev server
- `npm run build` - production build (run before finishing any change)
- `npm run typecheck` - TypeScript check

## Where things live

- Routes: /, /account, /c/[category], /cart, /checkout, /deals, /p/[slug], /shop, /wishlist
- Data: The whole catalogue is in src/lib/catalog.ts - categories, products, reviews, Q&A, sample orders.
- Design tokens (colours, fonts, radii): src/app/globals.css

## Payments and AI

The shopping assistant is offline and rule-based. src/lib/assistant.ts matches keywords
against the catalogue and returns a reply with product picks. It uses no model and needs
no API key.

That last section is the one we'd flag. An agent told the wrong thing about what's actually running in a template will confidently build on a false assumption, like wiring a real API key into a chat feature that's actually a keyword matcher. So the file says so, plainly, instead of staying quiet about it.

The honest AI-status table

That same honesty carries over to /ai-ready, a page that lists every template's actual AI status next to its agent files - which ones run a real model, which run a rule-based or canned-demo assistant, and which have no AI features at all. It exists because a few templates in the catalog do ship mock, rule-based, or demo-corpus AI for the preview experience, and a buyer's coding agent deserves to be told that directly rather than find out by reading the source after the fact.

A prompt cookbook, too

Each template also gets its own cookbook page at /templates/[slug]/ai-prompts - three ready-made prompts for the customizations people actually make first: changing the brand colour, adding a page, wiring up a real backend. Each prompt names the exact file it changes, so it's copy-paste, not guesswork.

The result: open a template in Claude Code, Cursor, or Codex, and it already knows the answers to the first five questions it would otherwise have had to ask you.

See every template's agent files and AI status, or browse the full catalog.

I gave away the docs setup from my paid Next.js template

TheKitBase — Tue, 29 Sep 2026 05:15:07 +0000

I sell a Next.js documentation template called DocsKit. A few weeks ago I sat down and pulled the whole marketing homepage, search, and syntax highlighting stack out of it, kept everything else, and put it on GitHub for free.

Not a demo. Not a 3 page teaser that stops working when you try to add a fourth page. The actual docs system, MIT licensed, clone and go.

I did this mostly because I was annoyed at how most "free tier" templates work. You clone them, poke around for five minutes, hit a wall almost immediately, and the wall is obviously there on purpose. It feels bad even when I'm the one doing the poking. So when I built the free version of mine, I just tried to answer one question honestly. What can this thing do without the stuff that actually took me real time to build?

Turns out the answer is a lot. You get MDX, a sidebar, a table of contents that tracks your scroll position, dark and light mode, all four components, callout boxes, code blocks, numbered steps, and tabs. It also exports to static HTML, so you can throw it on Vercel, Netlify, wherever.

What you don't get is search, which uses Pagefind and took a while to set up properly, syntax highlighting for code blocks, which uses Shiki, same story, and the actual marketing homepage that comes with the paid version. Those are the parts I'd charge for even if I open sourced everything else, because that's where most of the time went.

If you want to see exactly what's different, that's the nice part about doing it this way. You can just diff the two repos. I'm not going to pretend there's nothing to compare.

Demo: https://docskit-free.vercel.app/
Repo: https://github.com/thekitbase/docskit-free

git clone https://github.com/thekitbase/docskit-free.git my-docs
cd my-docs
npm install
npm run dev

If it's useful to you as is, great. That was the point. If you outgrow it, the paid version is linked from the repo.

How to Cut Your AI/LLM Costs in 2026: Caching, Cheaper Models, and Multi-Agent Routing

TheKitBase — Thu, 23 Jul 2026 06:57:17 +0000

AI features ship fast and then the bill arrives. The good news: most LLM spend is avoidable waste - the same prompt paid for a thousand times, a frontier model doing work a cheap one could handle, tokens generated that nobody reads. Here are six levers that cut real money, ordered by how much they typically save, with numbers and code you can paste today.

Lever 1: Prompt caching (the biggest single win)

Most AI apps resend the same large prefix on every request - a system prompt, tool definitions, a knowledge base, few-shot examples. That prefix is often 80% of your input tokens, and you are paying full price for it every single time. Prompt caching bills the cached prefix at roughly one tenth of the input price on a hit. Writing to the cache costs about 1.25x, so the break-even is two requests - after that it is close to 90% off the cached portion.

The rule is that caching is a prefix match: anything before your cache breakpoint must be byte-identical across requests. Put the stable content first (frozen system prompt, deterministic tool list) and the volatile content (the user's actual question, timestamps, per-request ids) last. A single datetime.now() interpolated into the system prompt invalidates the entire cache on every request - the most common reason a cache hit rate sits at zero.

Fastest audit: log cache_read_input_tokens on every response. If it is zero across repeated requests with the same system prompt, a silent invalidator (a timestamp, a random id, unsorted JSON) is in your prefix. Find it and you just cut input cost by up to 90%.

Lever 2: Right-size the model

The reflex to route everything to the smartest, most expensive model is the second biggest source of waste. Model tiers differ by 5x or more in price, and most requests in a real app - classification, extraction, short answers, routing - do not need the top tier. The trick is matching the model to the job, not to your ambition.

Tier	Rough price / 1M tokens (in / out)	Use it for
Small (Haiku-class)	~$1 / ~$5	Classification, extraction, routing, short replies
Mid (Sonnet-class)	~$3 / ~$15	Most product features, tool-calling agents, coding help
Frontier (Opus-class)	~$5 / ~$25	Hard reasoning, long-horizon agents, the few requests that need it

Prices move, so check current rates - but the ratios hold: the small tier is roughly 5x cheaper than frontier for input and output alike. And do not sleep on open-source models. Llama, Mistral, DeepSeek, and Qwen are available through the same gateway, and for high-volume, well-scoped tasks (summarization, extraction, internal tools) they can undercut hosted frontier models dramatically. Route the boring 80% of your traffic to a cheap or open model and reserve the expensive tier for the requests that actually need it.

Lever 3: Multi-agent routing (the cascade pattern)

Levers 1 and 2 combine into the highest-leverage architecture: a cheap model classifies each incoming request, and only the genuinely hard ones escalate to an expensive model. This is the cascade - a fast, cheap triage step in front of your real work. In most apps the classifier costs a rounding error and diverts the majority of traffic away from the frontier tier.

import { generateText } from 'ai'

async function answer(userMessage: string) {
  // 1. A cheap model triages the request
  const { text: difficulty } = await generateText({
    model: 'anthropic/claude-haiku-4.5',
    prompt: 'Classify as SIMPLE or HARD. Reply with one word only.\n\n' + userMessage,
  })

  // 2. Route to the tier that fits
  const model =
    difficulty.trim().toUpperCase() === 'HARD'
      ? 'anthropic/claude-sonnet-4.6'
      : 'anthropic/claude-haiku-4.5'

  const result = await generateText({ model, prompt: userMessage })
  return result.text
}

The same idea scales up: specialized agents per job (a cheap extractor, a mid-tier writer, a frontier planner) instead of one expensive generalist doing everything. You pay top-tier prices only for the steps that are genuinely top-tier work.

Lever 4: Response and semantic caching

Prompt caching (Lever 1) discounts the shared prefix. Response caching skips the model call entirely when the same request comes in again. For static-knowledge queries - FAQs, policy lookups, translations, extraction from identical documents - cache the whole response at the gateway and serve repeats for free.

import { generateText } from 'ai'

const result = await generateText({
  model: 'openai/gpt-5.4',
  prompt: 'Summarize our refund policy in two sentences.',
  providerOptions: {
    gateway: { cacheControl: 'max-age=3600' }, // serve repeats for 1 hour
  },
})

The cache key is the model plus the prompt plus the generation parameters, so identical requests hit and anything that varies (a real conversation) misses and is billed normally. Do not cache user-specific conversations; do cache the repetitive, deterministic lookups that make up a surprising share of most apps.

Lever 5: Gateway-level cost controls

Routing every call through a single gateway is what makes the levers above governable instead of theoretical. From one place you get spend attribution by feature and user, automatic failover to a cheaper provider or model when the primary is down or rate-limited, per-user rate limits so one abuser cannot run up your bill, and budget alerts before you blow the month.

import { gateway } from 'ai'

const result = await generateText({
  model: gateway('anthropic/claude-sonnet-4.6'),
  prompt,
  providerOptions: {
    gateway: {
      order: ['anthropic', 'bedrock'],       // failover order
      models: ['openai/gpt-5.4'],            // fallback model if the primary fails
      user: userId,                           // per-user tracking and rate limits
      tags: ['feature:support', 'env:prod'],  // cost attribution
    },
  },
})

Because the gateway charges provider list price with zero markup, you get all of this - failover, tracking, per-user limits, budgets - without paying more per token than calling the provider directly. Tags turn a mystery invoice into a per-feature cost breakdown, which is how you find the one endpoint quietly burning half your budget.

Lever 6: Token hygiene

The unglamorous lever that adds up. You pay per token in and per token out, so trim both.

Use structured output (a schema) instead of asking for JSON in prose - shorter, parseable, and no wasted tokens explaining the format.
Cap output with maxOutputTokens. A model with no ceiling will happily write three paragraphs where you needed one sentence.
Trim the context you resend - old tool results and stale history are pure cost. Summarize or drop them.
For anything not real-time (nightly reports, bulk classification, embeddings backfills), use the Batch API - it runs asynchronously at roughly half price.

Putting it together

None of these are exotic. Stacked, they routinely take an AI feature from alarming to boring on the cost side. A representative before-and-after for a support assistant handling a mix of simple and hard questions:

Setup	Relative cost
Everything to the frontier model, full prefix every request	100%
+ prompt caching on the system prompt and tools	~40%
+ cascade routing (cheap triage, escalate only hard ones)	~15%
+ response caching on repeated lookups + output caps	~10%

The exact numbers depend on your traffic mix, but the shape is real: the same product, an order of magnitude cheaper to run, with no drop in quality on the requests that actually matter - because the frontier model still handles those. The waste you cut was never doing useful work.

Keel, our AI SaaS starter kit, is built cost-aware from the start - gateway routing, model fallbacks, and a streaming assistant wired so you can swap tiers with a string. Start from an architecture that already respects your bill.

Tool Calling with the AI SDK in Next.js: Build an Assistant That Actually Does Things

TheKitBase — Thu, 23 Jul 2026 06:55:20 +0000

A chat box that only answers questions is a demo. The moment your AI feature has to look something like a user's orders, book a slot, or update a record, you need tool calling - letting the model call functions you define, read the results, and keep going until the task is done. This guide builds that loop with the Vercel AI SDK v6 in Next.js, and it is shorter than you would expect.

The mental model

You give the model a set of tools - each one a description, an input schema, and a function to run. The model decides which tools to call and with what arguments; the SDK runs your functions, feeds the results back, and loops until the model produces a final answer. You never write the orchestration loop by hand.

Setup: one package, gateway model strings

Install the ai package. For the model, pass a plain provider/model string and it routes through the Vercel AI Gateway automatically - no provider SDK, no API key juggling, and you can swap models by changing the string. Gateway slugs use dots for versions (anthropic/claude-sonnet-4.6), which is the one naming gotcha to remember.

// app/api/chat/route.ts
import { generateText } from 'ai'

export async function POST(req: Request) {
  const { prompt } = await req.json()

  const result = await generateText({
    model: 'anthropic/claude-sonnet-4.6', // routes through AI Gateway
    prompt,
  })

  return Response.json({ text: result.text })
}

Defining a tool

A tool is a description (so the model knows when to reach for it), an inputSchema built with Zod (so arguments are validated and typed), and an execute function (your actual code). Be prescriptive in the description about when to call it - not just what it does.

import { tool } from 'ai'
import { z } from 'zod'

const getOrders = tool({
  description:
    "Look up a customer's recent orders. Call this whenever the user asks about order status, history, or a specific purchase.",
  inputSchema: z.object({
    customerId: z.string().describe('The customer id from the session'),
    limit: z.number().optional().describe('How many orders to return'),
  }),
  execute: async ({ customerId, limit = 5 }) => {
    const orders = await db.orders.findMany({
      where: { customerId },
      take: limit,
      orderBy: { createdAt: 'desc' },
    })
    return orders
  },
})

In AI SDK v6 the field is inputSchema, not parameters. If you are following an older tutorial that uses parameters, it will not typecheck - the rename is the single most common upgrade error.

The multi-step loop

One tool call is rarely the whole task. The model might call getOrders, read the result, then decide it also needs to check inventory before answering. stopWhen lets the SDK run that back-and-forth automatically - it keeps looping (call tool, feed result back, let the model continue) until the model stops calling tools or you hit the step cap.

import { generateText, stepCountIs } from 'ai'

const result = await generateText({
  model: 'anthropic/claude-sonnet-4.6',
  stopWhen: stepCountIs(5), // cap the loop at 5 steps
  tools: { getOrders, checkInventory },
  prompt: 'Where is my last order and is a replacement in stock?',
})

// result.text is the final answer after all tool calls resolved
console.log(result.text)

That stepCountIs(5) is your safety belt. Without a cap, a confused model could loop indefinitely. Five is a reasonable default for most assistants; raise it for genuinely multi-hop tasks, lower it for simple lookups.

Streaming the whole thing to the UI

For a chat interface you want tokens and tool activity to stream, not arrive in one blob. Swap generateText for streamText - same tools, same stopWhen - and pipe it to the client. The user sees the assistant think, call a tool, and answer in real time.

import { streamText, stepCountIs } from 'ai'

export async function POST(req: Request) {
  const { messages } = await req.json()

  const result = streamText({
    model: 'anthropic/claude-sonnet-4.6',
    stopWhen: stepCountIs(5),
    tools: { getOrders, checkInventory },
    messages,
  })

  return result.toUIMessageStreamResponse()
}

Gating the dangerous tools

Read-only tools (look up orders, search docs) can run automatically. Tools with side effects - refund a payment, delete a record, send an email - should not fire without a human in the loop. The cleanest pattern is to make the execute function return a proposal instead of performing the action, then confirm on the client before a second call actually commits it.

Validate every argument at the boundary - the model's output is untrusted input, so treat customerId like anything else a user could send.
For destructive actions, have execute return what it would do and surface a confirm step in the UI before committing.
Scope your tools to the current session - never let the model pass in a customerId that is not the authenticated user.

From tools to a reusable agent

Once you have a set of tools you reuse across routes, wrap them in an agent instead of re-declaring the config each time. The AI SDK's ToolLoopAgent pattern bundles the model, tools, and stopWhen into one object you can call from anywhere and type end-to-end. Same loop, less repetition.

The whole point of tool calling: your assistant stops being a search box with personality and becomes a teammate that can actually operate your product - safely, because you define exactly what it can touch.

Keel, our AI SaaS starter kit, ships with a streaming assistant, tool-calling wired through the AI Gateway, and the auth and billing around it - so you start from a working agent instead of a blank route handler.

Next.js 16 Cache Components: use cache, PPR, and When to Reach for Each

TheKitBase — Thu, 23 Jul 2026 06:46:38 +0000

Next.js 16 shipped Cache Components - the feature that finally lets a single route mix static HTML, cached data, and per-request dynamic content without splitting it into separate pages. It is Partial Prerendering (PPR) made stable, plus a new use cache directive that replaces the old unstable_cache and the awkward route-segment config flags. This guide covers what changed, the three content types you now think in, and the runtime-data rule that trips up almost everyone on day one.

What actually changed

If you were using the experimental PPR flag, it is gone. Cache Components is a single config switch, and it turns on the whole model - static shell, cached segments, and streamed dynamic content in one route.

// next.config.ts
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  cacheComponents: true, // replaces experimental.ppr
}

export default nextConfig

Once it is on, every piece of your route falls into one of three buckets. The whole mental model is learning which bucket each component belongs in.

The three content types

Static - synchronous code, imports, and pure markup. Prerendered at build time and served instantly from the CDN. Your header, nav, and layout shell.
Cached - async data that does not need to be fresh on every request. Marked with use cache. Think product lists, blog posts, dashboard stats.
Dynamic - runtime data that must be fresh (cookies, headers, per-user state). Wrapped in Suspense so it streams in after the shell paints.

import { Suspense } from 'react'
import { cookies } from 'next/headers'
import { cacheLife } from 'next/cache'

export default function DashboardPage() {
  return (
    <>
      {/* Static - instant from the CDN */}
      <header><h1>Dashboard</h1></header>

      {/* Cached - fast, revalidates hourly */}
      <Stats />

      {/* Dynamic - streams in with fresh data */}
      <Suspense fallback={<NotificationsSkeleton />}>
        <Notifications />
      </Suspense>
    </>
  )
}

async function Stats() {
  'use cache'
  cacheLife('hours')
  const stats = await db.stats.aggregate()
  return <StatsDisplay stats={stats} />
}

async function Notifications() {
  const userId = (await cookies()).get('userId')?.value
  const items = await db.notifications.findMany({ where: { userId } })
  return <NotificationList items={items} />
}

The payoff: the user sees the static shell and cached stats instantly, and the personalized notifications stream in a beat later - instead of the whole page blocking on the slowest query.

The use cache directive

use cache works at three levels - the whole file, a single component, or a plain data function. Put it at the top of whatever scope you want cached, and Next.js generates the cache key automatically from the function's arguments and closure variables. No manual key arrays like the old unstable_cache required.

// Function level - cache a query
export async function getPosts() {
  'use cache'
  return db.posts.findMany()
}

// Component level - cache a whole subtree
export async function PricingTable() {
  'use cache'
  const plans = await db.plans.findMany()
  return <Plans plans={plans} />
}

Controlling lifetime with cacheLife

By default a use cache block is stale after 5 minutes and revalidates after 15. Override that with a built-in profile or an inline config. The built-in profiles are default, minutes, hours, days, weeks, and max.

import { cacheLife } from 'next/cache'

async function getData() {
  'use cache'
  cacheLife({
    stale: 3600,      // serve stale for 1 hour while revalidating
    revalidate: 7200, // refresh in the background every 2 hours
    expire: 86400,    // hard expiry after 1 day
  })
  return fetch('https://api.example.com/data')
}

Invalidation: cacheTag, updateTag, revalidateTag

Tag your cached data, then invalidate by tag from a Server Action. The one distinction that matters: updateTag refreshes within the same request (the user who just edited sees fresh data immediately), while revalidateTag is background-only (the next visitor sees fresh data). Reach for updateTag after a mutation the current user made; reach for revalidateTag for everyone else's writes.

import { cacheTag } from 'next/cache'

async function getProduct(id: string) {
  'use cache'
  cacheTag('products', 'product-' + id)
  return db.products.findUnique({ where: { id } })
}

// In a Server Action:
'use server'
import { updateTag, revalidateTag } from 'next/cache'

export async function editProduct(id: string, data: FormData) {
  await db.products.update({ where: { id }, data })
  updateTag('product-' + id)   // same request sees the change
  revalidateTag('products')    // everyone else's next load is fresh
}

The rule that trips everyone up

You cannot call cookies(), headers(), or read searchParams inside a use cache block. It makes sense once you say it out loud - cached output has to be identical for everyone, and those APIs are per-request. The fix is to read the dynamic value outside the cached function and pass it in as an argument, where it becomes part of the cache key automatically.

// Wrong - runtime API inside use cache
async function CachedProfile() {
  'use cache'
  const session = (await cookies()).get('session')?.value // Error
  return <div>{session}</div>
}

// Right - read outside, pass in as an argument
async function ProfilePage() {
  const session = (await cookies()).get('session')?.value
  return <CachedProfile sessionId={session} />
}

async function CachedProfile({ sessionId }: { sessionId: string }) {
  'use cache'
  const data = await fetchUserData(sessionId) // sessionId is part of the key
  return <div>{data.name}</div>
}

If you genuinely cannot refactor (a compliance wrapper, say), use cache: private is the escape hatch - it permits runtime APIs and caches per-user. Use it sparingly; it is not a shared cache.

Migrating from the old world

If you are coming from an earlier Next.js app, most of the migration is deleting things. Here is the direct mapping.

Old	Next.js 16 replacement
experimental.ppr	cacheComponents: true
export const dynamic = 'force-dynamic'	Remove - it is the default
export const dynamic = 'force-static'	'use cache' + cacheLife('max')
export const revalidate = N	cacheLife({ revalidate: N })
unstable_cache()	'use cache' directive

The unstable_cache migration is the big one, and it is mostly deletion: no more manual key arrays, tags move from an options object into cacheTag() calls, and revalidate moves into cacheLife(). The same cookies/headers restriction that applied to unstable_cache applies to use cache, so any code that already respected it ports cleanly.

Limitations worth knowing up front

Node.js runtime only - Cache Components does not run on the Edge runtime.
No static export - you need a server, so next export is out.
Non-deterministic values (Math.random, Date.now) run once at build time inside a cached block. For per-request randomness, call connection() from next/server to defer to request time.

When to reach for each

The decision is almost always about freshness. Does the data change per-user or per-request? Dynamic, wrapped in Suspense. Does it change occasionally and can be a few minutes stale? Cached with use cache and a cacheLife that matches your tolerance. Never changes between deploys? Leave it static. Get those three buckets right and you get CDN-fast first paint with correct, fresh data streaming in - which used to require picking one or the other.

Every TheKitBase template is built on Next.js 16 with this rendering model already wired up - static shells, cached data layers, and streamed dynamic content, so you inherit the fast-by-default architecture instead of retrofitting it.

The Best Free Next.js Templates in 2026 (Sorted by Use Case)

TheKitBase — Tue, 14 Jul 2026 13:14:16 +0000

There are a lot of free Next.js templates out there, and most "best free templates" lists are just a wall of links with no guidance. This one is sorted by what you're actually building, with the genuinely good free options in each category and an honest note on where free stops being enough. Every pick here is free to use; the premium upgrades are called out where they save real time.

Where to find free templates first

Before any list, know the three sources that cover most needs and are always current because their maintainers keep them updated:

The official Next.js examples repo - dozens of minimal starters for specific integrations (auth, CMS, databases, i18n), maintained alongside the framework
The Vercel Templates directory - a large gallery of free and paid templates you can deploy in one click
shadcn/ui - not a template but a component collection you copy into your project; the fastest way to a good-looking UI from scratch

For marketing sites and landing pages

Free marketing starters get you a hero, features, and a footer, which is enough to validate an idea. What they rarely give you is a complete, cohesive multi-page site with blog, pricing, and auth designed as one system. For a quick landing page, the Vercel and Tailwind free starters are fine; when you need a finished marketing site, that's where a premium template earns its price.

For dashboards and admin panels

shadcn/ui ships an excellent free dashboard example, and it's the best free starting point for an admin UI - charts, tables, and a sidebar you can build on. The gap with free dashboards is depth: you typically get one or two screens, not the 9-12 cohesive pages a real admin panel needs (billing, team, settings, reports). Free gets you the shell; a production template gets you the whole app.

For e-commerce

Next.js Commerce, Vercel's open-source storefront, is the standout free e-commerce starter - a real, deployable store wired for a headless backend. It's an excellent foundation if you're comfortable connecting a commerce backend. For a simpler, static storefront with a working cart and no backend to configure, a focused template will be faster to launch.

For docs and content

Nextra is the go-to free documentation framework on Next.js - MDX, search, and a clean default theme, all open-source. For blogs and content sites, the official Next.js blog examples and any of the many free MDX starters will do the job. Docs is one area where free options are genuinely strong.

For AI apps

Vercel's open-source AI Chatbot template is the best free starting point for anything with a streaming AI interface - it's the reference implementation for the AI SDK and stays current with it. Open SaaS (on the Wasp framework) is a capable free full-stack option with AI examples. Both are great to learn from; neither is a complete, polished SaaS with the product shell around the AI.

For portfolios

Portfolios are the most abundant category of free template - GitHub is full of open-source Next.js portfolio starters, and many are genuinely good. If you want something that stands out from the common grey-on-white developer portfolio, that's where a designed premium template is worth it, but for a solid free portfolio you're spoiled for choice.

When free is enough (and when it isn't)

Free templates are perfect for learning, prototyping, side projects, and anything where your time is worth less than the money saved. They stop being enough when you're shipping something people pay for and your time matters: free templates are usually shallow (a few screens, not a whole product), inconsistent (assembled from parts rather than designed as a system), and yours to finish. A good premium template is the finished system - which is the difference between a weekend of setup and an afternoon of shipping.

Rule of thumb: use free templates to learn and prototype; buy a premium one the moment your time is worth more than the price. A $79 template that saves a week is one of the cheapest hours-back trades in software.

When free stops being enough - see TheKitBase templates from $39

The Ultimate Next.js SaaS Tech Stack for 2026

TheKitBase — Tue, 14 Jul 2026 13:10:27 +0000

The hardest part of starting a SaaS in 2026 isn't writing code - it's choosing the stack. Every layer has five defensible options and a dozen strong opinions. This is an opinionated, boringly reliable stack for building a Next.js SaaS: the choices that let you ship fast, scale sanely, and not rewrite everything in six months. Where there's a real fork, I'll name the alternative and when to take it.

The stack at a glance

Layer	Pick	Strong alternative
Framework	Next.js (App Router)	-
Language	TypeScript (strict)	-
Styling	Tailwind CSS v4	CSS Modules
Components	shadcn/ui	Build your own
Auth	Auth.js	Clerk (managed)
Database	Postgres (Neon) + Drizzle	Supabase / Prisma
Payments	Stripe	Dodo / Lemon Squeezy (MoR)
AI	Vercel AI SDK + Claude	-
Email	Resend	Postmark
Hosting	Vercel	-

Framework, language, and styling

Next.js with the App Router is the default for a reason: server components, server actions, and a single codebase for your marketing site and app. TypeScript in strict mode is non-negotiable for anything you'll maintain - the compile-time safety pays for itself the first time you rename a field. Tailwind CSS v4 for styling, with its @theme token system, makes an entire product reskinnable from a handful of variables and keeps styles colocated with markup.

Auth and database

For auth, Auth.js (formerly NextAuth) is the flexible, self-hosted default; reach for Clerk when you'd rather pay to never think about auth UI, sessions, and organizations again. For data, Postgres is the safe forever-choice - Neon and Supabase both give you serverless Postgres with generous free tiers. Pair it with Drizzle (typed, SQL-first, light) or Prisma (batteries-included, more magic). The through-line: pick managed Postgres and a typed query layer, and you won't outgrow it.

Payments

Stripe is the default and the most capable, and the right pick if you're comfortable handling sales tax and VAT yourself (or with a tax add-on). If you'd rather offload tax and compliance entirely, a merchant-of-record provider like Dodo Payments or Lemon Squeezy handles the tax paperwork globally in exchange for a slightly higher fee - often worth it for a small team selling internationally. Decide based on whether you want to own tax compliance or rent it.

AI, email, and hosting

If your SaaS has an AI feature, the Vercel AI SDK is the standard way to build it - one API across providers, first-class streaming, and an easy swap between models. Point it at Claude for strong reasoning and a clean developer experience. For transactional email (receipts, invites, password resets), Resend is the modern default with a great DX and React-based email templates. And for hosting, Vercel is the path of least resistance for Next.js - zero-config deploys, preview URLs, and edge/serverless handled for you.

AI: Vercel AI SDK + Claude - streaming, provider-agnostic, swap models in one line
Email: Resend - transactional email with React templates
Hosting: Vercel - zero-config Next.js deploys and preview URLs
Analytics: Vercel Analytics or PostHog when you need product analytics + flags

The best stack is the one you don't have to think about. Every pick here is chosen to be reliable and swappable, not clever - so you spend your energy on the product, not on infrastructure decisions you'll second-guess at 2am.

Skip the setup - TheKitBase templates ship on exactly this stack

Next.js vs Astro in 2026: Which Should You Actually Use?

TheKitBase — Tue, 14 Jul 2026 13:03:34 +0000

Next.js and Astro get pitted against each other constantly, which is a little unfair because they were built for different jobs. Next.js is a full-stack React framework for building applications; Astro is a content-first framework for building fast, mostly-static sites. They overlap in the middle - marketing sites, blogs, docs - which is exactly where the choice gets interesting. Here's how they actually differ and a clear rule for deciding.

The core difference: apps vs. content

Next.js assumes you're building an application - interactivity, authentication, dashboards, data that changes per user. It ships React, runs server components, supports server actions and dynamic rendering, and gives you a full backend surface. Astro assumes you're building content - articles, marketing pages, documentation - and optimizes ruthlessly for that: it ships zero JavaScript by default and only hydrates the interactive "islands" you explicitly mark.

	Next.js	Astro
Built for	Full-stack apps	Content-first sites
Default JS shipped	React runtime	Zero (islands opt-in)
Rendering	SSR, SSG, ISR, RSC	Static-first, SSR available
UI framework	React	Any (React, Vue, Svelte) or none
Best fit	Dashboards, SaaS, auth'd apps	Blogs, docs, marketing

Performance: Astro's home turf

For a content site with little interactivity, Astro is hard to beat on raw performance because it ships almost no JavaScript - the browser gets HTML and CSS and nothing to parse and execute. Next.js has closed much of the gap with React Server Components, which keep non-interactive components off the client, and a well-built Next.js content site scores excellently. But if your page is genuinely mostly static content, Astro's zero-JS default gives it a structural head start.

Where Next.js pulls ahead

The moment your product becomes an application - users log in, data is personalized, state is complex, you need a real backend - Next.js is the stronger choice. The App Router, server components, server actions, and the enormous React ecosystem are built for exactly this. Astro can do SSR and can embed React islands, but you'd be fighting its content-first grain to build a full SaaS in it.

The rule for picking

Building a blog, docs site, or marketing site that's mostly content - Astro.
Building an app with auth, dashboards, and dynamic data - Next.js.
Building a SaaS whose marketing site and app should share one codebase and stack - Next.js for both keeps it simple.
Not sure and you might grow into an app - Next.js is the safer long-term bet.

It's not really a rivalry - it's a fork in the road. Content site: reach for Astro. Application: reach for Next.js. The trap is picking Astro because it benchmarks faster, then spending months bending it into an app it was never meant to be.

Building an app? Start from a production Next.js foundation

Cursor vs Claude Code vs Copilot: The 2026 AI Coding Tools Compared

TheKitBase — Tue, 14 Jul 2026 12:59:24 +0000

AI-assisted coding stopped being a novelty and became the default way most developers work. By 2026 three tools lead the space, and they're not really the same kind of thing: Cursor is an AI-first editor, Claude Code is an agentic terminal tool, and GitHub Copilot is an assistant that lives inside your existing IDE. They overlap enough to compete and differ enough that the right pick depends on how you actually work. Here's an honest breakdown.

The quick version

Tool	Form factor	Best at	Model
Cursor	AI-first editor (VS Code fork)	Inline editing + in-context chat	Multiple (incl. Claude, GPT)
Claude Code	Agentic terminal / CLI	Autonomous multi-file changes	Claude (Opus / Sonnet)
GitHub Copilot	Plugin for your existing IDE	Completions inside your current setup	Multiple (incl. Claude, GPT)

Cursor - the AI-first editor

Cursor is a fork of VS Code rebuilt around AI. You get everything familiar about VS Code plus deep AI integration: inline edits, a chat that knows your codebase, and an agent mode that can make multi-file changes while you watch. Because it's the editor itself, the AI has rich context about what you're looking at, and the feedback loop is tight - highlight code, describe a change, accept the diff.

Best for developers who want AI woven into the editor, not bolted on
Strong inline editing and codebase-aware chat
You switch editors (from VS Code) to use it
Model choice, with usage-based and subscription pricing tiers

Claude Code - the agentic terminal tool

Claude Code takes a different shape entirely: it lives in your terminal and works agentically. You describe a task in natural language and it explores the codebase, makes changes across many files, runs commands, and iterates - closer to delegating to a capable pair than autocompleting your typing. It's editor-agnostic (your files are just files), which makes it a strong fit for larger, multi-step changes and for developers who live in the terminal.

Best for autonomous, multi-file tasks and refactors you can describe end to end
Editor-agnostic - works alongside whatever you already use
Terminal-native, scriptable, and strong at planning across a codebase
Runs on Claude models; available via subscription and API-based usage

GitHub Copilot - the assistant in your IDE

Copilot is the incumbent and the least disruptive to adopt: it's a plugin for the IDE you already use (VS Code, JetBrains, and others), so nothing about your setup changes. It started as autocomplete and has grown chat and agent capabilities, plus tight integration with GitHub itself - pull requests, issues, and code review. If you don't want to change editors and you live in the GitHub ecosystem, it's the path of least resistance.

Best for staying in your current IDE with zero workflow change
Deep GitHub integration (PRs, issues, review)
Completions, chat, and agent mode across many editors
Predictable per-seat subscription pricing

How to choose

Want AI as the center of your editor and you'll switch from VS Code - Cursor.
Want to delegate whole multi-file tasks from the terminal - Claude Code.
Want to keep your exact IDE and GitHub workflow - Copilot.
Honestly, many developers run two: a completion/edit tool in the editor and an agentic tool for big changes.

Whichever you pick, the same rule applies: AI tools accelerate work within a structure far better than they invent structure from nothing. Start from a real, well-architected foundation and any of these tools becomes dramatically more useful - the coherence is already there for them to build on.

Give your AI tool a real foundation - browse TheKitBase templates