---
title: "02 — Ways to Use Claude Code — Same Engine, Many Surfaces"
uid: ways-to-use-claude-code
tags: ["desktop", "channels", "roadmap:claude-code", "ide", "cli", "claude-code", "pricing"]
excerpt: "One agentic engine, several frontends: CLI for scripting, IDE for diffs, desktop for projects, channels for mobile. What changes is how you steer it and how its actions come back to you."
date: 2026-08-13T03:28:23+0000
source: https://www.aveshina.my.id/en/blog/ways-to-use-claude-code
---

"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.

```figure
<svg viewBox="0 0 740 280" xmlns="http://www.w3.org/2000/svg" class="my-6 w-full max-w-2xl" role="img" aria-label="One engine, four surfaces. A central indigo box labelled 'Agentic engine (model + tools + loop)' sits in the middle. Four arrows reach out to four surrounding boxes: CLI (terminal, scriptable, canonical), Desktop (standalone window, project management), IDE extension (sidebar + inline diffs, workspace-aware), Channels (mobile push via Telegram, Discord, iMessage). A note underneath reads: 'same loop underneath — differs in feel, not in what it can do'.">
  <defs>
    <marker id="spoke" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto">
      <path d="M0,0 L10,5 L0,10 z" fill="#64748b"/>
    </marker>
  </defs>
  <g font-family="ui-sans-serif, system-ui, sans-serif" text-rendering="geometricPrecision">
    <rect x="260" y="110" width="220" height="60" rx="10" fill="#e0e7ff" stroke="#6366f1" stroke-width="1.8"/>
    <text x="370" y="135" font-size="13" font-weight="700" fill="#1e1b4b" text-anchor="middle">Agentic engine</text>
    <text x="370" y="153" font-size="10" fill="#475569" text-anchor="middle">model · tools · loop</text>

    <rect x="30" y="40" width="150" height="50" rx="8" fill="#dcfce7" stroke="#16a34a" stroke-width="1.5"/>
    <text x="105" y="62" font-size="12" font-weight="700" fill="#052e16" text-anchor="middle">CLI</text>
    <text x="105" y="79" font-size="9.5" fill="#475569" text-anchor="middle">terminal · scriptable</text>

    <rect x="560" y="40" width="150" height="50" rx="8" fill="#fef9c3" stroke="#ca8a04" stroke-width="1.5"/>
    <text x="635" y="62" font-size="12" font-weight="700" fill="#422006" text-anchor="middle">IDE extension</text>
    <text x="635" y="79" font-size="9.5" fill="#475569" text-anchor="middle">sidebar · inline diffs</text>

    <rect x="30" y="190" width="150" height="50" rx="8" fill="#fce7f3" stroke="#db2777" stroke-width="1.5"/>
    <text x="105" y="212" font-size="12" font-weight="700" fill="#500724" text-anchor="middle">Desktop</text>
    <text x="105" y="229" font-size="9.5" fill="#475569" text-anchor="middle">standalone window</text>

    <rect x="560" y="190" width="150" height="50" rx="8" fill="#e0e7ff" stroke="#6366f1" stroke-width="1.5"/>
    <text x="635" y="212" font-size="12" font-weight="700" fill="#1e1b4b" text-anchor="middle">Channels</text>
    <text x="635" y="229" font-size="9.5" fill="#475569" text-anchor="middle">mobile push in</text>

    <path d="M180,75 C220,90 240,110 258,125" fill="none" stroke="#64748b" stroke-width="1.5" marker-end="url(#spoke)"/>
    <path d="M560,75 C520,90 500,110 482,125" fill="none" stroke="#64748b" stroke-width="1.5" marker-end="url(#spoke)"/>
    <path d="M180,205 C220,190 240,170 258,155" fill="none" stroke="#64748b" stroke-width="1.5" marker-end="url(#spoke)"/>
    <path d="M560,205 C520,190 500,170 482,155" fill="none" stroke="#64748b" stroke-width="1.5" marker-end="url(#spoke)"/>

    <text x="370" y="270" font-size="10" font-style="italic" fill="#64748b" text-anchor="middle">same loop underneath — differs in feel, not capability</text>
  </g>
</svg>
```

## 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.

```figure
<svg viewBox="0 0 740 220" xmlns="http://www.w3.org/2000/svg" class="my-6 w-full max-w-2xl" role="img" aria-label="Two ways to pay. Left box: Subscription — flat monthly fee, shared message allocation across web and terminal, predictable cost, good for daily dev. Right box: API usage — pay per token, direct to Anthropic API, granular model and billing control, good for power users and automation.">
  <g font-family="ui-sans-serif, system-ui, sans-serif" text-rendering="geometricPrecision">
    <rect x="30" y="30" width="320" height="150" rx="10" fill="#dcfce7" stroke="#16a34a" stroke-width="1.5"/>
    <text x="190" y="55" font-size="13" font-weight="700" fill="#052e16" text-anchor="middle">Subscription (Pro / Max)</text>
    <text x="50" y="80" font-size="10.5" fill="#052e16">• flat monthly fee</text>
    <text x="50" y="100" font-size="10.5" fill="#052e16">• shared allocation across web + terminal</text>
    <text x="50" y="120" font-size="10.5" fill="#052e16">• predictable cost</text>
    <text x="50" y="140" font-size="10.5" fill="#052e16">• Team/Enterprise: SSO, audit logs</text>
    <text x="50" y="162" font-size="10" font-style="italic" fill="#475569">good for daily development</text>

    <rect x="390" y="30" width="320" height="150" rx="10" fill="#e0e7ff" stroke="#6366f1" stroke-width="1.5"/>
    <text x="550" y="55" font-size="13" font-weight="700" fill="#1e1b4b" text-anchor="middle">API usage (Console)</text>
    <text x="410" y="80" font-size="10.5" fill="#1e1b4b">• pay-as-you-go per token</text>
    <text x="410" y="100" font-size="10.5" fill="#1e1b4b">• direct to Anthropic API</text>
    <text x="410" y="120" font-size="10.5" fill="#1e1b4b">• granular model + billing control</text>
    <text x="410" y="140" font-size="10.5" fill="#1e1b4b">• choose exact model versions</text>
    <text x="410" y="162" font-size="10" font-style="italic" fill="#475569">good for power users &amp; automation</text>
  </g>
</svg>
```

## 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](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](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](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](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](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](https://code.claude.com/docs/en/channels)

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

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

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

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

```quiz
Q: What do the CLI, desktop app, IDE extensions, and channels share?
- The same graphical interface rendered differently
- The same agentic engine underneath; they differ in how they feel to use, not in what they can do
correct: 1
explain: There is one model + tools + loop. Each surface is a frontend over it — the CLI is canonical and scriptable, the IDE shows inline diffs, the desktop manages projects, channels push mobile events in.

Q: What is the main payoff of the IDE extension over a plain terminal?
- It adds new capabilities the CLI cannot do
- Workspace awareness — it sees your active file, selection, and terminal errors without manual copy-paste
correct: 1
explain: The extension wraps the same engine but feeds it IDE context automatically (open files, selection, error panes). The underlying tools are identical to the CLI.

Q: How do channels deliver messages into Claude Code without exposing a public URL?
- A webhook is opened on a public server
- A plugin runs locally on your machine and polls the platform's API, acting as a bridge
correct: 1
explain: The channel plugin runs on your computer and polls the messaging platform. No inbound port is opened; the plugin forwards polled messages to the local Claude session.

Q: Subscription vs API billing — which fits a scripted CI/CD job that must pick exact model versions?
- Subscription (Pro/Max), because it's a flat fee
- API usage, because it's pay-per-token with granular model and billing control
correct: 1
explain: API mode talks directly to the Anthropic API, giving per-token billing and exact model selection — the right fit for automation. Subscription is for predictable daily-development cost.

Q: Community tools (GitHub, Slack, Jira integrations) extend Claude Code by…
- adding a second, separate engine that runs in parallel
- adding new tools the existing engine can call inside its loop
correct: 1
explain: Community tools are MCP servers and plugins. They grow the tool menu the existing loop can reach for; they don't add a new engine.
```