02 — Ways to Use Claude Code — Same Engine, Many Surfaces

"The CLI is the whole thing" was my assumption about Claude Code, and it made every other surface look like marketing. The idea that straightened it out: there is one agentic engine, and every interface is a frontend over it. [1] The same model, tools, and loop do the work; what changes is how I steer it and how its actions get shown back to me.

The framing that clicked is to stop thinking of "Claude Code" as a single app and start thinking of it as an engine with several steering wheels. The CLI is the canonical, scriptable surface. The IDE extensions wrap that engine in a graphical sidebar with inline diffs. The desktop app is a standalone window for managing complex projects. Channels push messages in from mobile platforms. All four run the same loop underneath — they differ in how they feel to use, not in what they can do [1][2].

The CLI: the canonical surface

The CLI is the command-line tool — the agentic partner that interacts directly with local files and the terminal [3]. It's the surface I keep coming back to because it's the most honest: every tool call and every edit is a line of text I can read, copy, and script. Setup is one install command, then claude inside a project folder to start a session, and a browser login the first time. The CLI also exposes flags and a headless mode (-p) that turn it into a Unix-style utility for CI/CD — which is a whole separate post, but the point here is that every other surface is downstream of what the CLI can do.

The part I had to internalize: the terminal is not a limitation. Inline diff viewers and sidebars are nice, but the underlying actions — Read, Edit, Bash, Grep — are identical. Choosing the CLI is choosing the lowest-overhead view of the loop, not a downgrade.

Desktop and IDE: graphical frontends over the same loop

Claude Code Desktop is a standalone application that gives the agent a graphical interface — read the codebase, edit files, run terminal commands, all from a window instead of a prompt [4]. It's the right choice when a project is large enough that I want a persistent, organized view rather than a single terminal scrollback. The desktop app doesn't add capabilities the CLI lacks; it adds a layout for managing them.

IDE extensions are where most day-to-day work happens for people who already live in an editor. The VS Code and JetBrains extensions provide a graphical sidebar and inline diff viewers, so proposed changes appear side-by-side with existing files [5]. The real payoff isn't the diff viewer itself — it's context awareness. Because the extension lives inside the IDE, it can see my active workspace, the file I have selected, even the error messages in my terminal pane. I stop copying and pasting context into a prompt; the IDE hands it over automatically.

Channels: pushing the outside world into a session

Channels are the surface that took longest to click. They push events from messaging platforms — Telegram, Discord, iMessage — into an already-running Claude Code session [6]. I install a channel plugin, configure it in my MCP config, and Claude Code spawns it locally. When someone messages me on the platform, the plugin receives it and forwards it to Claude, which can read and respond.

The detail that made it make sense: the plugin runs on my computer and polls the platform's API — it's a bridge, not a webhook exposed to the internet. So I can ping my dev session from my phone without opening a port. This is the right fit for an always-on setup where Claude is running in the background and I want to nudge it or get notifications while away from the terminal. For a normal focused coding session, channels are noise; for unattended long jobs, they earn their keep.

Community tools: extending the engine

Beyond the official surfaces, community tools extend Claude Code's reach through the Model Context Protocol (MCP) and plugins — connecting it to GitHub for pull requests, Slack for updates, Jira or Linear for issue tracking [7]. These don't add new engines; they add new tools the existing engine can call in its loop. The community has built many third-party extensions installable through the /plugin command. The way of thinking: the engine stays the same; the tool menu grows.

Subscription vs API: two ways to pay

Underneath all the surfaces is one decision that affects every one of them — how I pay. There are two paths, and they're not interchangeable [8][9].

Subscription links a Claude Pro or Claude Max plan and gives a recurring allocation of messages shared across the web interface and the terminal. Costs are predictable — a flat monthly fee — which suits daily development. Team and Enterprise plans add higher limits, SSO, and audit logs.

API usage is pay-as-you-go: I create a Console account, generate an API key, and pay per token processed [9]. Because it talks directly to the Anthropic API, this mode gives granular control over model versions, billing thresholds, and usage. It's the right fit for power users, automation, and anyone who wants to pay only for what they consume.

Common use cases

The roadmap is blunt about where this pays off in practice, and it matches what I've seen [10]:

• Legacy modernization — navigating and refactoring massive codebases a human would take weeks to map.
• Prototyping — spinning up startup MVPs quickly from natural-language briefs.
• Data pipeline work — converting exploratory notebooks into production code.
• Test automation — generating and maintaining unit tests across a repo.
• Bug diagnosis — reading stack traces and tracing root causes across files.
• DevOps — managing Kubernetes, monitoring, and CI/CD through prompts.

The thread through all of them is the same loop doing different things because the tools differ. Give it file tools and it refactors; give it a shell and it diagnoses; give it a cluster API and it operates infrastructure.

How I use this

The practical habit is matching the surface to the session shape. Quick fix in one file — CLI. Multi-file refactor where I want to watch diffs land — IDE extension. Long, unattended job I want to nudge from my phone — desktop app plus a channel. And underneath, I pick the payment model once: subscription for daily coding where I want predictable cost, API for scripting and automation where I want per-token control. The engine never changes; only the steering wheel and the meter.

References

[1] Anthropic, "Use Claude Code everywhere," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/overview#use-claude-code-everywhere

[2] Anthropic, "Claude Code in Action," Anthropic Skilljar, 2025. [Online]. Available: https://anthropic.skilljar.com/claude-code-in-action

[3] Anthropic, "Getting started with Claude Code," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/quickstart

[4] Anthropic, "Claude Code on desktop," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/desktop

[5] Anthropic, "Use Claude Code in VS Code," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/vs-code

[6] Anthropic, "Push events into a running session with channels," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/channels

[7] Conductor, "Conductor docs," 2025. [Online]. Available: https://docs.conductor.build/

[8] Anthropic, "Subscription & pricing," claude.com, 2025. [Online]. Available: https://claude.com/pricing

[9] Anthropic, "Claude Console," platform.claude.com, 2025. [Online]. Available: https://platform.claude.com/

[10] Anthropic, "Common workflows," Claude Code Docs, 2025. [Online]. Available: https://code.claude.com/docs/en/common-workflows