What Is an LLM API Call? A Clear Explanation

An LLM API call is a single HTTP request you send to a large language model provider (like OpenAI, Anthropic, or a proxy service) asking it to generate text, and the response it sends back. In practice it's a JSON payload — a prompt, a system instruction, and some parameters — sent over HTTPS, answered either as one complete JSON blob or as a stream of partial chunks. That's the whole mechanic. The complexity people run into is less about the HTTP part and more about what counts as "one call," how it gets billed, and what happens between the request going out and the text coming back.

This article breaks down what actually happens during an LLM API call, what's inside the request and response, and how usage and cost get measured — the practical stuff you need to know before you build against one.

The anatomy of an LLM API call

Every LLM API call, regardless of provider, is built from the same core pieces:

• Endpoint — a URL like https://api.example.com/v1/messages that accepts POST requests.
• Authentication — an API key sent in a header, usually Authorization: Bearer <key>.
• Messages — an array of turns (user, assistant, sometimes system) representing the conversation so far.
• Model — which model version should process the request.
• Parameters — things like max_tokens, temperature, and stream.
• Response — the model's generated text, plus metadata: token counts, stop reason, model version used.

A minimal call looks like this:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-3-5-sonnet",
    "max_tokens": 500,
    "messages": [
      {"role": "user", "content": "Summarize this changelog in three bullets."}
    ]
  }'

The response comes back as JSON containing the assistant's reply and usage data:

{
  "id": "msg_01Ab...",
  "role": "assistant",
  "content": [{"type": "text", "text": "- Fixed pagination bug\n- Added dark mode\n- Improved cold start time"}],
  "usage": {"input_tokens": 42, "output_tokens": 18}
}

That single request-response exchange is what's typically meant when people say "one API call." See the messages docs for the full request shape.

What actually happens between request and response

When you send the request, several things happen on the provider's side before you see any output:

1. Auth and rate-limit checks — your key is validated and checked against your plan's limits.
2. Tokenization — your input (system prompt + messages) is converted into tokens, the sub-word units the model actually processes.
3. Inference — the model generates output tokens one at a time, each new token conditioned on everything before it.
4. Formatting and return — the generated tokens are decoded back into text and wrapped in a response object with metadata.

None of this requires you to manage infrastructure — it's why the "API" part matters. You're not running a model on your own hardware; you're paying to send input and receive output over the network.

Streaming calls vs. standard calls

Not every LLM API call returns its answer all at once. There are two common modes:

• Standard (blocking) calls — you send the request and wait until the full response is generated before getting anything back. Simple to implement, but slow for long outputs since nothing appears until the model is completely done.
• Streaming calls — the same request, but with "stream": true. The response arrives as a sequence of server-sent events, each containing a small chunk of text, so you can render output as it's generated — the same effect you see in chat interfaces where text appears word by word.

const response = await fetch("https://api.subtoapi.app/v1/messages", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.SUBTOAPI_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "claude-3-5-sonnet",
    max_tokens: 500,
    stream: true,
    messages: [{ role: "user", content: "Write a haiku about deployments." }]
  })
});

Streaming doesn't change what counts as "a call" — it's still one request — but it changes how you have to handle the response on your end, since you're parsing an event stream instead of a single JSON object. Details are in the streaming docs.

How LLM API calls get counted and billed

This is the part that actually affects your bill and your architecture decisions. A few things to keep in mind:

• Tokens, not calls, drive cost. Most providers price by input and output tokens, not by the number of HTTP requests. A call with a 4,000-token system prompt and a 10-token answer costs more than a call with a 10-token prompt and a 4,000-token answer, even though both are "one call."
• Conversation history compounds. Every message you resend as context in a multi-turn chat gets re-tokenized and re-billed on every subsequent call. A 20-turn conversation isn't 20 cheap calls — it's 20 calls where the input grows each time.
• Tool use adds calls, not just tokens. If a model decides to call a tool, that's often a distinct request/response round trip: the model asks for a tool call, your code executes it, and you send the result back as another call. See the tools docs for how that loop works.
• Rate limits apply per call and per token. Providers commonly cap both requests-per-minute and tokens-per-minute, so a handful of very large calls can hit a limit before you've made many requests at all.

If you're building on top of Claude specifically, SubToAPI wraps your existing Claude access in a standard HTTPS API with sub_live_ application keys, so each call goes through the same request/response mechanics described above, with usage metadata and per-seat visibility in one dashboard. You can see the request format in the quickstart or check pricing for plan limits before wiring it into production.

Getting started with your first call

If you haven't made an LLM API call before, the fastest way to understand the mechanics is to make one:

1. Get an API key from your provider.
2. Send a POST request with a model name and a single user message.
3. Read the response body — note the usage field, since that's what determines cost.
4. Try the same request with stream: true and observe how the response shape changes.

Once that loop feels familiar, everything else — multi-turn conversations, tool use, structured outputs — is a variation on the same request/response pattern.

Questions

Is an LLM API call the same as a chat message? Not exactly. A chat message is one turn in a conversation, but a single API call typically includes the entire conversation history up to that point, since most LLMs are stateless between calls and need full context resent each time.

Does a streaming response count as multiple API calls? No. Streaming changes how the response is delivered — in chunks instead of all at once — but it's still a single request and a single call for billing and rate-limit purposes.

What's the difference between an LLM API call and an LLM API request? In practice, they're used interchangeably. "Request" usually refers to the outbound HTTP payload, while "call" refers to the full round trip, including the response — but neither term implies anything beyond a single request/response exchange.