DEV Community: Carlos Oliva Pascual

NestJS vs Fastify (2026): When Full Framework Beats Micro-Framework

Carlos Oliva Pascual — Thu, 13 Aug 2026 09:22:23 +0000

NestJS and Fastify are not competing for the same niche. Fastify is an HTTP framework — routing, request lifecycle, JSON serialization. NestJS is an application framework — all of that plus dependency injection, module encapsulation, decorators, and a strong opinion about how every file should be organized.

The comparison isn't really about performance numbers. It's about whether you want the framework to enforce architecture, or whether your team can enforce it themselves.

Architecture: Yours vs. Theirs

Fastify: You Own the Structure

// src/plugins/db.ts
export const dbPlugin = fp(async (fastify) => {
  const pool = new Pool({ connectionString: process.env.DATABASE_URL })
  fastify.decorate('db', drizzle(pool, { schema }))
  fastify.addHook('onClose', async () => pool.end())
})

// src/routes/users.ts
export const userRoutes: FastifyPluginAsync = async (fastify) => {
  fastify.post('/', {
    schema: {
      body: Type.Object({
        name: Type.String({ minLength: 1 }),
        email: Type.String({ format: 'email' })
      }),
      response: { 201: UserResponse }
    }
  }, async (request, reply) => {
    const existing = await fastify.db.query.users.findFirst({
      where: (u, { eq }) => eq(u.email, request.body.email)
    })
    if (existing) return reply.status(409).send({ error: 'Email already in use' })
    const [user] = await fastify.db.insert(users).values(request.body).returning()
    return reply.status(201).send(user)
  })
}

Clean for senior developers. The risk: on larger teams, architectural drift accumulates over months.

NestJS: Module → Controller → Service

// src/users/users.service.ts
@Injectable()
export class UsersService {
  constructor(
    @InjectRepository(User)
    private readonly userRepo: Repository<User>
  ) {}

  async create(dto: CreateUserDto): Promise<User> {
    const existing = await this.userRepo.findOne({ where: { email: dto.email } })
    if (existing) throw new ConflictException('Email already in use')
    return this.userRepo.save(this.userRepo.create(dto))
  }
}

// src/users/users.controller.ts
@Controller('users')
export class UsersController {
  constructor(private readonly usersService: UsersService) {}

  @Post() @HttpCode(201) @UseGuards(JwtAuthGuard)
  create(@Body() dto: CreateUserDto) {
    return this.usersService.create(dto)
  }
}

A developer joining day one knows exactly where the business logic for any endpoint lives. That predictability has real value on a 10-person team.

Dependency Injection: The Real Differentiator

NestJS's DI container changes how you test:

// NestJS unit test — inject mocks without touching production code
describe('UsersService', () => {
  const mockRepo = {
    findOne: jest.fn(),
    create: jest.fn((dto) => dto),
    save: jest.fn((user) => ({ id: 'uuid-123', ...user }))
  }

  beforeEach(async () => {
    const module = await Test.createTestingModule({
      providers: [
        UsersService,
        { provide: getRepositoryToken(User), useValue: mockRepo }
      ]
    }).compile()
    service = module.get(UsersService)
  })

  it('throws ConflictException when email is taken', async () => {
    mockRepo.findOne.mockResolvedValueOnce({ id: 'existing' })
    await expect(service.create({ name: 'Test', email: 'taken@test.com' }))
      .rejects.toThrow(ConflictException)
  })
})

Mocking is natural. The DI container handles wiring — tests override what they need without changing anything else.

NestJS + Fastify Adapter

NestJS can run Fastify underneath instead of Express — you get both:

// main.ts
const app = await NestFactory.create<NestFastifyApplication>(
  AppModule,
  new FastifyAdapter({ logger: true })
)
app.useGlobalPipes(new ValidationPipe({ whitelist: true, transform: true }))
await app.listen(3000, '0.0.0.0')

Throughput improvement: ~30-50% more req/s on JSON-heavy routes. Verify Express-specific middleware compatibility before switching an existing app.

Performance

Setup	~Throughput
Fastify standalone	~75,000 req/s
NestJS + Fastify adapter	~50,000 req/s
NestJS + Express (default)	~28,000 req/s

Context: NestJS's DI resolves at startup, not per request. For most production APIs, database latency (5-50ms) dominates over framework overhead (0.1-0.5ms). The gap matters at 10k+ sustained req/s.

Auto-Generated Swagger

NestJS's killer feature for enterprise APIs:

export class CreateUserDto {
  @ApiProperty({ description: 'Full name', minLength: 1 })
  @IsString() @MinLength(1)
  name: string

  @ApiProperty({ format: 'email' })
  @IsEmail()
  email: string
}
// swagger-ui at /api — no separate spec file to maintain

Decision Framework

Choose Fastify if:

Small team (1-5 devs) with strong architectural discipline
Maximum throughput, minimal abstraction overhead
Microservice with a clear, bounded scope
Migrating from Express and want a familiar model with real performance gains

Choose NestJS if:

Team of 5+ with mixed experience levels
You need enforced architecture to prevent drift at scale
Enterprise features: microservices, GraphQL, WebSockets, gRPC out of the box
Coming from Spring Boot or Angular — mental model maps directly
Auto-generated Swagger without maintaining a spec

Choose NestJS + Fastify adapter if:

You want NestJS's structure but need better throughput than Express delivers

Full article at stacknotice.com/blog/nestjs-vs-fastify-2026

tRPC vs Hono RPC (2026): End-to-End Type Safety Without the Setup Tax

Carlos Oliva Pascual — Wed, 12 Aug 2026 15:10:40 +0000

The problem both tools solve is the same: you write an API in TypeScript and your frontend immediately knows the types — request shape, response shape, errors — without a code generation step, without an OpenAPI schema, without a shared types package you have to keep synchronized manually.

The implementation is very different.

tRPC builds on React Query and has deep Next.js integration. The client is a React Query wrapper — you get caching, background refetching, and optimistic updates automatically. Hono RPC is lighter. It generates a typed fetch client from your route definitions, works with any TypeScript consumer (React, Vue, Svelte, React Native, plain Node.js scripts), and runs on Cloudflare Workers, Bun, and Deno with zero changes.

The Core Model

tRPC: Procedures on a Router

// server/routers/users.ts
export const usersRouter = router({
  getById: publicProcedure
    .input(z.object({ id: z.string().cuid() }))
    .query(async ({ input }) => {
      const user = await db.user.findUnique({ where: { id: input.id } })
      if (!user) throw new TRPCError({ code: 'NOT_FOUND', message: 'User not found' })
      return user
    }),

  create: protectedProcedure
    .input(z.object({
      name: z.string().min(1).max(100),
      email: z.string().email(),
    }))
    .mutation(async ({ input, ctx }) => {
      const existing = await db.user.findUnique({ where: { email: input.email } })
      if (existing) throw new TRPCError({ code: 'CONFLICT', message: 'Email already in use' })
      return db.user.create({ data: { ...input, createdBy: ctx.session.userId } })
    }),
})

export type AppRouter = typeof appRouter

The AppRouter type carries the entire API contract to the client.

Hono RPC: Routes as Types

// server/routes/users.ts
const users = new Hono()
  .get('/:id', async (c) => {
    const user = await db.user.findUnique({ where: { id: c.req.param('id') } })
    if (!user) return c.json({ error: 'Not found' }, 404)
    return c.json(user)
  })
  .post(
    '/',
    requireAuth,
    zValidator('json', z.object({ name: z.string().min(1), email: z.string().email() })),
    async (c) => {
      const body = c.req.valid('json')
      const existing = await db.user.findUnique({ where: { email: body.email } })
      if (existing) return c.json({ error: 'Email already in use' }, 409)
      return c.json(await db.user.create({ data: body }), 201)
    }
  )

const app = new Hono().route('/users', users)
export type AppType = typeof app

Client Integration

tRPC: React Query Under the Hood

// components/UserList.tsx
export function UserList() {
  const utils = trpc.useUtils()
  const { data, isLoading } = trpc.users.list.useQuery({ page: 1, limit: 20 })

  const createUser = trpc.users.create.useMutation({
    onSuccess: () => utils.users.list.invalidate()
  })

  // Cache invalidation, loading states, background refetch — all free
}

Hono RPC: Typed Fetch, You Handle Caching

// lib/client.ts
export const client = hc<AppType>('http://localhost:3000')

// components/UserList.tsx — React Query wired manually
const { data } = useQuery({
  queryKey: ['users', 1],
  queryFn: async () => {
    const res = await client.users.$get({ query: { page: '1', limit: '20' } })
    return res.json()  // fully typed
  }
})

Non-React Clients

Hono RPC's clear advantage:

// Vue 3
const { data } = await useAsyncData('users', () =>
  client.users.$get({ query: { page: '1' } }).then(r => r.json())
)

// Node.js seeding script
const client = hc<AppType>('http://localhost:3000')
await client.users.$post({ json: { name: 'Seed', email: 'seed@example.com' } })

// Server-to-server microservice call
const user = await internalClient.users[':id'].$get({ param: { id } }).then(r => r.json())
// Fully typed response — no manual type assertions

Subscriptions

tRPC wins here — first-class support:

// tRPC — real-time with subscriptions
const notificationsRouter = router({
  onNewMessage: publicProcedure
    .input(z.object({ roomId: z.string() }))
    .subscription(async function* ({ input }) {
      for await (const message of subscribeToRoom(input.roomId)) {
        yield message
      }
    })
})

// Client
trpc.notifications.onNewMessage.useSubscription(
  { roomId: 'room-123' },
  { onData: (msg) => setMessages(prev => [...prev, msg]) }
)

Hono handles real-time via SSE separately from the RPC layer.

Decision Framework

Situation	Choose
Next.js app, React-heavy frontend	tRPC
Already using React Query	tRPC
Need real-time subscriptions	tRPC
Non-React clients (Vue, Svelte, React Native)	Hono RPC
Edge deployment (Cloudflare Workers, Bun)	Hono RPC
Server-to-server API calls	Hono RPC
Multi-runtime backend	Hono RPC

Both are better than maintaining an OpenAPI schema or a shared types package that drifts. The choice is about what already exists in your stack — not which API is more elegant.

Full article at stacknotice.com/blog/trpc-vs-hono-rpc-2026

Hono vs Express vs Fastify (2026): Which Node.js Framework Is Actually Faster?

Carlos Oliva Pascual — Wed, 12 Aug 2026 08:08:58 +0000

Choosing a Node.js backend framework in 2026 means choosing between three tools with very different priorities. Express optimizes for familiarity. Fastify optimizes for Node.js performance. Hono optimizes for portability across runtimes.

Performance: The Numbers That Matter

Framework	Throughput	Latency
Hono (Node.js)	~85,000 req/s	~0.5ms
Fastify	~75,000 req/s	~0.6ms
Express	~30,000 req/s	~1.4ms
Hono (Bun)	~130,000+ req/s	~0.3ms

Express is ~2-3x slower than Fastify and Hono. The gap is real but only meaningful at scale (10k+ req/s). For most apps, database query time dominates.

Express — The Incumbent

import express from 'express'
import { z } from 'zod'

const app = express()
app.use(express.json())

app.post('/users', async (req, res) => {
  const parsed = createUserSchema.safeParse(req.body)
  if (!parsed.success) return res.status(400).json({ errors: parsed.error.flatten() })

  const user = await db.user.create({ data: parsed.data })
  res.status(201).json(user)
})

No built-in TypeScript. No built-in validation. No built-in serialization. You bring everything. That's also why there's an Express middleware for virtually every use case.

Choose Express when: legacy codebase, team already knows it, or you need a specific middleware with no alternative.

Fastify — Best Throughput on Node.js

Fastify compiles a serializer from your JSON Schema at startup — 2-3x faster than JSON.stringify. TypeScript is first-class.

import Fastify from 'fastify'
import { Type } from '@sinclair/typebox'

const fastify = Fastify({ logger: true })

fastify.post('/users', {
  schema: {
    body: Type.Object({
      name: Type.String({ minLength: 1 }),
      email: Type.String({ format: 'email' })
    }),
    response: {
      201: Type.Object({ id: Type.String(), name: Type.String(), email: Type.String() })
    }
  }
}, async (request, reply) => {
  // request.body is fully typed from schema
  const user = await db.user.create({ data: request.body })
  reply.status(201).send(user)
})

The schema does two things: validates input at runtime AND compiles the response serializer. One definition, both benefits.

Plugin system with fastify-plugin:

import fp from 'fastify-plugin'

export const authPlugin = fp(async (fastify) => {
  fastify.decorate('authenticate', async (request, reply) => {
    const token = request.headers.authorization?.replace('Bearer ', '')
    if (!token) return reply.status(401).send({ error: 'Unauthorized' })
    request.user = verifyJWT(token)
  })
})

Choose Fastify when: staying on Node.js, schema-first development with TypeBox, need maximum throughput without leaving Node.

Hono — Runs Everywhere

Hono is built on web standards (Request, Response, Headers). The same code runs on Node.js, Bun, Cloudflare Workers, Deno, and AWS Lambda Edge.

import { Hono } from 'hono'
import { zValidator } from '@hono/zod-validator'
import { z } from 'zod'

const app = new Hono()

app.post(
  '/users',
  zValidator('json', z.object({ name: z.string(), email: z.string().email() })),
  async (c) => {
    const body = c.req.valid('json')  // fully typed
    const user = await db.user.create({ data: body })
    return c.json(user, 201)
  }
)

export default app  // same export on Node, Bun, or Cloudflare Workers

Built-in middleware that covers most APIs:

import { cors } from 'hono/cors'
import { logger } from 'hono/logger'
import { jwt } from 'hono/jwt'
import { rateLimiter } from 'hono-rate-limiter'

app.use('*', logger())
app.use('*', cors({ origin: 'https://myapp.com' }))
app.use('/api/*', jwt({ secret: process.env.JWT_SECRET! }))

RPC with end-to-end type safety (no code generation):

// server.ts
const routes = new Hono()
  .get('/users/:id', async (c) => c.json(await getUser(c.req.param('id'))))

export type AppType = typeof routes

// client.ts
import { hc } from 'hono/client'
const client = hc<AppType>('http://localhost:3000')

const user = await client.users[':id'].$get({ param: { id: '123' } })
// Fully typed response — no API schema file needed

Choose Hono when: multi-runtime (Cloudflare Workers, Bun, Deno), edge deployments, you want tRPC-like type safety without the setup, or you're on Bun and want maximum performance.

The Same Endpoint in All Three

// Express
app.post('/posts', async (req, res) => {
  const parsed = schema.safeParse(req.body)
  if (!parsed.success) return res.status(400).json({ error: parsed.error })
  const post = await db.post.create({ data: parsed.data })
  res.status(201).json(post)
})

// Fastify
fastify.post('/posts', {
  schema: { body: PostBody, response: { 201: PostResponse } }
}, async (request, reply) => {
  const post = await db.post.create({ data: request.body })
  reply.status(201).send(post)
})

// Hono
app.post('/posts', zValidator('json', schema), async (c) => {
  const post = await db.post.create({ data: c.req.valid('json') })
  return c.json(post, 201)
})

Fastify wins on compiled performance. Hono wins on portability and conciseness. Express requires the most boilerplate for equivalent safety.

Decision Framework

Situation	Choose
Legacy Express codebase	Express
New project, Node.js only, max throughput	Fastify
New project, multi-runtime or edge	Hono
Using Bun	Hono
Need RPC-style type safety	Hono
Specific Express middleware with no alternative	Express

Full article at stacknotice.com/blog/hono-vs-express-vs-fastify-2026

OpenAI Codex CLI vs Claude Code (2026): Terminal Coding Agents Compared

Carlos Oliva Pascual — Tue, 11 Aug 2026 12:56:21 +0000

OpenAI entering the terminal-based AI coding agent space with Codex CLI puts two serious tools in direct comparison. Both are CLI agents that read your codebase, edit files, and run shell commands. Both are designed to replace a significant portion of manual coding work. The surface similarity is real. The philosophy is not.

The Foundational Difference

Codex CLI leans toward autonomy. In --full-auto mode, it reads files, makes changes, and runs commands without asking. The assumption is that you've scoped the task correctly and want execution without interruption.

Claude Code leans toward control. Its explicit permission model asks before consequential actions. You can whitelist trusted commands, but the default is to surface what it's about to do before doing it.

Model and API

# Codex CLI
codex --model gpt-4o "add input validation to the signup form"
codex --model o3 "analyze the architecture and suggest improvements"

# Claude Code
claude                              # Sonnet 4.6
claude --model claude-opus-4-6     # Opus — deeper reasoning

Both GPT-4o and Claude Sonnet 4.6 are strong for coding tasks. The model is less the differentiator than the tooling built around it.

Permission Models

Codex CLI: three modes

# Suggest only — show changes, don't apply
codex --approval-mode suggest "refactor the auth module"

# Auto-edit — edit files, ask before commands
codex --approval-mode auto-edit "refactor the auth module"

# Full auto — edit files AND run commands without asking
codex --approval-mode full-auto "refactor the auth module"

Full auto is genuinely different. It will run git commit, npm install, docker build without asking. The speed is real. The risk is also real: a wrong command runs before you see it. Codex mitigates this with a network sandbox in full auto mode.

Claude Code: explicit by default

# Every consequential action asks first:
# > Run command: git push origin main ? [y/n/always/never]

# Grant permanent permission for trusted commands:
claude config add-allowed-command "npm test"

You make trust decisions deliberately, not as a mode toggle. For production codebases, this is not friction — it's the point.

Context and Project Understanding

Codex CLI: git history + explicit files

codex "fix the failing tests" src/auth.ts src/__tests__/auth.test.ts
codex "what changed in the last three commits causing the 401 errors"

Context is session-scoped: what you pass in explicitly.

Claude Code: CLAUDE.md — persistent across sessions

# Project Context
## Stack
- Next.js 15, TypeScript strict, Drizzle ORM + Neon, Clerk, Bun
## Key files
- /src/lib/auth.ts — Clerk JWT validation
- /src/lib/db/schema.ts — Full Drizzle schema
## Constraints
- Never use `any`. Ask before installing packages.

Loads automatically every session. Set up once, works indefinitely.

Features Unique to Each

Codex CLI has:

MIT open source — inspect, fork, contribute, self-host
Full auto mode — zero-interruption execution
Network sandbox — blocks unintended network calls
o3 reasoning — OpenAI's deep reasoning model
Community extensions — growing open source ecosystem

Claude Code has:

Plan Mode — review approach before any code is written
Parallel subagents — multiple Claude instances on different parts of a task
Hooks system — run commands automatically on events
CLAUDE.md hierarchy — global + project + subdirectory context
Ultrathink — extended reasoning for the hardest problems
Headless mode — non-interactive execution for CI/automation

Plan Mode is the most significant daily differentiator. Before writing code, Claude produces a detailed plan of what it intends to do. You review and redirect before implementation — preventing the expensive failure mode of implementing the wrong approach across many files.

Open Source vs Proprietary

Codex CLI: MIT licensed. Audit the code, self-host, modify for internal use. For teams with security requirements around AI tooling, this matters.

Claude Code: Proprietary. Anthropic controls the implementation.

Decision Framework

Choose Codex CLI if:

Open source is a hard requirement
You want full auto mode for trusted environments
You want GPT-4o or o3 specifically
You want to contribute to or customize the agent itself

Choose Claude Code if:

You're already on Claude Max (no marginal cost per task)
Plan Mode is valuable — reviewing approach before implementation
You need subagents for parallel large-codebase work
The hooks system fits your automation needs
Persistent CLAUDE.md context across sessions matters

Both can coexist: Codex CLI for fast trusted dev, Claude Code for sensitive production work or complex reasoning tasks.

Full article at stacknotice.com/blog/openai-codex-vs-claude-code-2026

Aider vs Claude Code (2026): Which CLI Coding Agent Should You Use?

Carlos Oliva Pascual — Tue, 11 Aug 2026 07:17:02 +0000

If you've decided you want an AI coding agent that runs in your terminal, you're choosing between two serious tools: Aider and Claude Code. Both edit files, run commands, and work across your codebase autonomously. But the philosophy behind each is different, and that difference shows up in daily use.

The Essential Difference

Aider is model-agnostic and open source. It works with GPT-4o, Claude, Gemini, Llama, and most models with an API. It focuses on doing one thing well — editing code with any capable LLM.

Claude Code is tightly integrated with Claude. It's built to use Claude's specific capabilities: extended thinking, subagents, Plan Mode, the hooks system, and CLAUDE.md context files. Richer feature set, but only runs on Claude.

Model Flexibility

Aider: any model, your choice

aider --model gpt-4o
aider --model claude-sonnet-4-6
aider --model gemini/gemini-2.0-flash
aider --model ollama/llama3.2  # Local, free

Aider lets you mix models. If Claude's pricing increases or a better model releases, you switch a flag. For cost-sensitive teams or developers who want local models with no API cost at all, Aider wins here clearly.

Claude Code: Claude only

claude                           # Sonnet 4.6 (default)
claude --model claude-opus-4-6  # Opus

You're staying in the Claude ecosystem. The advantage: Claude Code is optimized specifically for Claude's strengths — features like extended thinking (ultrathink), Plan Mode, and parallel subagents are built around how Claude reasons.

Git Integration

Aider: automatic commits by default

Aider commits after every change with AI-generated messages:

aider src/auth.ts
# After each edit, Aider auto-commits:
# "feat: add JWT validation for custom org_id claim"
# "fix: handle null case in token refresh"

Clean git history of every AI change. git revert any wrong change instantly. This is a real safety net for aggressive AI editing.

Claude Code: explicit git control

Claude Code makes file changes and you control commits:

claude
# Claude edits files during the session
git add -p && git commit -m "feat: add JWT validation"

More control over what ends up in commits. The tradeoff: you have to remember to commit.

Context and Codebase Understanding

Aider: repo map

Aider scans your repository and builds a compressed representation of your codebase's structure, functions, and relationships. Effective for large codebases — understands the big picture without reading every file in full.

Claude Code: CLAUDE.md

Claude Code reads files explicitly. The alternative to Aider's repo map is CLAUDE.md — a file you write and maintain that gives Claude a high-level understanding:

# Key Architecture
- Auth: /src/lib/auth.ts (Clerk JWT validation)
- DB: /src/lib/db/ (Drizzle ORM + Neon)
- API: /src/app/api/ (Next.js route handlers)

Aider's approach: automatic but approximate. Claude Code's approach: requires maintenance but gives precise control.

Permission Model

Aider: permissive by default

Edits files and runs commands with minimal confirmation. Designed to move fast.

Claude Code: explicit approval

Asks before running commands, before modifying files outside allowed scope:

# Claude Code prompts:
# > Run command: git push origin feature/auth-refactor ?
# [y/n/always/never]

# Grant permanent permission for trusted commands:
claude config add-allowed-command "npm test"

For production codebases where a wrong command has real consequences, the explicit model is not friction — it's the point.

Features Unique to Each

Aider has:

Any LLM including local (Ollama = free)
Automatic git commits with AI messages
Open source — inspect and modify the tool itself
Voice mode (experimental)

Claude Code has:

Plan Mode — review approach before any code is written
Parallel subagents — spawn multiple Claude instances on different tasks
Hooks system — run commands automatically on events (pre-save, post-tool-use)
CLAUDE.md hierarchy — global + project + subdirectory context files
Ultrathink — extended reasoning for the hardest problems
Headless mode — non-interactive execution for CI/automation

These Claude Code features have no Aider equivalent. Plan Mode alone prevents expensive wrong implementations. Subagents let you parallelize large codebase work.

Daily Workflow

A typical Aider session

aider src/api/users.ts src/lib/auth.ts

> Add rate limiting to the users endpoint using the existing Redis client

# Aider edits, auto-commits
# "feat: add rate limiting to users endpoint"

> The test is failing — fix it

# Aider reads the test, fixes, auto-commits

Lightweight, fast, minimal friction. Auto-commit history is a clean record.

A typical Claude Code session

claude

"Add rate limiting to /src/app/api/users/route.ts using the Redis
client in /src/lib/redis.ts. Limit: 100 req/min per user ID.
Add a test in /src/__tests__/api/users.test.ts."

# Claude reads relevant files, asks permission to run: npm test
# Makes changes, runs tests, confirms they pass

More explicit, more controlled.

Which One to Use

Choose Aider if:

Model flexibility matters — especially local models or non-Claude APIs
Auto-commit git history is important to your workflow
Cost is a primary constraint
You prefer open source tools

Choose Claude Code if:

You're already on Claude Max (no marginal cost per task)
You need Plan Mode, subagents, or hooks
Sensitive codebase where explicit permissions matter
Complex multi-step tasks that benefit from parallel execution

Use both: Aider for quick edits with a cheap/local model, Claude Code for complex reasoning tasks that benefit from Claude's specific capabilities.

Full article at stacknotice.com/blog/aider-vs-claude-code-2026

Claude Code Token Usage: Cut Costs 40-60% Without Losing Quality (2026)

Carlos Oliva Pascual — Mon, 10 Aug 2026 07:04:24 +0000

Token cost is the hidden tax on AI-assisted development. A focused coding session with Claude Code can consume thousands of tokens in minutes — and an unfocused one can consume ten times as many for the same output. The difference comes from habits that either burn tokens or preserve them.

The Biggest Lever: Model Selection

The single highest-impact thing you can do is use the right model for each task.

Sonnet 4.6 and Opus 4.6 produce nearly identical output for 80-90% of coding tasks. Opus genuinely outperforms Sonnet only in specific cases: multi-file bugs with indirect causation, architecture decisions, security review.

# Default: Sonnet (fast, cost-effective)
claude

# Only when you need deeper reasoning
claude --model claude-opus-4-6

The rule: start every session in Sonnet, switch to Opus only when Sonnet fails on the same problem twice. Using Opus by default for ordinary tasks is the most common way Claude Code users overspend.

Context Window: The Compounding Leak

Every message includes the full conversation history up to that point. As a session grows longer, each subsequent message gets more expensive — not because the new message is bigger, but because the accumulated context is.

`/compact` — Summarize and Continue

When a session is getting long but you're not done:

/compact

Replaces conversation history with a compressed summary. You lose exact phrasing but keep important decisions and context. Much cheaper per subsequent message.

Use /compact when: session has been running 45+ minutes, or you're starting a new subtask.

`/clear` — Start Clean

/clear

Wipes the conversation entirely. Next message starts with zero accumulated context — only your CLAUDE.md. Use this when moving to a completely unrelated task.

CLAUDE.md: Tokens You Never Spend Twice

Every time you re-explain your stack or conventions, you're spending tokens you already spent in a previous session.

# Project Context

## Stack
- Next.js 15, TypeScript strict, Drizzle ORM + Neon, Clerk, Bun

## Conventions
- Server actions in /src/actions/ — never inline mutations in components
- No Prisma, no NextAuth, no npm (use Bun)

## Key files
- /src/lib/db/schema.ts — full Drizzle schema
- /src/lib/auth.ts — Clerk session helpers

A 300-token CLAUDE.md that saves a 150-token re-explanation per session pays for itself in 2 sessions. Infinite return from session 3 onward.

Specific Prompts Beat Vague Requests

Vague prompts force Claude to explore before executing. Exploration costs tokens.

Vague (expensive):

"Fix the auth stuff"

Claude has to figure out what "auth stuff" means, read multiple files trying to identify the problem, make assumptions, possibly go down the wrong path.

Specific (efficient):

"The JWT validation in /src/lib/auth.ts line 47 fails when the token
contains a custom claim. The claim key is 'org_id'. Fix the validation
to accept it."

Claude reads one file, makes one targeted change. Done.

The pattern: tell Claude exactly what file, what function, what the expected behavior is, and what the current failure is. The more context you provide upfront, the less Claude has to spend tokens discovering it.

Plan Mode for Complex Tasks

For tasks that touch multiple files or have non-obvious scope, Plan Mode is more token-efficient than direct execution:

claude --plan
# Review the plan before any tokens are spent on wrong code
# Redirect if the approach is wrong (costs almost nothing)
/execute  # Execute once confident — first-attempt success

One failed multi-file refactor with two correction rounds costs 4-5x what a planned implementation would have. Use Plan Mode for anything touching 3+ files.

Batch Related Changes

Each message exchange has overhead — the context is re-sent, Claude processes the full history. Sending 10 separate single-instruction messages costs 10x the overhead of one message with 10 instructions.

Inefficient:

"Add email validation"
"Add password validation"
"Add loading state"
"Add error display"

Efficient:

"Do these four things in the signup form:
1. Email validation (format + required)
2. Password validation (min 8 chars + required)
3. Loading state on submit button
4. Error message display below each field"

Same output, ~25% the overhead.

What Costs More Than You Think

Asking Claude to explore: "What's the best way to handle X?" requires reading files, reasoning about options, writing a detailed answer. Use sparingly.
Correction cycles: Every "no, not like that" correction costs as much as the wrong response. Better prompts upfront are cheaper than corrections.
Leaving sessions running: A session doesn't get cheaper as the day goes on — it gets more expensive per message as history accumulates.
Unnecessary file reads: "Read the whole codebase" is expensive. Do it once and capture the useful parts in CLAUDE.md.

The Token Efficiency Checklist

Before starting a task:

[ ] Using Sonnet? (switch to Opus only if needed)
[ ] Is CLAUDE.md current? (no re-explaining context)
[ ] Prompt specific enough that Claude won't explore?
[ ] Should I use Plan Mode? (3+ files, non-obvious scope)
[ ] Can I batch multiple changes into one message?

During a long session:

[ ] Running 45+ minutes? → /compact
[ ] Starting an unrelated task? → /clear

Applied consistently, these habits reduce token consumption by 40-60% compared to unstructured usage — with no reduction in output quality.

Full article at stacknotice.com/blog/claude-code-token-usage-optimization

Claude Code: CLAUDE.md vs Projects vs Memory — Which Persists What?

Carlos Oliva Pascual — Fri, 07 Aug 2026 11:32:03 +0000

The most common frustration with Claude Code is re-explaining the same context at the start of every session. "We use Drizzle, not Prisma." "Don't use any in TypeScript." "The auth is in /src/lib/auth.ts."

Claude has three mechanisms for remembering across sessions. They solve different problems and are appropriate in different situations. Using the wrong one means either re-explaining constantly or contaminating context you didn't want shared.

The Three Mechanisms at a Glance

	CLAUDE.md	Projects	Memory
Scope	Per project / directory	Per Claude.ai Project	Global across all conversations
Where it lives	Your filesystem	Claude's servers	Claude's servers
Shared with team	✅ Yes (git)	❌ No	❌ No
Works in Claude Code CLI	✅ Primary method	✅ When in a Project	⚠️ Limited
Works in Claude.ai web	❌ No	✅ Yes	✅ Yes

CLAUDE.md — The Primary Tool for Claude Code

CLAUDE.md is a Markdown file that Claude Code reads automatically at the start of every session. Write it once, and it persists forever, version-controlled, team-shared.

Hierarchical structure

~/.claude/CLAUDE.md          # Global — applies to every project
~/projects/myapp/CLAUDE.md   # Project-level — this project only
~/projects/myapp/src/CLAUDE.md  # Subdirectory — extra context for src/

What to put in it

# MyApp — Claude Context

## Stack
- Next.js 15 App Router, TypeScript strict mode
- Drizzle ORM with Neon Postgres (NOT Prisma)
- Clerk for authentication (NOT NextAuth)
- Bun as package manager (NOT npm or yarn)

## Conventions
- API routes go in /src/app/api/
- Server actions go in /src/actions/ with 'use server'
- Database queries go in /src/lib/db/ — never inline in components
- Never use `any`. Use `unknown` with type guards instead.

## Key Files
- /src/lib/auth.ts — Clerk auth helpers and session logic
- /src/lib/db/schema.ts — Complete Drizzle schema

## What to Avoid
- Don't install new packages without asking first
- Don't modify schema.ts without mentioning the migration

This loads into every Claude Code session. Claude knows your stack, conventions, and constraints without you saying anything.

Global CLAUDE.md for personal preferences

# Global Preferences (~/.claude/CLAUDE.md)

- TypeScript strict mode always on
- Prefer explicit return types on public functions
- Use early returns over nested conditionals
- Show the plan before implementing large changes
- Ask before installing packages I didn't mention

The team advantage

CLAUDE.md committed to git gives every developer on the team the same starting context. New developer joins → they clone the repo → Claude Code already knows the conventions. Update a convention → update the file → everyone picks it up next session.

This is what neither Projects nor Memory can do. They're personal, not shared.

Claude Projects — Conversation History That Persists

Projects maintain persistent conversation history across sessions. You can also upload files — PDFs, specs, architecture docs — and Claude references them throughout the Project's lifetime.

What Projects persist

Conversation history — previous exchanges available as context
Uploaded files — documents and specs you've added
Project instructions — a persistent system prompt you define

When Projects add value

Projects are useful when you need the history of decisions, not just the current state of the codebase:

Long-running features where previous decisions inform new ones
Debugging sessions where you need to remember what you've already tried
Architecture work where the reasoning behind choices matters

The key distinction: CLAUDE.md tells Claude what your codebase is like right now. Projects tell Claude what you've discussed and decided over time.

Projects are personal — your team doesn't get your accumulated context.

Memory — Personal Facts Across All Conversations

Memory is the simplest: ask Claude to remember something, and it does — across all your conversations, regardless of project.

"Remember that I prefer tabs over spaces in all my projects."
"Remember that my main database is on Railway, not local."

What Memory is good for

Personal preferences that don't belong in a project's CLAUDE.md because they're about you, not the project:

Communication style preferences
Cross-project personal conventions
Work context ("I'm currently focused on the payments feature")

What Memory is bad for

Technical project context. Memory is global and can create conflicts across projects. "Use Drizzle not Prisma" in Memory might bleed into unrelated projects. Use CLAUDE.md for project-specific technical context.

In Claude Code CLI, CLAUDE.md is the equivalent of Memory — more precise, version-controlled, and project-scoped.

The Right Tool for Each Situation

Use CLAUDE.md when:

Context applies every time you open Claude Code in this project
It's technical: stack, conventions, file structure, constraints
You want your team to share the same context

Use Projects when:

Extended work across many sessions where history matters
You've uploaded reference documents Claude needs to consult
You need a running record of decisions and reasoning

Use Memory when:

It's a personal preference, not a project constraint
Context applies across all your work
You're in Claude.ai web interface

The Practical Setup for a New Project

touch CLAUDE.md

Fill it with:

Stack — every library and framework, including what you're NOT using
Conventions — naming, file organization, patterns
Key files — where the important pieces live
Constraints — things Claude should ask about before doing

Commit it on day one. From that point forward, every session starts with full context.

Why Most Developers Under-Use CLAUDE.md

The most common mistake: treating CLAUDE.md as documentation — writing it once and never updating it.

CLAUDE.md is a living document. Every time you make an architectural decision, add it. Every time Claude makes a wrong assumption about your stack, correct it in the file. Every time you establish a new convention, write it down.

The developers who get consistent output from Claude Code are the ones who maintain a detailed CLAUDE.md. Not because Claude is smarter with it — because it's not making assumptions about your project. It knows.

Full article at stacknotice.com/blog/claude-code-memory-vs-projects-vs-claude-md

Claude Code Plan Mode: What It Is and When to Actually Use It (2026)

Carlos Oliva Pascual — Fri, 07 Aug 2026 08:05:09 +0000

Most Claude Code users discover Plan Mode by accident — they run a command with --plan or type /plan in a session and Claude starts writing a numbered list instead of code. The instinct is to dismiss it as an extra step and go back to direct execution.

That instinct is wrong for a specific class of tasks.

What Plan Mode Actually Does

In normal Claude Code operation, you describe what you want and Claude starts writing code immediately. Plan Mode inserts a step between your instruction and any code changes. Claude reads all relevant files and context, then produces a written plan — what it intends to do, in what order, with what tradeoffs. No files are modified. No commands are run.

# Start a session in Plan Mode
claude --plan

# Or switch mid-session
/plan

# Once you've reviewed and approved the plan
/execute

The plan Claude produces is specific:

Which files it intends to modify
What changes it plans to make to each
Any new files it will create
Commands it expects to run
Potential risks or places where it's uncertain

The Problems Plan Mode Solves

Wasted implementation on the wrong approach

The most expensive failure mode is when Claude picks an approach, implements it across a dozen files, and you realize at the end it was the wrong architecture.

"Add email notifications when a user's subscription expires" sounds clear. But the correct implementation depends on whether you have a job queue, what email service you use, whether you need idempotency. Claude will make assumptions. Without Plan Mode, you find out what those assumptions were after the code is written.

With Plan Mode, you read: "I plan to use a cron job that runs daily and sends via Resend." At that point you can say "we use BullMQ, not cron" before anything is touched.

Multi-file refactors with unclear scope

When a refactor touches many files, the first thing you need is a map of what changes. Plan Mode produces exactly this:

Planned changes for auth middleware refactor:

1. src/middleware.ts — Extract token validation to validateToken()
2. src/lib/auth.ts — Add validateToken() function, update types
3. src/app/api/auth/[...nextauth]/route.ts — Remove duplicated validation
4. src/app/api/webhooks/stripe/route.ts — Use shared validateToken()

Risk: The Stripe webhook uses a different validation path
that might need special handling — I'll flag this in implementation.

Reading this takes 30 seconds and tells you whether Claude's mental model of your codebase is correct before it starts touching files.

High-stakes changes

Auth flows, payment processing, data migrations, security-sensitive paths — Plan Mode gives you a formal review step that matches the stakes of the change.

When Plan Mode Gets in the Way

Plan Mode is overhead on tasks where the scope is small and the risk is low.

Skip Plan Mode for:

Single-file, well-defined changes
Boilerplate generation and scaffolding
Iterative refinement in a tight feedback loop
Anything under 5 minutes to redo if wrong

The practical test: if you can describe what you want in one sentence and you'd recognize a correct implementation immediately — skip Plan Mode.

The Plan → Review → Execute Workflow

claude --plan

"I need to add multi-tenancy to the API. Each user belongs to an
organization, all data filtered by org_id, Row-Level Security at
the Postgres level. Current schema is in /prisma/schema.prisma.
Start by planning the approach."

When Claude produces the plan, read it critically:

Does it understand the existing structure correctly?
Are the files it plans to touch the right ones?
Has it missed anything?
Are its assumptions about your stack correct?

If the plan is wrong, redirect in plain language:

"The plan looks right but you're missing the webhook handlers in
/src/app/api/webhooks — those also query the database and need
the org_id filter."

Claude revises. You iterate until it's correct. Then:

/execute

Plan Mode and Token Cost

A common concern: does Plan Mode cost more?

The planning step does consume tokens. But failed implementations cost tokens too — reading files, writing wrong code, running failing tests, attempting corrections. A single botched refactor requiring multiple correction attempts easily costs 3–5x what a successful planned implementation costs.

For tasks touching more than 3 files or with non-obvious dependencies, Plan Mode is almost always more token-efficient than direct execution.

Plan Mode With Subagents

Before spinning up parallel subagents on different parts of a large task, a planning phase in the orchestrator ensures each subagent has clear, non-overlapping scope:

claude --plan

"We need to add a notification system: email via Resend,
in-app via a notifications table, and push via Expo.
Plan how to split this across parallel subagents
with no shared file conflicts."

Once you approve the coordination map, spawn the subagents knowing their work won't collide.

The Decision Framework

One question determines whether to use Plan Mode: "Would I want to review an approach document before this work starts?"

If yes in a human-to-human collaboration → yes with Claude. Plan Mode is that approach document, produced in seconds, reviewable before a single change is made.

The developers who get the most out of Claude Code treat it like a collaborator that needs a brief — not an executor that needs instructions. Plan Mode is how you write the brief.

Full article at stacknotice.com/blog/claude-code-plan-mode-guide-2026

Claude Code vs Cursor Agent Mode (2026): Same Model, Very Different Tool

Carlos Oliva Pascual — Thu, 06 Aug 2026 07:31:50 +0000

A question that comes up constantly when developers discover Claude Code: "I already have Cursor — do I need Claude Code too? Aren't they basically the same thing?"

They're not the same thing. They solve overlapping problems using the same underlying model, but the architecture is different, the control model is different, the daily workflow is different, and they excel in completely different situations.

The Surface-Level Answer

Cursor is an IDE. It wraps VS Code with AI capabilities built in: inline completions, a chat panel, Agent Mode that executes multi-step tasks, and deep integration with the editor you're already using.

Claude Code is a CLI agent. It lives in your terminal, has direct access to your filesystem and shell, can run commands, read files anywhere on your machine, and execute tasks without an IDE involved at all.

Both can use Claude Sonnet 4.6 or Opus 4.6 as the underlying model. The model is not the differentiator. The tool architecture is.

How Agent Mode Works in Each

Cursor Agent Mode

Cursor's agent runs inside the IDE:

Opens and reads files from your project
Writes diffs you can review inline before accepting
Runs terminal commands in a panel inside Cursor
Applies changes file by file with a visual diff review step

The UX is optimized for visual review. Every change shows you exactly what's being modified, in context, in the same editor you work in.

Claude Code

Claude Code's agent runs in your terminal:

Reads files anywhere on your filesystem
Runs shell commands directly (npm, pytest, git, docker, curl — anything)
Edits files with your approval at each step
Persists context about your project via CLAUDE.md
Can orchestrate parallel subagents across multiple tasks simultaneously

The UX is optimized for task completion. You give a goal, Claude Code executes it, asks for permission at consequential steps, and delivers the result.

The Permission Model — The Most Important Difference

Cursor: implicit trust within the workspace

Cursor's agent can read and modify files in your open workspace by default. The assumption is that your workspace is your project and the agent should be able to work in it.

Claude Code: explicit, auditable permissions

Before running any command or modifying any file outside of what you've allowed, it asks:

# Claude Code shows what it's about to run and asks:
# > Run command: git push origin feature/auth-refactor ?
# [y/n/always/never]

# Grant permanent permission for safe commands:
claude config add-allowed-command "npm test"

When you're working in a sensitive codebase — production infrastructure, auth code, anything where a silent mistake has real consequences — the explicit permission model is not friction. It's the point.

Context: Where Each Excels

Cursor: current file + open workspace

Cursor is exceptional at understanding what you're currently looking at. It knows your cursor position, the selected code, the current file. When you want help with the specific code you're editing right now, Cursor's context is immediate and relevant.

Claude Code: your whole machine, your whole workflow

Claude Code's context can span your entire filesystem, multiple repositories, shell history, and running processes. Combined with CLAUDE.md files that store permanent project context, it understands your project at a higher level than "what's in the workspace folder".

# Claude Code can run a full workflow:
# 1. Read the failing test output
# 2. Find the source of the failure
# 3. Fix the code
# 4. Run the tests again
# 5. Commit if they pass
# All from one instruction in the terminal, no IDE needed.

Which Scenarios Favor Each

Use Cursor when:

Primarily doing frontend work where visual editor context matters
You want inline completions alongside agent capabilities in the same tool
You're reviewing AI changes visually, accepting/rejecting diffs per file
Working in a single repository with a clear workspace
Your workflow is IDE-centered

Use Claude Code when:

Doing backend, infrastructure, or DevOps work where the terminal is the primary environment
The task involves running commands as part of the work (tests, scripts, migrations, builds)
Working across multiple repositories simultaneously
You want to automate repetitive development tasks via headless scripting
Doing a large refactor spanning many files with parallel subagents
Working on CI or a remote server without a GUI
The work is sensitive and you want the explicit permission model

Do You Need Both?

Yes, and many developers use them together without friction.

The workflow that makes sense: Cursor for in-editor work, Claude Code for everything outside the editor.

When you're writing a new feature, Cursor's inline completions and chat are fast and context-aware. When you need to run a database migration, write a deployment script, fix a failing test suite across three repos, or automate a repeated task — switch to Claude Code in the terminal.

They're not competitors for the same workflow. They address different parts of a developer's day.

Cost and Subscription

Cursor: $20/month for Pro (Claude Sonnet access included)
Claude Code: Requires Claude subscription — included in Claude Max ($100/month), otherwise uses API credits

If you're on Claude Max, Claude Code's cost is part of that subscription. If you're also paying for Cursor Pro, you're paying for both — reasonable if you're using both for different things.

The One-Line Summary

Cursor: AI built into your editor. Best when the work is the file you're looking at.

Claude Code: AI with shell access. Best when the work involves running things, spanning repos, or going beyond what an IDE can reach.

The question isn't which one is better. The question is which one matches the shape of the work you're doing right now. For most developers doing full-stack work, both have a clear role and don't conflict with each other — they just live in different parts of the workflow.

Full article at stacknotice.com/blog/claude-code-vs-cursor-agent-mode-2026

Claude Sonnet 4.6 vs Opus 4.6 for Coding: Which Model Should You Use?

Carlos Oliva Pascual — Wed, 05 Aug 2026 08:48:50 +0000

The most common question from developers who start paying for Claude Max or Claude Pro is always the same: do I actually need Opus, or is Sonnet good enough?

It's not a simple answer. Both models are built on the same architecture. Both write real code. But they make different tradeoffs — and the difference only becomes obvious when you've used both for the same type of work.

The Quick Answer

Use Sonnet 4.6 for 80–90% of your coding work. It's faster, it costs less, and it handles the vast majority of tasks without any quality difference you'd notice.

Use Opus 4.6 when you're doing something that requires sustained multi-step reasoning: untangling a complex bug across many files, designing a system from scratch, or reviewing an architecture where the wrong call has large downstream consequences.

The rule that works in practice: start every session in Sonnet and switch to Opus when Sonnet gets it wrong twice in a row on the same problem.

Speed and Cost — The Practical Reality

Sonnet 4.6 generates tokens roughly 2–3x faster than Opus 4.6. On a complex refactor producing 800 lines of output, that's the difference between a 25-second response and a 60-second one. For iterative work, that multiplies across dozens of interactions.

On Claude Max (subscription plan), you still hit usage limits faster with Opus — each request consumes more capacity. Opus is a finite resource even on Max. Use it deliberately, not by default.

Where Sonnet 4.6 Is Genuinely Better

Boilerplate and scaffolding

// Sonnet generates this just as well as Opus
export async function createUser(data: CreateUserDto): Promise<User> {
  const existing = await db.user.findUnique({ where: { email: data.email } })
  if (existing) throw new ConflictException('Email already in use')

  const hashed = await bcrypt.hash(data.password, 12)
  return db.user.create({
    data: { ...data, password: hashed },
    select: { id: true, email: true, name: true, createdAt: true }
  })
}

Generating endpoints, CRUD handlers, components, test files — Sonnet handles all of this at the same quality as Opus. No reason to spend Opus credits here.

Also Sonnet-territory:

Refactoring with clear requirements
Writing tests for known behavior
Debugging well-isolated bugs
Documentation and code review

Where Opus 4.6 Earns Its Cost

Multi-file bugs with indirect causation

The hardest bugs are the ones where the symptom is three layers away from the cause. A user sees a blank screen. The issue is a race condition between an auth token refresh and a cached API response, which causes a stale closure to capture an undefined value that gets used in a render function.

Sonnet finds the symptom. Opus works backwards to the root cause, traces the full call chain, and fixes the right thing. This is where the reasoning difference is most visible.

Architecture and system design

"Should we use Redis pub/sub or a message queue here?" "How should we structure tenant isolation?" These questions have tradeoffs that compound. Opus holds more context simultaneously and reasons through second-order consequences — it catches the "yes but if you do that, then X breaks because Y" that Sonnet misses on complex design questions.

Security review

Identifying SQL injection vectors, SSRF possibilities, JWT validation errors — security reasoning requires thinking adversarially and tracking subtle data flows. Opus is noticeably better at this. Use Opus for security passes before releases.

The Model Selection Workflow in Claude Code

# Start in Sonnet (default, fastest)
claude

# Realize the bug is more complex than expected — switch:
# /model claude-opus-4-6

# Or set Opus as default for sessions where you know it's needed:
claude --model claude-opus-4-6

The pattern that works:

Start in Sonnet for every new task
If Sonnet gets it wrong, switch to Opus for that specific problem
Once Opus resolves the hard part, switch back to Sonnet for implementation

Use Opus as a specialist you bring in for hard problems — not a general assistant you leave running all day.

Task-by-Task Decision Guide

Task	Use
Writing new endpoints / components	Sonnet
Refactoring with clear spec	Sonnet
Writing tests	Sonnet
Documentation and comments	Sonnet
Well-isolated bug fix	Sonnet
Multi-file bug with unclear root cause	Opus
System architecture decisions	Opus
Security review	Opus
Debugging unfamiliar library	Opus
Large codebase refactor (20+ files)	Opus

The Real Difference Is Problem Type, Not Problem Size

Common mistake: thinking "big task = Opus, small task = Sonnet". That's wrong.

The correct frame is problem type:

Well-defined transformation → Sonnet (even if it touches 50 files)
Open-ended reasoning with non-obvious solution → Opus (even if it's one function)

A large refactor where you've already figured out the approach is a Sonnet task. A single function that keeps returning the wrong result and you can't figure out why is an Opus task.

Sonnet 4.6 is the right default. It's not a compromise — it handles most coding work correctly and returns answers fast enough to keep the iteration loop tight. Opus 4.6 is a specialist: bring it in for the problems that genuinely require it, and you'll notice the difference immediately.

Full article at stacknotice.com/blog/claude-sonnet-vs-opus-coding-2026

Svelte 5 Complete Guide: Runes, Snippets & SvelteKit (2026)

Carlos Oliva Pascual — Tue, 04 Aug 2026 14:25:11 +0000

Svelte 5 is the biggest change to the framework since it launched. The compiler-driven approach stays — no virtual DOM, real DOM updates compiled away — but the reactivity model is completely new. Runes replace the implicit $: reactive statements with explicit, signal-based primitives that work consistently inside and outside components.

This matters because Svelte 4's reactivity had rough edges: reactive declarations only worked at the top level of components, stores were the only way to share state, and $: could be hard to reason about when dependencies were indirect. Runes fix all of this with a uniform API that works everywhere.

Installation

# New project (SvelteKit + Svelte 5)
npm create svelte@latest my-app
cd my-app
npm install
npm run dev

The Runes System

Runes are compiler-recognized function calls prefixed with $. They look like functions but are processed at compile time — no imports needed, they're always in scope in .svelte files.

$state — Reactive Variables

<script>
  let count = $state(0)
  let user = $state({ name: 'Alice', score: 0 })

  function increment() {
    count++
  }

  function addScore(points: number) {
    user.score += points  // object mutations are tracked
  }
</script>

<button onclick={increment}>Count: {count}</button>
<p>{user.name}: {user.score} points</p>

Deep reactivity works out of the box — mutating nested properties on a $state object triggers updates. No need to spread or replace the whole object.

$state.raw — Untracked State

When you have a large object you only replace as a whole (never mutate in place), use $state.raw to skip deep tracking:

<script>
  let items = $state.raw<string[]>([])

  function addItem(item: string) {
    items = [...items, item]  // replace, don't mutate
  }
</script>

$derived — Computed Values

$derived replaces $: reactive declarations. It re-evaluates whenever its dependencies change:

<script>
  let price = $state(100)
  let quantity = $state(3)
  let discount = $state(0.1)

  const subtotal = $derived(price * quantity)
  const total = $derived(subtotal * (1 - discount))
  const formatted = $derived(`$${total.toFixed(2)}`)
</script>

<p>Subtotal: ${subtotal}</p>
<p>Total (10% off): {formatted}</p>

For complex derived values that need multiple statements, use $derived.by:

<script>
  let items = $state([
    { name: 'Apple', qty: 3, price: 1.2 },
    { name: 'Bread', qty: 2, price: 2.5 },
  ])

  const summary = $derived.by(() => {
    const total = items.reduce((sum, item) => sum + item.qty * item.price, 0)
    const count = items.reduce((sum, item) => sum + item.qty, 0)
    return { total: total.toFixed(2), count }
  })
</script>

<p>{summary.count} items — ${summary.total}</p>

$effect — Side Effects

$effect replaces $: statements that call functions or run side effects. It runs after the component mounts and re-runs when its reactive dependencies change:

<script>
  import { Chart } from 'chart.js'

  let data = $state([10, 25, 18, 42])
  let canvas: HTMLCanvasElement

  $effect(() => {
    const chart = new Chart(canvas, {
      type: 'bar',
      data: { labels: data.map((_, i) => `Day ${i + 1}`), datasets: [{ data }] }
    })

    return () => chart.destroy()  // cleanup runs before next effect or on unmount
  })
</script>

<canvas bind:this={canvas}></canvas>

The return value of $effect is a cleanup function — the same pattern as React's useEffect. Don't mutate state inside $effect — it can create infinite loops.

$props — Component Props

In Svelte 5, props use $props() instead of export let:

<!-- Button.svelte -->
<script lang="ts">
  interface Props {
    label: string
    variant?: 'primary' | 'secondary' | 'ghost'
    disabled?: boolean
    onclick?: () => void
  }

  const { label, variant = 'primary', disabled = false, onclick }: Props = $props()
</script>

<button
  class="btn btn-{variant}"
  {disabled}
  {onclick}
>
  {label}
</button>

$bindable — Two-Way Binding

When a prop should support bind:, mark it with $bindable:

<!-- TextInput.svelte -->
<script lang="ts">
  let { value = $bindable(''), placeholder = '' } = $props()
</script>

<input bind:value {placeholder} />

<!-- Parent -->
<script>
  let name = $state('')
</script>

<TextInput bind:value={name} placeholder="Enter your name" />
<p>Hello, {name}</p>

Snippets — Replacing Slots

Svelte 5 replaces slots with Snippets. Snippets are reusable template fragments that can be passed as props or defined inline.

Basic Snippet

<!-- Card.svelte -->
<script lang="ts">
  import type { Snippet } from 'svelte'

  interface Props {
    title: string
    children: Snippet
    footer?: Snippet
  }

  const { title, children, footer } = $props<Props>()
</script>

<div class="card">
  <h2>{title}</h2>
  <div class="card-body">
    {@render children()}
  </div>
  {#if footer}
    <div class="card-footer">
      {@render footer()}
    </div>
  {/if}
</div>

<Card title="User Profile">
  <p>Name: Alice</p>
  <p>Role: Admin</p>

  {#snippet footer()}
    <button>Edit Profile</button>
  {/snippet}
</Card>

Snippets with Parameters

Snippets accept arguments — the equivalent of scoped slots in Vue or render props in React:

<!-- DataTable.svelte -->
<script lang="ts">
  import type { Snippet } from 'svelte'

  interface Props<T> {
    items: T[]
    row: Snippet<[T, number]>  // receives item and index
  }

  const { items, row } = $props<Props<unknown>>()
</script>

<table>
  <tbody>
    {#each items as item, i}
      <tr>{@render row(item, i)}</tr>
    {/each}
  </tbody>
</table>

Event Handling Changes

Svelte 5 moves away from on:event directives to standard HTML event attributes:

<!-- Svelte 4 -->
<button on:click={handleClick}>Click</button>
<form on:submit|preventDefault={handleSubmit}>

<!-- Svelte 5 -->
<button onclick={handleClick}>Click</button>
<form onsubmit={(e) => { e.preventDefault(); handleSubmit(e) }}>

Shared State with Runes

State can live in .svelte.ts files and be shared across components — the replacement for Svelte stores:

// src/lib/cart.svelte.ts
function createCart() {
  let items = $state<CartItem[]>([])

  const total = $derived(
    items.reduce((sum, item) => sum + item.price * item.qty, 0)
  )

  function add(item: CartItem) {
    const existing = items.find((i) => i.id === item.id)
    if (existing) {
      existing.qty++
    } else {
      items.push(item)
    }
  }

  function remove(id: string) {
    items = items.filter((i) => i.id !== id)
  }

  return {
    get items() { return items },
    get total() { return total },
    add,
    remove,
  }
}

export const cart = createCart()

<!-- CartIcon.svelte -->
<script>
  import { cart } from '$lib/cart.svelte'
</script>

<span>{cart.items.length} items — ${cart.total.toFixed(2)}</span>

SvelteKit Form Actions

SvelteKit's form actions handle mutations server-side — no API routes needed for standard CRUD:

// src/routes/posts/new/+page.server.ts
import { fail, redirect } from '@sveltejs/kit'
import { z } from 'zod'
import type { Actions } from './$types'

const schema = z.object({
  title: z.string().min(3).max(200),
  content: z.string().min(10)
})

export const actions: Actions = {
  default: async ({ request, locals }) => {
    const formData = await request.formData()
    const parsed = schema.safeParse(Object.fromEntries(formData))

    if (!parsed.success) {
      return fail(400, { errors: parsed.error.flatten().fieldErrors })
    }

    const post = await locals.db.post.create({ data: parsed.data })
    redirect(303, `/blog/${post.slug}`)
  }
}

<form method="POST" use:enhance>
  <input name="title" />
  <textarea name="content"></textarea>
  <button type="submit">Publish</button>
</form>

use:enhance progressively enhances the form — works without JS (plain HTML form), with JS submits via fetch without a full page reload.

Migrating from Svelte 4

npx sv migrate svelte-5

Svelte 4	Svelte 5
`export let count = 0`	`const { count = 0 } = $props()`
`$: double = count * 2`	`const double = $derived(count * 2)`
`$: console.log(count)`	`$effect(() => { console.log(count) })`
`<slot />`	`{@render children()}`
`on:click={handler}`	`onclick={handler}`
`writable(0)` from svelte/store	`$state(0)` in `.svelte.ts`

Stores still work in Svelte 5 — no need to migrate them immediately.

Svelte 5 vs React and Vue 3

	Svelte 5	React	Vue 3
Reactivity model	Runes (compile-time)	useState/hooks	Composition API
Bundle size (runtime)	~8KB	~45KB	~22KB
No virtual DOM	Yes	No	No
SSR framework	SvelteKit	Next.js	Nuxt
Learning curve	Low	Medium	Medium

Svelte's compile-time approach means less JavaScript shipped to the browser. For content-heavy sites and apps where bundle size matters, Svelte wins clearly. For apps that lean heavily on the npm ecosystem (data tables, charts, editors), React's depth still has an edge.

Runes make Svelte's reactivity predictable and portable. State that used to only work inside components now works in plain TypeScript files — shared state without stores, reactive utilities without component lifecycle constraints. Combined with SvelteKit's server-first data loading and form actions, Svelte 5 is a compelling choice for full-stack TypeScript projects where performance and bundle size are priorities.

Full article at stacknotice.com/blog/svelte-5-complete-guide-2026

Redis Complete Guide: Caching, Queues & Pub/Sub (2026)

Carlos Oliva Pascual — Tue, 04 Aug 2026 10:06:25 +0000

Redis is a data structure server that lives in memory. It's fast because reads and writes never touch a disk during normal operation. It's versatile because it supports more than just key-value pairs — strings, hashes, sorted sets, lists, streams, and pub/sub channels are all first-class primitives.

Most developers use Redis as a cache. That's a fine starting point, but it undersells what Redis can do: session storage, rate limiting, leaderboards, job queues, real-time event streams, and distributed locks are all solved with Redis primitives rather than custom code.

This guide covers Redis from setup through production patterns using Node.js and TypeScript.

Setup

Local with Docker

docker run -d \
  --name redis \
  -p 6379:6379 \
  redis:7-alpine

# With password
docker run -d \
  --name redis \
  -p 6379:6379 \
  redis:7-alpine \
  redis-server --requirepass your-password

Node.js Client — ioredis

npm install ioredis
npm install -D @types/node

// src/lib/redis.ts
import { Redis } from 'ioredis'

const redis = new Redis({
  host: process.env.REDIS_HOST ?? 'localhost',
  port: parseInt(process.env.REDIS_PORT ?? '6379'),
  password: process.env.REDIS_PASSWORD,
  maxRetriesPerRequest: 3,
  enableReadyCheck: true,
  lazyConnect: false,
})

redis.on('error', (err) => console.error('Redis error:', err))
redis.on('connect', () => console.log('Redis connected'))

export default redis

For managed Redis (production), use Upstash Redis with Next.js — serverless, no connection management. For self-hosted or when you need full Redis features, ioredis + a managed Redis instance (Railway, Render, AWS ElastiCache) is the path.

Data Structures

Strings — the Basic Building Block

Strings hold any value up to 512MB. The most common use: cache a computed or fetched value.

// Set a value
await redis.set('user:123:name', 'Alice')

// Set with expiry (TTL in seconds)
await redis.set('session:abc', JSON.stringify(sessionData), 'EX', 3600)

// Set only if key doesn't exist (atomic check-and-set)
const created = await redis.set('lock:job:42', '1', 'EX', 30, 'NX')
// Returns 'OK' if set, null if key already existed — distributed lock pattern

// Get
const name = await redis.get('user:123:name')

// Increment (atomic — no race conditions)
const count = await redis.incr('pageview:post:slug-here')
await redis.incrby('stats:downloads', 5)

// Delete
await redis.del('user:123:name')

// Check existence
const exists = await redis.exists('user:123:name')  // 1 or 0

// Remaining TTL (in seconds)
const ttl = await redis.ttl('session:abc')  // -1 = no expiry, -2 = doesn't exist

Hashes — Object Storage

A hash stores multiple field-value pairs under one key — natural fit for user objects or settings:

// Set multiple fields
await redis.hset('user:123', {
  name: 'Alice',
  email: 'alice@example.com',
  role: 'admin',
  createdAt: new Date().toISOString()
})

// Get one field
const email = await redis.hget('user:123', 'email')

// Get all fields
const user = await redis.hgetall('user:123')
// Returns: { name: 'Alice', email: 'alice@example.com', role: 'admin', ... }

// Update a field
await redis.hset('user:123', 'role', 'moderator')

// Delete a field
await redis.hdel('user:123', 'tempField')

// Check field existence
const hasEmail = await redis.hexists('user:123', 'email')

// Get all keys/values separately
const fields = await redis.hkeys('user:123')
const values = await redis.hvals('user:123')

Sorted Sets — Leaderboards and Rankings

Sorted sets store unique members with a score. Members are always sorted by score:

// Add members with scores
await redis.zadd('leaderboard:weekly', [
  100, 'alice',
  85,  'bob',
  92,  'charlie',
  78,  'diana'
])

// Increment a score (when alice earns more points)
await redis.zincrby('leaderboard:weekly', 15, 'alice')

// Get top 10 with scores (highest first)
const top10 = await redis.zrevrange('leaderboard:weekly', 0, 9, 'WITHSCORES')
// Returns: ['alice', '115', 'charlie', '92', 'bob', '85', ...]

// Get a member's rank (0-indexed, lowest score = rank 0)
const rank = await redis.zrevrank('leaderboard:weekly', 'alice')  // 0 = top

// Get a member's score
const score = await redis.zscore('leaderboard:weekly', 'alice')  // '115'

// Get members in a score range
const midRange = await redis.zrangebyscore('leaderboard:weekly', 80, 100, 'WITHSCORES')

// Count members in a score range
const count = await redis.zcount('leaderboard:weekly', 90, '+inf')

Sorted sets also model time-series data when you use Unix timestamps as scores — lets you query events in a time window efficiently.

Lists — Queues and Activity Feeds

Lists are ordered sequences. Push to one end, pop from the other — FIFO queue.

// Push to the right (tail)
await redis.rpush('notifications:user:123', JSON.stringify({ type: 'like', postId: '456' }))

// Push to the left (head)
await redis.lpush('recent:searches', 'nextjs hooks')

// Blocking pop (waits for an item — useful for job consumers)
const item = await redis.blpop('job:queue', 10)  // waits up to 10 seconds

// Non-blocking pop
const next = await redis.lpop('job:queue')

// Range (get without removing)
const recent = await redis.lrange('recent:searches', 0, 9)  // last 10 searches

// Trim to keep only the last N items
await redis.ltrim('recent:searches', 0, 99)  // keep only 100 items

// Length
const queueDepth = await redis.llen('job:queue')

Sets — Unique Collections

Sets hold unique values — intersections, unions, and membership checks are fast:

// Track active sessions per user
await redis.sadd('sessions:user:123', 'session-token-abc')
await redis.srem('sessions:user:123', 'session-token-abc')

// Check membership
const isActive = await redis.sismember('sessions:user:123', 'session-token-abc')

// Get all members
const sessions = await redis.smembers('sessions:user:123')

// Set operations
const commonFollowers = await redis.sinter('followers:alice', 'followers:bob')
const allFollowers = await redis.sunion('followers:alice', 'followers:bob')
const onlyAlice = await redis.sdiff('followers:alice', 'followers:bob')

// Count members
const count = await redis.scard('sessions:user:123')

Caching Patterns

Cache-Aside (Lazy Loading)

The most common pattern — check cache first, load from DB on miss, populate cache:

async function getPost(slug: string) {
  const cacheKey = `post:${slug}`

  // 1. Check cache
  const cached = await redis.get(cacheKey)
  if (cached) {
    return JSON.parse(cached)
  }

  // 2. Cache miss — load from database
  const post = await db.post.findUnique({
    where: { slug },
    include: { author: true, tags: true }
  })

  if (!post) return null

  // 3. Populate cache (1 hour TTL)
  await redis.set(cacheKey, JSON.stringify(post), 'EX', 3600)

  return post
}

// Invalidate when post changes
async function updatePost(slug: string, data: Partial<Post>) {
  const post = await db.post.update({ where: { slug }, data })
  await redis.del(`post:${slug}`)  // force fresh load on next request
  return post
}

Memoize with Expiry

Wrap any async function with Redis caching:

async function memoize<T>(
  key: string,
  fn: () => Promise<T>,
  ttlSeconds: number
): Promise<T> {
  const cached = await redis.get(key)
  if (cached) return JSON.parse(cached) as T

  const result = await fn()
  await redis.set(key, JSON.stringify(result), 'EX', ttlSeconds)
  return result
}

// Usage
const stats = await memoize(
  'dashboard:stats',
  () => computeExpensiveDashboardStats(),
  300  // cache 5 minutes
)

Rate Limiting

Use Redis to track request counts per user/IP with a sliding window:

async function checkRateLimit(
  identifier: string,  // IP or userId
  limit: number,
  windowSeconds: number
): Promise<{ allowed: boolean; remaining: number; resetAt: number }> {
  const key = `ratelimit:${identifier}`
  const now = Date.now()
  const windowStart = now - windowSeconds * 1000

  // Use a sorted set — score = timestamp, member = unique request ID
  const pipeline = redis.pipeline()
  pipeline.zremrangebyscore(key, '-inf', windowStart)  // remove old requests
  pipeline.zadd(key, now, `${now}-${Math.random()}`)  // add current request
  pipeline.zcard(key)                                   // count in window
  pipeline.expire(key, windowSeconds)                   // cleanup TTL

  const results = await pipeline.exec()
  const count = results![2][1] as number

  return {
    allowed: count <= limit,
    remaining: Math.max(0, limit - count),
    resetAt: now + windowSeconds * 1000
  }
}

// In Express middleware
app.use(async (req, res, next) => {
  const ip = req.ip ?? 'unknown'
  const { allowed, remaining, resetAt } = await checkRateLimit(ip, 100, 60)

  res.setHeader('X-RateLimit-Remaining', remaining)
  res.setHeader('X-RateLimit-Reset', resetAt)

  if (!allowed) {
    return res.status(429).json({ error: 'Too many requests' })
  }

  next()
})

Session Storage

Store Express sessions in Redis so they survive server restarts:

npm install express-session connect-redis

import session from 'express-session'
import { RedisStore } from 'connect-redis'
import redis from './lib/redis'

app.use(session({
  store: new RedisStore({ client: redis }),
  secret: process.env.SESSION_SECRET!,
  resave: false,
  saveUninitialized: false,
  cookie: {
    secure: process.env.NODE_ENV === 'production',
    httpOnly: true,
    maxAge: 7 * 24 * 60 * 60 * 1000  // 7 days
  }
}))

Pub/Sub

Redis pub/sub broadcasts messages across processes — the same mechanism used by Socket.io's Redis Adapter:

import { Redis } from 'ioredis'

// Publisher — regular client
const publisher = new Redis({ host: 'localhost' })

// Subscriber — dedicated client (can't run commands while subscribed)
const subscriber = new Redis({ host: 'localhost' })

// Subscribe to a channel
await subscriber.subscribe('notifications')

subscriber.on('message', (channel, message) => {
  console.log(`[${channel}] ${message}`)
  const data = JSON.parse(message)
  // process notification...
})

// Publish from anywhere in your application
await publisher.publish('notifications', JSON.stringify({
  type: 'new_order',
  orderId: '123',
  userId: 'alice'
}))

// Pattern subscribe (subscribe to multiple channels matching a pattern)
await subscriber.psubscribe('user:*:events')
subscriber.on('pmessage', (pattern, channel, message) => {
  // channel = 'user:alice:events', message = '...'
})

Job Queues with BullMQ

BullMQ uses Redis as a queue backend — reliable job processing with retries, delays, and priorities:

npm install bullmq

import { Queue, Worker, Job } from 'bullmq'

const connection = { host: 'localhost', port: 6379 }

// Producer — add jobs to queue
const emailQueue = new Queue('email', { connection })

await emailQueue.add('send-welcome', {
  to: 'alice@example.com',
  name: 'Alice'
}, {
  attempts: 3,
  backoff: { type: 'exponential', delay: 1000 }
})

await emailQueue.add('send-digest', { userId: 'alice' }, {
  delay: 60_000,     // process after 1 minute
  priority: 10       // lower number = higher priority
})

// Consumer — process jobs
const emailWorker = new Worker('email', async (job: Job) => {
  if (job.name === 'send-welcome') {
    const { to, name } = job.data
    await resend.emails.send({
      from: 'hello@myapp.com',
      to,
      subject: `Welcome, ${name}!`,
      html: `<h1>Hello ${name}!</h1>`
    })
  }
}, {
  connection,
  concurrency: 5  // process up to 5 jobs simultaneously
})

emailWorker.on('completed', (job) => {
  console.log(`Job ${job.id} completed`)
})

emailWorker.on('failed', (job, error) => {
  console.error(`Job ${job?.id} failed:`, error.message)
})

Eviction Policies

When Redis runs out of memory, it evicts keys based on the configured policy. Set in redis.conf or on connection:

Policy	Behavior
`noeviction`	Returns errors when memory is full (default)
`allkeys-lru`	Evicts least recently used key across all keys
`volatile-lru`	Evicts LRU key among keys with TTL
`allkeys-lfu`	Evicts least frequently used key
`volatile-ttl`	Evicts key with shortest TTL

For a pure cache, allkeys-lru is the right choice — Redis automatically removes old data to make room for new entries.

# Set via CLI or redis.conf
redis-cli CONFIG SET maxmemory 256mb
redis-cli CONFIG SET maxmemory-policy allkeys-lru

Atomic Operations with Pipelines

Reduce round-trips by batching commands:

// Without pipeline — 4 round trips
await redis.set('a', '1')
await redis.set('b', '2')
await redis.incr('counter')
await redis.expire('session', 3600)

// With pipeline — 1 round trip
const results = await redis
  .pipeline()
  .set('a', '1')
  .set('b', '2')
  .incr('counter')
  .expire('session', 3600)
  .exec()
// results: array of [error, result] for each command

For operations that need to be atomic (all-or-nothing), use Lua scripts or transactions:

// Transaction (MULTI/EXEC)
const result = await redis
  .multi()
  .decrby('inventory:item:42', 1)
  .rpush('orders:pending', JSON.stringify(order))
  .exec()
// If any command fails, none execute

Redis vs Alternatives

	Redis	Memcached	Upstash	Dragonfly
Data structures	Rich	Strings only	Redis-compatible	Redis-compatible
Persistence	Yes (RDB/AOF)	No	Managed	Yes
Pub/sub	Yes	No	Yes	Yes
Streams	Yes	No	Yes	Yes
Serverless	No	No	Yes	No
Horizontal scale	Redis Cluster	Native	Managed	Better than Redis
Best for	General purpose	Pure caching	Serverless/edge	High throughput

For Next.js serverless environments, Upstash is the right call — no persistent connections needed. For self-hosted backends (NestJS, Fastify, Express) running as long-lived processes, a managed Redis instance (Redis Cloud, Railway, Render) with ioredis is simpler and gives you access to the full feature set.

Redis's data structures remove entire categories of problems that would otherwise require custom code. Rate limiting becomes a sorted set with score-based expiry. Leaderboards become a sorted set with member scores. Job queues become lists with atomic pop. Before reaching for a specialized service, check if Redis already has a primitive that fits — it usually does.

Full article at stacknotice.com/blog/redis-complete-guide-2026

DEV Community: Carlos Oliva Pascual

NestJS vs Fastify (2026): When Full Framework Beats Micro-Framework

Architecture: Yours vs. Theirs

Fastify: You Own the Structure

NestJS: Module → Controller → Service

Dependency Injection: The Real Differentiator

NestJS + Fastify Adapter

Performance

Auto-Generated Swagger

Decision Framework

tRPC vs Hono RPC (2026): End-to-End Type Safety Without the Setup Tax

The Core Model

tRPC: Procedures on a Router

Hono RPC: Routes as Types

Client Integration

tRPC: React Query Under the Hood

Hono RPC: Typed Fetch, You Handle Caching

Non-React Clients

Subscriptions

Decision Framework

Hono vs Express vs Fastify (2026): Which Node.js Framework Is Actually Faster?

Performance: The Numbers That Matter

Express — The Incumbent

Fastify — Best Throughput on Node.js

Hono — Runs Everywhere

The Same Endpoint in All Three

Decision Framework

OpenAI Codex CLI vs Claude Code (2026): Terminal Coding Agents Compared

The Foundational Difference

Model and API

Permission Models

Codex CLI: three modes

Claude Code: explicit by default

Context and Project Understanding

Codex CLI: git history + explicit files

Claude Code: CLAUDE.md — persistent across sessions

Features Unique to Each

Codex CLI has:

Claude Code has:

Open Source vs Proprietary

Decision Framework

Aider vs Claude Code (2026): Which CLI Coding Agent Should You Use?

The Essential Difference

Model Flexibility

Aider: any model, your choice

Claude Code: Claude only

Git Integration

Aider: automatic commits by default

Claude Code: explicit git control

Context and Codebase Understanding

Aider: repo map

Claude Code: CLAUDE.md

Permission Model

Aider: permissive by default

Claude Code: explicit approval

Features Unique to Each

Aider has:

Claude Code has:

Daily Workflow

A typical Aider session

A typical Claude Code session

Which One to Use

Claude Code Token Usage: Cut Costs 40-60% Without Losing Quality (2026)

The Biggest Lever: Model Selection

Context Window: The Compounding Leak

/compact — Summarize and Continue

/clear — Start Clean

CLAUDE.md: Tokens You Never Spend Twice

Specific Prompts Beat Vague Requests

Plan Mode for Complex Tasks

Batch Related Changes

What Costs More Than You Think

The Token Efficiency Checklist

Claude Code: CLAUDE.md vs Projects vs Memory — Which Persists What?

The Three Mechanisms at a Glance

CLAUDE.md — The Primary Tool for Claude Code

Hierarchical structure

What to put in it

Global CLAUDE.md for personal preferences

The team advantage

`/compact` — Summarize and Continue

`/clear` — Start Clean