LaunchpadHQ

Anthropic API

by Anthropic PBC

Getting-started guide

Getting Started with the Anthropic API

The same models as the chat assistant, billed per token — and under a contract with the opposite privacy default.

Current prices: $0.10 input / $0.50 output per million tokens · See all plans

Last reviewed 2026-10-14 · for Anthropic API

How it works

Your own code sends text to Anthropic's models and gets a response back, instead of you typing into a chat window. You create an account on the developer console, generate a key, and your program sends requests with that key attached. You read what comes back, change the request, and send it again.

What it is

A pay-per-use interface to the same model family behind the Claude chat assistant.

Aimed at people building something — a tool, a script, a product feature — rather than at people who want to chat.

Billed by usage with no subscription floor, which means near-zero cost while you experiment and real cost at volume.

Governed by commercial terms, which have a different and stricter privacy default than the consumer chat product.

Before you start

You need to write or run code. There is no interface here — the console has a testing workbench, but the product is the endpoint.

Pricing is per million tokens and differs sharply by model: the largest models cost many times what the smallest do, and the text a model writes back costs more than the text you send it. Anthropic's pricing page lists the current rate for each model, including older ones.

Batch processing halves the cost in both directions for work that does not need an immediate answer. If your job can wait, this is the single largest saving available.

Set a spending limit in the console before your first real run. Runaway loops are the most common way beginners get an unpleasant bill.

Getting set up safely

Official source: Anthropic developer documentation

Create an account on the developer console — this is separate from any chat subscription you may already pay for, and one does not include the other.

Generate an API key and treat it like a password. Anyone holding it can spend your money.

Store the key in an environment variable, never inside your code. Keys committed to a public repository are found and abused within minutes.

Set an organisation spend limit before writing anything that runs in a loop.

Start with the cheapest model that could plausibly work. Moving up is easy; discovering you overpaid for a month is not.

Official docs ↗

Security & privacy

This is the same company as the Claude chat assistant and the default is reversed. API traffic falls under commercial terms, which means it is not used to train models by default, and inputs and outputs are deleted from backend systems within about thirty days. The consumer chat product trains on personal-plan conversations unless you opt out; the API does not train on them at all.

Practical implications

  • Routing work through the API rather than a personal chat account changes the contract you are operating under, not just the interface.
  • Submitting feedback is the material exception to the no-training baseline — feedback you send can be retained and used.
  • Zero-retention arrangements exist for qualifying organisations, but they are arranged through sales rather than switched on in a dashboard.
  • Content flagged for policy violations is retained longer regardless of your configuration.

The transferable lesson: which door you walk through determines which contract you are under. Two interfaces to the same underlying model can have opposite data defaults, and neither one advertises this at the moment you paste something sensitive.

What it's good (and not good) at

Best at

  • Building the same operation into a repeatable pipeline
  • Processing many items in bulk, especially where batch pricing applies
  • Embedding assistant behaviour inside a product you are building
  • Work where a stricter data contract is a requirement rather than a preference

Okay at

  • One-off tasks, where the chat interface is faster and cheaper
  • Cost prediction, which is straightforward per call and surprising in aggregate

Avoid

  • Casual use — a subscription is cheaper for conversation
  • Any project without a spending cap configured
  • Shipping a key in client-side code, ever

First things to try

Make one call from the console before writing any code

Uses the console's testing workbench to send one message to a model and read the reply, with no program involved.

Why this one: Confirms your key, your account, and your billing work, without a debugging session in the way.

Tweak: Send something deliberately trivial. You are testing the plumbing, not the model.

Price your actual job before you build it

Runs one representative item, then multiplies by your real volume.

Why this one: Per-call costs look negligible and per-month costs frequently do not. Do this arithmetic while it is still cheap to change your mind.

Tweak: Price it against the cheapest model too. The difference is often larger than the quality gap.

Move a bulk job to batch processing

Submits a set of requests together for processing later at half the per-token rate, instead of sending each one and waiting for its answer.

Why this one: Half price in both directions is the biggest lever available, and it costs nothing but patience.

Tweak: If you find yourself waiting on results interactively, the job was not a batch job.

Put the key in an environment variable on day one

Stores the key in your system's settings, where your program reads it at run time, so it never appears in the code itself.

Why this one: Every leaked-key story starts with "I was going to fix that later".

Tweak: Add the environment file to your ignore list in the same commit, not the next one.

Common pitfalls

  • A chat subscription does not include API credit. They are separate products with separate billing. Paying for one buys you nothing on the other.
  • The promotional rate expires. The discounted mid-tier price ends on 2026-08-31 and reverts to the standard rate. If your budget assumes the lower number, it breaks that day.
  • Loops are how people get surprised bills. A retry that does not stop, or a batch larger than you thought, runs up cost quickly. Set the spend limit first, not after.
  • Keys in public repositories are found within minutes. Automated scanners watch for them continuously. Environment variables are not a best practice here, they are the minimum.
  • The most capable model is rarely the right first choice. Start cheap and move up only when a specific failure justifies it. The price gap between tiers is far larger than the quality gap for most tasks.

Where to next

Want the full picture first? See the Anthropic API overview for pricing, the free tier and related tools.