I spent a good five minutes yesterday confused about which Claude I was talking to, which Claude I was asking about, and whether my own assistant understood the difference. It turns out: mostly, but not quite. We straightened it out. The moment was short, but the confusion was real — and almost certainly not mine alone.

Here's the thing nobody puts on a single page: Claude is several products, each with several front ends, and some of them share state and some don't, and the names overlap just enough to make everyone squint.

If you're new to Claude — or using one flavor and wondering whether you're missing out by not using the others — this is the map I wish I'd had.


The two things people call "Claude"

First, the biggest split. The word "Claude" in casual conversation means one of two totally different products:

Claude — the chat app. claude.ai in the browser, the Claude app on your phone, the Claude desktop app on Windows or Mac. This is what most people mean when they say "I was talking to Claude." It's a general-purpose assistant: writing, research, brainstorming, analysis, the whole spread. It has Projects, artifacts, web search, file uploads, memory, Skills, and connectors (MCP) to things like Gmail and Google Drive.

Claude Code — the coding platform. A completely separate product, purpose-built for software development. It lives in a terminal, a sidebar in your IDE, a dedicated desktop app, or a web browser — your pick. It's the one that reads your repo, edits your files, runs your tests, and commits when you tell it to.

Both are made by Anthropic. Both use the same underlying models. Both have slash commands. Both can load Skills. Both can connect to MCP servers. But they are distinct products with distinct installers, distinct pricing, and distinct purposes.

The single most useful sentence I can give you: if you're writing essays, answering questions, or exploring ideas, you want Claude. If you're writing software, you want Claude Code. Many of us use both, on the same day, for different tasks. That's normal.


The front-end zoo

Here's where people get lost, and understandably so. Each of those two products has multiple front ends — the "how you actually talk to it" surface — and they aren't the same list.

Claude (the chat app) ships as: a web app at claude.ai, a desktop app for macOS and Windows (often called "Claude Desktop"), and mobile apps for iOS and Android.

Claude Code ships as: a CLI you run by typing claude in a terminal, a dedicated desktop app with no terminal required, a VS Code extension that lives in an editor sidebar, a JetBrains extension for IntelliJ/PyCharm/etc., a web version at code.claude.com that runs in Anthropic's cloud, and a mobile app that acts as a thin client into cloud sessions.

That's six front ends for Claude Code alone. Add the three for the chat product and you've got nine distinct ways to say "I'm using Claude." Nine.


The naming trap that will bite you

Before you go any further, know that both products have something called a desktop app, and they are not the same thing.

"Claude Desktop" — no "Code" in the name — is the chat app. The one with Projects and artifacts and the comfy left sidebar of past conversations. Install it from claude.ai.

"Claude Code Desktop" is a visual front end for Claude Code. It looks like an app, not a terminal, but it's running the coding engine. Install it from the Claude Code docs page.

If you have both, they sit side by side in your taskbar with similar icons. Check the window title if you're ever confused about which one you're in.

This is genuinely the nuance that trips people up the most. Same company, similar icon, overlapping name — but totally different capabilities. When someone online says "I'm in Claude Desktop and…" pay attention to whether they mean the chat app or the coding app, because the answer changes which features apply.


Which Claude Code front end should you actually use?

If you've decided you want Claude Code, the second question lands immediately: which of the six front ends?

The good news is you don't have to commit. They share state. Configuration, project memory, and MCP servers are shared across the local surfaces. That means any Skills you write, any slash commands you define, any MCP servers you connect, any CLAUDE.md you customize — all of it applies to every local Claude Code front end on your machine. Switching surfaces costs you nothing.

So the right question isn't "which one is best" but "which one fits the moment."

SurfaceWhat it isBest for
CLIclaude in a terminalMost complete feature set. Scripting. Agent SDK. Third-party providers. If you live in the terminal.
Desktop appDedicated graphical windowSame engine as CLI, no terminal required. Good for cross-project work.
VS Code extensionSidebar in VS CodeInline diffs, plan mode with editing. Warmest entry point for beginners.
JetBrains extensionSidebar in IntelliJ familyJava/Kotlin/Python/Go devs already in JetBrains.
Webcode.claude.comCloud-hosted sessions that persist after you disconnect.
MobileiOS/AndroidThin client into cloud sessions or remote control.

The practical default I'd suggest: start with CLI if you're comfortable in a terminal, VS Code extension if you're not. Add the Desktop app later if you want a terminal-free variant of what you've already learned in CLI. You can always switch — your state comes with you.


Skills vs slash commands — a bonus clarification

While we're at it, here's another pair that people conflate on first contact.

Slash commands are things you type. /deploy, /compress, /review. They're shortcuts for prompts you'd otherwise retype. You write them as markdown files in .claude/commands/. Predictable, manual, always the same output shape. They only work in Claude Code — not in the chat Claude.

Skills are things Claude decides to use. You write a SKILL.md describing a capability, and Claude reads the description on every turn and auto-loads the skill when the current task matches. They work in both products — Claude Code, the chat desktop app, and claude.ai all support Skills. Write once, use everywhere.

The simplest way to remember: slash commands are for when you know exactly what you want and want to save keystrokes. Skills are for when you want Claude to notice a situation and handle it consistently without being asked. Different triggers, different scopes.

If the thing you're building is truly meant to work across the chat product and the coding product, it has to be a Skill. A slash command won't travel. That one decision alone affects how you architect your personal tooling.


The analogy that finally made it click for me

Imagine Anthropic built one car engine that's exceptionally good. Very good engine, industry-leading, no complaints.

Then they realized different drivers want different cars. So they built two cars around that engine:

A comfortable sedan for everyday driving — passengers, errands, road trips, long conversations. And a work truck for construction sites — carries tools, gets dirty, lives on job sites.

That's Claude (the sedan) and Claude Code (the truck). Same engine. Different vehicle. Different purpose.

Then — and this is where it gets nested — each car comes in multiple body styles. The sedan comes in a hatchback, a sedan-sedan, a wagon, a convertible. The truck comes in regular cab, extended cab, crew cab, flatbed, dump bed. Same car, different configuration for different jobs.

That's the front-end zoo. The CLI is the flatbed — maximally capable, minimally comfortable. The VS Code extension is the crew cab — comfortable, slightly less capability at the edges. The mobile app is the jump seat — you're not really driving, you're riding along.

And the two different "desktop apps" with similar names? That's the sedan dealership and the truck dealership both having a bay labeled "Desktop" and both selling a vehicle from that bay. Same word, different thing, and if you're not paying attention to the sign on the building, you'll walk into the wrong one.

Once I internalized the sedan-vs-truck distinction, the rest of the landscape arranged itself. I stopped worrying about whether I was "missing" something by using one and not the other. I started picking the right vehicle for the right trip.


What nobody tells you

A few things I wish someone had said to me on day one:

The products share your account, not your sessions. Your Anthropic login works everywhere, your usage limits pool across surfaces (Claude Code sessions draw from the same budget as chat Claude sessions on the consumer plans), and your billing is unified. But a conversation in one doesn't automatically show up in the other. Ask Claude Code about a chat you had with chat-Claude yesterday — it doesn't know.

The local front ends of each product share state among themselves. Open VS Code extension on Claude Code, go to lunch, come back and open CLI, and your project memory and MCP servers and custom slash commands are all there. This is not true across products. Claude chat's Projects and Claude Code's projects are separate systems.

Skills are the bridge. The only user-writable extension that works in both products is a Skill. Every other customization is product-specific.

You don't have to pick just one. The best configurations I've seen use chat Claude for thinking and Claude Code for doing — with the same person moving fluidly between them as the task dictates. The split isn't a forced choice, it's a toolkit.


The simplest map to carry with you

If you remember nothing else:

Claude is the chat product. Three front ends: web, desktop, mobile. Claude Code is the coding product. Six front ends: CLI, desktop, VS Code, JetBrains, web, mobile. "Claude Desktop" means the chat app. "Claude Code Desktop" means the coding app. They are not the same. Claude Code front ends share state with each other. The two products don't share sessions with each other. Slash commands live in Claude Code. Skills work in both.

That's the whole map. Nine surfaces, two products, one engine underneath. Once it's clear, it stays clear.

The only hard part is getting clear the first time.


Frank Kurka is the creator of TQL (The Question Layer), MemoryOS, and the Glass Bead Game development paradigm. He is the author of What is Artificial Intelligence, has been building software for 45+ years, and writes weekly at fkxx.substack.com.