Choosing Your Claude

Anthropic ships one model family under multiple surfaces: a browser-based chat interface (claude.ai), a terminal-native agentic tool (Claude Code), and a raw HTTP API with an OpenAI-compatible endpoint for drop-in programmatic use (the Anthropic API / SDK). Teams also get a managed tier — often called Claude for Work — that layers org-level controls on top of the web interface. All four ultimately call the same underlying models. None of them are the same tool.

The mistake most developers make is treating them as interchangeable. They have different memory models, different context lifetimes, radically different workflows, and different answers to the question of who is responsible for keeping track of what has been done. Picking the right surface for the right task is a force multiplier. Picking the wrong one means rebuilding context by hand, losing work between sessions, or shipping fragile integrations that break when a conversation ends.

The Three Surfaces at a Glance

// who handles what

claude.ai           // You write. It responds. Browser manages the session.
                    // Memory: Projects (manually curated). No filesystem access.

Claude Code         // It acts. Reads/writes files, runs shell commands, edits code.
                    // Memory: local .md files it can read and update directly.

Anthropic API       // You build. Full control. No session state between calls.
                    // Memory: whatever your application layer implements.

claude.ai — The Chat Interface

The browser interface at claude.ai is a conversational UI on top of the API. It handles session management, renders markdown, and provides a low-friction entry point for exploration, drafting, and research. The free tier has usage caps; the Pro tier lifts them and unlocks larger context windows and access to more capable models. Claude for Work (Teams/Enterprise) adds SSO, usage dashboards, and the ability to share Projects across an organization.

Where It Excels

claude.ai is best for tasks that live inside a single conversation: writing, explaining, brainstorming, reviewing a document you paste in, or working through a design question with back-and-forth. The UI manages context automatically — scroll up and the history is there. For exploratory work where the output is text rather than code that needs to run, it is fast to start and requires nothing installed.

Memory in claude.ai: Projects

The web interface offers two memory mechanisms. The first is the conversation thread itself — the model sees everything said so far, up to the context window limit. The second is Projects: a persistent store where you can add instructions, reference documents, and context that gets included at the start of every conversation in that project, without you manually pasting it each time.

Projects are manually maintained. You decide what goes in. You update them when they go stale. The model can read and reference project content but cannot modify it. If you update a design doc, you paste the new version into the project yourself. This is a significant friction point for ongoing technical work — the human is responsible for all writes to persistent state.

Projects keep context available but not current. If your reference documents change as fast as your code does, you will spend meaningful time keeping them in sync.

The Compile-and-Test Workflow

In the browser, the workflow for code looks like this: Claude generates code in the chat, you copy it, paste it into your editor, run it, observe any errors, paste the errors back into the chat, and iterate. This copy-paste loop is the defining friction of web-based AI coding. It is perfectly functional for short functions and contained tasks. For anything involving multiple files, build systems, or iterative test runs, it becomes the bottleneck.

# The browser workflow — fine for small tasks
1. Ask Claude to write parseConfig()
2. Copy from chat
3. Paste into config.js
4. node config.js  → TypeError: cannot read property 'host'
5. Paste error back into chat
6. Repeat from step 2

# Cost: context stays in chat, not in files. You are the integration layer.

When to Choose claude.ai

• Design and architecture discussions where the output is a decision, not a file
• Writing, explaining, or reviewing documents, PRs, specs
• Quick one-off questions that don't need follow-through
• Tasks where you want to stay in the browser and not set up a tool
• Exploratory conversations before you know what you want to build

Claude Code — The Agentic CLI

Claude Code is a command-line tool that runs Claude as an agent with direct access to your filesystem, your terminal, and any tools you configure. It is the same model as claude.ai, but the execution model is fundamentally different: instead of responding to a message, it plans and executes a sequence of actions — reading files, writing edits, running shell commands, checking output — until the task is done or it needs your input.

For a developer comfortable with the terminal, Claude Code closes the gap between "AI suggests code" and "AI ships code." It reads your actual files, not a paste of them. It runs your actual tests, not a hypothetical about what they might return. It writes directly to disk. The copy-paste loop disappears.

Memory in Claude Code: Local Files

This is the part that changes the workflow most significantly. Claude Code supports two layers of persistent memory, both implemented as plain files on disk that the model can read and write directly.

CLAUDE.md — a project-level context file that is loaded automatically at the start of every session. It is checked into the repository. It contains standing instructions: how the project is structured, how to run the dev server, naming conventions, things to avoid. Claude reads it as initialization; you update it as the project evolves. Unlike Projects in the web UI, Claude can propose edits to CLAUDE.md directly, and those edits persist to disk.

Memory files — a directory (by convention, memory/ or .claude/memory/) where Claude can write and update structured notes across sessions. These are markdown files with frontmatter, organized by topic: what the user prefers, decisions made in past sessions, current project state. Because they are plain files, you can read them, edit them, diff them in git, and version them like any other artifact. They are not locked inside a vendor platform.

project/
├── CLAUDE.md              # loaded every session — architecture, conventions
├── .claude/
│   ├── settings.json      # permissions, hooks, model settings
│   └── memory/
│       ├── MEMORY.md      # index of all memory entries
│       ├── user_prefs.md  # how you like to work
│       ├── project.md     # current sprint goals, decisions
│       └── feedback.md    # corrections from prior sessions

The key difference from the web interface: the model writes the memory. You don't have to remember to update a Project document every time you make a decision. You tell Claude something important, Claude saves it, and the next session starts with that context intact. This is the mechanism that makes multi-session work tractable without spending ten minutes on orientation at the start of every conversation.

The browser interface asks you to maintain context manually. Claude Code writes its own notes. For anything that spans more than one session, that difference compounds fast.

The Compile-and-Test Workflow

With Claude Code, the feedback loop becomes a tight automated cycle. Claude runs the tests, reads the failures, edits the code, and reruns — without you in the loop unless it hits something genuinely ambiguous. For straightforward bugs and feature additions, you can watch it work and intervene only when the direction is wrong.

# Claude Code workflow — agentic iteration
1. claude "add rate limiting to the /api/submit endpoint"
   → reads routes/api.php, middleware/, config/
   → writes the middleware implementation
   → runs: composer test
   → reads test failures
   → adjusts implementation
   → reruns tests until green
   → reports what it did

# You review the diff. You own the merge. Claude does the iteration.

Hooks extend this further. A PostToolUse hook can trigger a timestamp update, run a linter, or notify a build system every time Claude writes a file. The hooks configuration lives in .claude/settings.json and is project-specific — different projects can have different automation wired to Claude's actions.

// .claude/settings.json — PostToolUse hook example
{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{
        "type": "command",
        "command": "python .claude/update_site_timestamp.py"
      }]
    }]
  }
}

Things Claude Code Gets Wrong

Agentic autonomy has a failure mode: confidence without correctness. Claude Code will make changes, run commands, and move on — even when the action was subtly wrong. A test passing does not mean the intent was met. A file written does not mean it was written well. The feedback loop is faster, but you still need to review the diff. Skipping that review is how AI-assisted work introduces bugs that were never in a human's hands.

The other limitation is context scope. Claude Code reads files you point it at (or that it discovers through exploration), but it does not have a map of your entire codebase on first run. On large projects, the first session on a new feature involves some orientation cost as it learns the structure. A well-maintained CLAUDE.md front-loads that cost and eliminates most of it.

When to Choose Claude Code

• Any multi-file code task — features, refactors, bug fixes
• Iterative work that spans multiple sessions
• Tasks that require running the project (tests, builds, dev server)
• Any workflow where you're comfortable reviewing diffs rather than prose
• Situations where you want automation tied to Claude's actions (hooks)

The Anthropic API — Direct and Programmatic

The API is what both claude.ai and Claude Code use under the hood. Direct API access gives you complete control over every parameter: which model, the system prompt, the temperature, whether to use streaming, what tools to expose, whether to cache the prompt. Nothing is managed for you. Nothing is hidden.

Anthropic also exposes an OpenAI-compatible endpoint at https://api.anthropic.com/v1/ — accepting the same request shape as the OpenAI SDK. This means you can often substitute Claude into an existing OpenAI integration by changing the base URL and the API key, without rewriting your calling code. It is useful for testing Claude in systems already built around the OpenAI interface, though some Claude-specific features (prompt caching, extended thinking) are only accessible through the native SDK.

# Drop-in replacement via OpenAI SDK (Python)
from openai import OpenAI

client = OpenAI(
    api_key="sk-ant-...",            # Anthropic key, not OpenAI
    base_url="https://api.anthropic.com/v1/"
)

response = client.chat.completions.create(
    model="claude-sonnet-4-6",
    messages=[{"role": "user", "content": "..."}]
)

# For cache_control, thinking, or citations: use the native Anthropic SDK

Memory in the API: You Build It

The API is stateless. Every call is independent. The model has no memory of previous calls unless you send that history yourself as part of the messages array. This is not a limitation — it is the design. It means memory is exactly what your application layer makes it: a database, a file, a vector store, a summarized thread. You control the retention, the retrieval, and the cost.

The implication is that the API is the right surface when you are building a product or a pipeline — something that will run many times, with different users, with structured inputs and outputs. For a one-off coding task or an ongoing development session, the API is overkill. For a production integration that needs predictable behavior, auditability, and control over every aspect of the call, it is the only choice.

# Native SDK with prompt caching (Python) — the production pattern
import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system=[{
        "type": "text",
        "text": system_prompt,
        "cache_control": {"type": "ephemeral"}  # stable system prompt cached
    }],
    messages=conversation_history  # you manage this list
)

# Cached input tokens bill at ~10% of normal rate after the first call

The Compile-and-Test Workflow

There is no inherent workflow for compile-and-test at the API level — you define it. A common pattern for CI-integrated code review: a webhook fires on a PR, your service fetches the diff, calls the API with a code-review prompt, and posts the response as a comment. The "testing" is your CI pipeline. Claude is a step in it, not the operator of it.

For solo development tooling — a custom script that reviews your own commits, generates test cases, or explains unfamiliar code — the API lets you build exactly the integration you want. The overhead is real: you write the scaffolding, manage the keys, handle the errors. But the result is a tool that fits your workflow precisely, rather than adapting your workflow to a tool.

When to Choose the API

• Building a product that makes AI calls on behalf of users
• Pipelines that process structured data (code review bots, content moderation, extraction)
• Integrating Claude into an existing system that already uses OpenAI
• Any workload that needs fine-grained cost control, caching, or custom retry logic
• Batch jobs that run offline without a human in the loop

Memory Comparison: The Honest Summary

Memory is the axis where the three surfaces differ most in practice, and where the choice has the most impact on sustained productivity.

// Memory model comparison

claude.ai (Projects)
  persistence:  manual — you write, you update, you curate
  scope:        per-project, shared across conversations
  model writes: no — read-only from model's perspective
  portability:  low — locked in Anthropic's platform

Claude Code (CLAUDE.md + memory/ files)
  persistence:  automatic — model writes on request or by convention
  scope:        per-repository; version-controlled alongside code
  model writes: yes — reads and writes directly to disk
  portability:  high — plain markdown, committed to git

Anthropic API (application layer)
  persistence:  you build it — database, files, vector store, whatever
  scope:        whatever your application defines
  model writes: indirectly — through your code
  portability:  total — it is your system

The practical advantage of Claude Code's memory model is the elimination of re-orientation cost. A session on a codebase you've been working in for weeks starts with everything Claude needs already present. It knows your preferences, the decisions you've made, what you tried that didn't work, and what the current sprint goal is. That is not magic — it is an index file that got updated incrementally, session by session, by a model that was paying attention.

The productivity gain from Claude Code's local memory files is not about the files themselves. It is about who is responsible for keeping them current. When the model writes its own notes, the human stops losing context on tool handoff.

Practical Setup for CLI-Comfortable Developers

If you are comfortable at the command line and work on real codebases — rather than one-off scripts — Claude Code is almost certainly the right default surface for daily development work. Here is the setup that makes it most effective:

Start with a Strong CLAUDE.md

Invest time in the project context file before relying on it heavily. A good CLAUDE.md should tell Claude: how the project is structured, how to run the dev server and tests, conventions that matter (naming, error handling, where config lives), and what not to do (dependencies to avoid, patterns the team has agreed to abandon). Keep it under 300 tokens — if it is longer, some of it belongs in a referenced file loaded on demand.

# CLAUDE.md skeleton
## Local development
docker compose up          # full stack at localhost:8080
php -S localhost:8080 -t . # quick alternative

## Architecture
No framework. Apache → .htaccess rewrites → PHP files.
Request flow: browser → Apache → .htaccess → PHP → includes/header.php

## Conventions
- Color tokens only in css/tokens.css, never inline
- New topics: copy topics/_template.php, add to includes/topics.php

## Do not
- Add npm, composer, or any build step
- Use inline styles for colors that belong in tokens.css

Use Permissions to Reduce Prompt Friction

Claude Code will ask permission before running commands unless you explicitly allow them. For your own development machine, it is worth pre-approving the commands you use constantly (test runners, linters, build tools) so the interaction is not interrupted by confirmation prompts for routine operations. The /fewer-permission-prompts skill can scan your session history and generate an appropriate allowlist automatically.

Scope Tasks Tightly at Session Start

Claude Code works best when it starts with a clear, bounded task. "Implement the rate-limiting middleware from the spec in architecture.md" will produce better results than "work on the API." The model can take a broad goal and narrow it, but you pay for that exploration in token cost and iteration time. Tight input, tight output.

Review Diffs, Not Prose

The workflow review checkpoint is the diff, not a post-hoc explanation. Once Claude reports done, run git diff or equivalent before accepting the work. Claude's explanation of what it did is generally accurate, but the code is the authority. Train yourself to review the actual change, not the summary of it.

# After every Claude Code session
git diff                  # what changed and where
git diff --stat           # files touched at a glance
npm test                # or whatever your test runner is
# then: git add -p to review hunks before staging

Use the Web Interface for What It's Actually Good At

Even with Claude Code as the primary tool, claude.ai remains useful for conversations that should stay conversational: working through a design decision before writing any code, reviewing a document someone shared with you, understanding an unfamiliar technology. The surfaces are complementary. The mistake is using the web interface as a substitute for Claude Code on file-intensive work, not using it at all.

Decision Heuristic

function pickYourSurface(task) {
  if (task.isProduction() || task.hasStructuredIO()) {
    return "API";          // build the integration
  }

  if (task.touchesFiles() || task.spansMultipleSessions() || task.needsTestRuns()) {
    return "Claude Code";   // agentic CLI, local memory
  }

  return "claude.ai";      // conversation, review, exploration
}

A Practical Checklist

Before starting any AI-assisted dev task:
  [ ] Does this touch files on disk?          → Claude Code, not the browser
  [ ] Does this span multiple sessions?        → Claude Code with memory files
  [ ] Does this need tests to run?             → Claude Code with permissions set
  [ ] Is this a design/review conversation?    → claude.ai or Claude Code in chat mode
  [ ] Is this going into a production pipeline? → API with caching + retry logic

Claude Code setup checklist:
  [ ] CLAUDE.md written and committed to the repo
  [ ] memory/ directory initialized and indexed
  [ ] Test runner and linter pre-approved in settings.json
  [ ] PostToolUse hooks configured for any build automation
  [ ] Habit: git diff before accepting any agentic session

API setup checklist:
  [ ] Native SDK for net-new code; OpenAI SDK only for drop-in replacements
  [ ] Prompt caching on stable system prompt and large reference docs
  [ ] Exponential backoff with jitter on all calls
  [ ] Conversation history managed explicitly — never let it grow unbounded
  [ ] Batch API for offline or non-time-sensitive workloads

The three surfaces are not competitors. They are different tools for different stages of work: the API for building, Claude Code for shipping, claude.ai for thinking. Developers who treat them as interchangeable end up doing more work than necessary. Developers who learn where each one starts and stops find they rarely need to be the integration layer themselves.