A practical guide for developers navigating Claude Code, Cursor, Copilot, Windsurf, Codex, and beyond.

You switch from Cursor to Claude Code. Or from Copilot to Windsurf. The interface is different. The shortcuts are different. The config file has a new name. And for a moment, it feels like you’re starting from scratch.

You’re not.

Under the surface, every modern AI coding agent is built on the same foundational ideas. Once you understand those ideas deeply, moving between agents becomes a translation exercise — not a re-education. This post is your translation guide.

Table of contents

• Part 1: The Core Concepts That Never Change
  • Tokens: The Unit of All Understanding
  • The Context Window: Your Agent’s Working Memory
  • Prompt Levels: The Hierarchy of Instructions
  • Rules / Memory Files
  • Commands / Slash Commands
  • Hooks
  • Settings / Configuration Files
• Part 2: How Tokens and Context Windows Shape Your Daily Work
  • The Context Window Is a Sliding Window, Not a Snapshot
  • File Inclusion Is Expensive
  • Your Rules File Is Always In Context — Make It Count
• Part 3: Staying Efficient and Preserving Knowledge Across Agents
  • The Portable Knowledge Stack
  • Build an Agent-Agnostic Memory System
  • Keep a “Lessons Learned” File
  • Start New Tasks With a Fresh Session
• Part 4: How Coding Agents Differ — The Configuration File Map
  • Configuration & Memory Files Across Agents
  • Key Behavioral Differences Worth Knowing
  • The Rename Map: What to Call What When You Switch
• Part 5: The Mental Model That Makes It All Click
• Quick Reference: Starting a New Project with Any Coding Agent

Part 1: The Core Concepts That Never Change

No matter which coding agent you use, you’re always working inside the same basic model of how LLMs (Large Language Models) process information. These concepts are architectural — they exist at the level of the AI model itself, not the tool wrapped around it.

Tokens: The Unit of All Understanding

A token is the smallest chunk of text that an LLM processes. It’s not quite a character, not quite a word — it’s somewhere in between. The word "function" is one token. "refactoring" might be two. A newline character is a token. An emoji is a token.

Why does this matter to you as a developer?

• Cost: Most AI APIs charge per token (input + output). A 500-line file might be 3,000–5,000 tokens.
• Speed: More tokens in = more time to process.
• Limits: Every model has a hard cap on the total tokens it can handle at once — the context window.

Rules of thumb:

• 1 token ≈ 4 characters in English
• 100 lines of typical code ≈ 500–800 tokens
• A full package.json with many dependencies ≈ 500–1,000 tokens
• A dense 200-line Python module ≈ 1,500–2,500 tokens

Every coding agent — whether it’s Claude Code, Cursor, Copilot, Windsurf, or Codex — is ultimately constrained by this math.

The Context Window: Your Agent’s Working Memory

The context window is the total amount of text (measured in tokens) that a model can “see” and reason about at any one time. Think of it as the agent’s working memory. Whatever is inside the context window, the agent knows. Whatever falls outside it, the agent has completely forgotten.

┌─────────────────────────────────────────────────────────────┐
│                     CONTEXT WINDOW                          │
│                                                             │
│  [System Prompt]  [Rules/Memory]  [Files]  [Chat History]   │
│                                                             │
│  ← Everything here is "known" to the agent →                │
└─────────────────────────────────────────────────────────────┘
         ↑
  Anything outside this box? The agent has no idea it exists.

200K tokens sounds enormous — until you realize a mid-sized codebase can easily exceed it. This is why agents use strategies like RAG (Retrieval-Augmented Generation), file summarization, and selective file inclusion: they’re all techniques for making the most of a finite context window.

What fills your context window in a typical session?

1. System prompt (the agent’s built-in instructions)
2. Your memory/rules files (.claude/CLAUDE.md, .cursorrules, etc.)
3. Files you’ve opened or the agent has read
4. The conversation history
5. Tool call outputs (test results, terminal output, file listings)
6. The agent’s own responses

When a session gets long, earlier messages get evicted or compressed. This is why agents sometimes seem to “forget” things discussed earlier in a long session — they didn’t forget them, those tokens simply scrolled out of the window.

Prompt Levels: The Hierarchy of Instructions

Every coding agent operates with a layered instruction system. Think of it like a corporate org chart: instructions from higher levels take precedence, but lower levels fill in the details.

┌──────────────────────────────────────────┐
│           LEVEL 1: SYSTEM PROMPT         │  ← Set by the agent maker
│   "You are a helpful coding assistant…"  │     (you never see this)
├──────────────────────────────────────────┤
│        LEVEL 2: PROJECT MEMORY           │  ← Set by YOU (per project)
│CLAUDE.md / .cursorrules / .windsurfrules │   (lives in your repo)
├──────────────────────────────────────────┤
│         LEVEL 3: USER PREFERENCES        │  ← Set by YOU (global)
│   settings.json / user memory files      │   (applies to all projects)
├──────────────────────────────────────────┤
│          LEVEL 4: CONVERSATION           │  ← What you type, right now
│   "For this task, use async/await…"      │   (temporary, per session)
└──────────────────────────────────────────┘
         Higher levels = stronger default behavior
         Lower levels = more specific, situational instructions

Why this hierarchy matters:

Instructions at higher levels are always “on.” You don’t have to repeat yourself every session. Your project rules file (Level 2) might say “always write TypeScript, never use any” — and the agent will follow that for every request in that project without you ever typing it again.

Conversational instructions (Level 4) are the most powerful but the most ephemeral. They override everything for the current exchange but are gone next session.

Rules / Memory Files

These are the most portable concept across all coding agents. Every agent has some mechanism for you to write persistent instructions that get injected into the context automatically.

The file format is almost always plain Markdown. The ideas you put in these files travel with your project or your global preferences. This is your primary vehicle for knowledge transfer between agents (more on this in Part 3).

What belongs in a rules file:

• Your coding standards and conventions (naming, formatting, architecture patterns)
• Things the agent should always or never do
• Project-specific context (what this repo is, what the stack is, who the users are)
• Common gotchas (known bugs, deprecated patterns to avoid, custom APIs)

What does NOT belong:

• Long tutorials or documentation (waste of tokens)
• Information that changes frequently (use conversation for that)
• Secrets or credentials (never)

Commands / Slash Commands

Every major coding agent supports some form of slash commands — shorthand invocations that trigger specific behaviors or tools.

• /review → trigger a code review
• /fix → attempt to fix the current error
• /test → run or generate tests
• /commit → draft a commit message

The names differ between agents, but the concept is the same: they’re macros that expand into more complex prompts or tool invocations. Many agents also let you define custom commands — your own reusable prompts saved as files.

Hooks

Hooks are event-triggered automations. They run automatically when something happens — a file is saved, a tool call completes, a session starts. Think of them as git hooks but for your AI agent.

Common hook trigger points across agents:

Claude Code calls them hooks and configures them in settings.json. Cursor has similar automation through its rules system and extensions. The concept is identical — the config key is different.

Settings / Configuration Files

Every agent has a settings.json or equivalent that controls agent behavior at the tool level: which tools are enabled, permission levels, UI preferences, API keys, and so on. This is distinct from your rules/memory files (which are prompt-level) — settings files are more like application configuration.

Part 2: How Tokens and Context Windows Shape Your Daily Work

Understanding the theory is one thing. Here’s how it plays out practically.

The Context Window Is a Sliding Window, Not a Snapshot

When your conversation gets long, the model doesn’t summarize and keep everything. It literally truncates. The oldest messages drop off first. This means:

• Don’t rely on something you said 50 messages ago. Re-state it.
• Long sessions degrade in quality. Start a fresh session for a new task.
• The more files the agent opens, the less room there is for your conversation.

File Inclusion Is Expensive

When you ask an agent to “look at my codebase,” it reads files — and every line it reads costs tokens. A 2,000-line monolith file can consume 15,000–20,000 tokens just by being opened. Multiply that by a few files and you’ve consumed a significant fraction of even a 200K context window before you’ve typed a single prompt.

Practical tips:

• Keep your important files short and modular.
• Tell the agent exactly which files are relevant instead of letting it explore broadly.
• Use .gitignore-style exclusions in your agent’s config to prevent it from accidentally pulling in node_modules, build artifacts, or generated files.

Your Rules File Is Always In Context — Make It Count

Every token in your rules file is loaded at the start of every session. A bloated, disorganized rules file wastes tokens on every single request. A well-written, tight rules file pays dividends every time.

Keep your rules file under 500 tokens (roughly 300–400 words) if possible. Write it like a technical spec, not a tutorial.

Part 3: Staying Efficient and Preserving Knowledge Across Agents

The biggest risk when switching coding agents isn’t learning a new interface — it’s losing the accumulated knowledge embedded in your workflow. Here’s how to prevent that.

The Portable Knowledge Stack

Think of your knowledge in three tiers, each with different portability:

TIER 1 — Fully Portable (Markdown files you own)
  └── Project rules, coding conventions, architectural decisions
  └── Lives in your repo. Works in any agent.

TIER 2 — Partially Portable (Concepts, patterns, commands)
  └── The mental model of what commands do, how hooks work
  └── Needs renaming when you switch agents, but ideas transfer directly

TIER 3 — Agent-Specific (UI, proprietary features, integrations)
  └── Keyboard shortcuts, specific UI panels, proprietary tools
  └── Must be re-learned each time

Invest heavily in Tier 1. Tier 3 is unavoidable tax.

Build an Agent-Agnostic Memory System

The single most impactful thing you can do is treat your rules/memory files as source-of-truth documentation for how you like to work — not as agent-specific config.

Write them as if you’re onboarding a new developer (or a new agent) to your project. The moment you want to try a different agent, you copy that file, rename it to whatever the new agent expects, and you’re 80% of the way there.

Suggested structure for any rules file:

# Project: [Name]

## Stack
- Language: TypeScript (strict mode)
- Framework: Next.js 14 (App Router)
- Styling: Tailwind CSS
- DB: PostgreSQL via Prisma

## Conventions
- Use named exports everywhere (no default exports except pages)
- All async functions must have explicit return types
- Error handling: always use Result<T, E> pattern, never throw from service layer

## Common Gotchas
- The `auth` module uses a custom session store — do not use next-auth defaults
- `prisma.$transaction` has a 5s timeout in production

## What I Want From You
- Prefer small, composable functions over large ones
- Always write the test before the implementation when I ask for new features
- When you're unsure, ask — don't guess and write 200 lines

This file is useful in Claude Code, Cursor, Windsurf, Copilot, Codex, and any agent that comes next year.

Keep a “Lessons Learned” File

Beyond project conventions, keep a running log of insights you’ve discovered working with AI agents on this project. Things like:

• Prompts that worked particularly well
• Patterns where the agent consistently went wrong
• Tasks where you found the right level of granularity

This becomes a knowledge asset you carry forward indefinitely.

Start New Tasks With a Fresh Session

One of the most common efficiency mistakes is continuing a long, rambling session into a new, unrelated task. By that point, the context window is full of irrelevant history, earlier instructions may have scrolled out, and the agent is working with a degraded picture.

The discipline: one task, one session. Start fresh. The first message of a session should be context-rich (the agent doesn’t know anything yet). Later messages in the same session can be terse.

Part 4: How Coding Agents Differ — The Configuration File Map

This is where the agent-specific translation happens. The concepts are the same; the file names and structures differ. Here’s a comprehensive reference table.

Configuration & Memory Files Across Agents

Key Behavioral Differences Worth Knowing

The Rename Map: What to Call What When You Switch

If you’re migrating from one agent to another, here’s the rename map for your most important files:

Moving FROM → TO            Rename this file
─────────────────────────────────────────────────────
Cursor → Claude Code        .cursorrules → CLAUDE.md
Cursor → Windsurf           .cursorrules → .windsurfrules
Cursor → Codex              .cursorrules → AGENTS.md
Claude Code → Cursor        CLAUDE.md → .cursorrules
Claude Code → Windsurf      CLAUDE.md → .windsurfrules
Claude Code → Copilot       CLAUDE.md → .github/copilot-instructions.md
Claude Code → Codex         CLAUDE.md → AGENTS.md
Codex → Claude Code         AGENTS.md → CLAUDE.md
Codex → Cursor              AGENTS.md → .cursorrules
Windsurf → Cursor           .windsurfrules → .cursorrules
Any → Any                   Keep a master copy (e.g., AI_CONTEXT.md)
                            and symlink/copy to the agent-specific name

Pro tip: Keep a canonical AI_CONTEXT.md in your repo that is your master source of truth. Then create the agent-specific files as copies (or symlinks on Unix). When you update your conventions, you update one file — not four.

For a practical walkthrough of this approach, see Sharing AI Agent Configs Between Cursor and Claude with Symlinks.

Part 5: The Mental Model That Makes It All Click

Here’s the simplest mental model for all of this:

Every coding agent is a smart intern who can only read what’s on their desk.

Their desk is the context window. What you put on the desk — through rules files, open files, and conversation — is all they know. When the desk gets too full, older stuff falls off the edge. The intern doesn’t know what fell off.

Your rules file is the onboarding document you hand them on day one. It saves you from re-explaining yourself every morning.

Tokens are how long each piece of paper on the desk is. Some documents are dense (1,000 tokens per page), some are sparse. The desk has a finite surface area.

Commands are the shorthand phrases you and the intern have agreed on: “do a review” means the same 10-step process every time.

Hooks are the standing instructions pinned to the wall: “whenever you save a file, run the linter.”

And the model is the intern’s actual intelligence — how well they reason, how much they know, how carefully they follow instructions. Different agents use different interns (models), which is why they feel different even when given identical instructions.

The agent changes. The desk, the onboarding document, and the standing instructions — those are yours.

Quick Reference: Starting a New Project with Any Coding Agent

1. Create your rules file first. Before writing a line of code, write 200–400 words explaining your stack, conventions, and working preferences.
2. Name it what the agent expects (see the rename map above), but keep a master copy named something neutral.
3. Add an ignore file. Tell the agent what NOT to read: build directories, generated files, massive lockfiles.
4. Keep sessions task-scoped. One task per session. Start each session with a brief context summary if the agent doesn’t auto-load memory.
5. Invest in custom commands. If you find yourself typing the same prompt repeatedly, save it as a command.
6. Document what works. When a prompt pattern works well, write it down. It’ll work in any agent.

The best coding agent is the one that fits your workflow — and the best workflow is one that doesn’t depend on any single agent. Build your knowledge layer in portable Markdown, understand the universal constraints, and you’ll be effective anywhere.