Most developers reach for an SDK the moment they start working with a language model API. That is completely understandable. But here is the thing: the SDK hides everything. When something breaks at 2am and your agent is returning garbage, you need to know exactly what is going over the wire. No abstractions. No magic. Just raw HTTP.

This article is about understanding and debugging LLM API calls at the network level, without leaning on libraries like the OpenAI SDK or Anthropic's client. The methods below apply to any provider, whether you are using Claude, Gemini, or an open-source model hosted on Hugging Face.

Why Skipping the SDK Teaches You More

SDKs are convenient. They handle retries, parse responses, and abstract away headers. But that convenience comes at a cost: you never see the actual shape of a request. You miss the stop_reason field. You miss the usage object. You miss the moment a model signals it wants to call a tool instead of answering.

When you go raw, every field becomes visible. You start to understand why stateless APIs require you to resend the full message history every single time. You realize that max_tokens is a hard ceiling, not a suggestion. A truncated response looks identical to a complete one unless you explicitly check why the model stopped generating.

Developers who understand the raw layer also find it easier to switch providers. The patterns are nearly identical across the board: a POST request, a JSON body with a model name and messages array, and a Bearer token in the Authorization header. Once that clicks, moving from one provider to another is mostly find-and-replace work.

So how do you actually inspect these calls in practice? Here are five methods that work well in 2026.

Method 1: Use curl Directly

This is the most direct approach. No dependencies, no setup. Just a terminal and an API key. Here is what a minimal request to an LLM endpoint looks like:

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-4",
    "max_tokens": 256,
    "messages": [
      {"role": "user", "content": "What is 2 + 2?"}
    ]
  }'

Run that and you get the full raw JSON response printed to your terminal. No filtering. No parsing. The stop_reason, usage, and content fields are all right there in front of you.

Add the -v flag to see every HTTP header going in both directions. This is especially useful when debugging authentication errors or spotting mismatched content-type headers. Many silent failures at the API layer come from something as simple as a wrong header value.

One practical tip: pipe the output to a file and then format it. Most terminals truncate long JSON. You can use curl ... | python3 -m json.tool to pretty-print the response directly. For visual formatting without leaving the browser, an online markdown editor can help you document your findings as you go.

Method 2: Intercept Traffic With a Local Proxy

Tools like mitmproxy let you sit between your application and the LLM API. Every request and response flows through the proxy, and you can inspect or even modify them in real time. This is powerful when you are debugging an existing codebase that already uses an SDK and you cannot easily swap it out.

Terminal showing a raw curl command hitting an LLM API endpoint with JSON response

Setting up mitmproxy takes about five minutes. You configure your HTTP client to route through localhost:8080, trust the mitmproxy certificate, and then watch requests scroll past in a clean UI. You will see the full request body, all headers, response times, and status codes.

Steps to Debug LLM API Calls

Step 1

Use curl for direct API calls.

Step 2

Inspect raw HTTP requests.

Step 3

Log requests and responses.

Step 4

Analyze response JSON fields.

Step 5

Identify stop reasons and token limits.

This method is particularly useful when building multi-step agents. An agent might make four or five API calls in sequence. With a proxy, you can see exactly which call triggered a tool_use stop reason and what the model sent back before your code handled the tool invocation.

It also helps with cost debugging. The usage field in each response tells you input and output token counts. Watching those numbers across a full agent run often reveals surprising token inflation, especially when system prompts grow over time as context accumulates.

Method 3: Log Raw Requests in Node.js Before They Leave

If you are building in Node.js, you can intercept the outgoing HTTP request before it even leaves your process. The built-in http and https modules expose hooks that let you log the full request body. Here is a lightweight pattern:

const https = require('https');
const originalRequest = https.request;

https.request = function (options, callback) {
  console.log('[LLM REQUEST]', JSON.stringify(options, null, 2));
  return originalRequest.call(this, options, callback);
};

This monkey-patch approach logs every outgoing HTTPS request. It is not something you ship to production, but it is invaluable during development. You can see exactly what your agent is sending, including any system prompt mutations that happen dynamically at runtime.

A cleaner production-safe alternative is to wrap your fetch calls in a thin logging utility. Every LLM call goes through one function, and that function logs the request and response before returning. This gives you a permanent audit trail without touching the network layer directly.

What to Log and What to Skip

Log everything during development: the full messages array, model name, max_tokens, stop_reason, and the usage object. In production, be selective. The messages array can contain sensitive user data. Log token counts and stop reasons at minimum. Log the full body only when an unexpected stop reason appears.

Many teams discover token budget issues only after they receive a surprise bill. Logging the usage field from day one, even in a basic CSV or time-series store, gives you the data you need to optimize prompts before costs spiral.

Method 4: Use Postman or Hoppscotch for Manual Exploration

Sometimes you just want to poke at an API without writing any code. Postman and the open-source Hoppscotch are both solid choices for this. You set up the endpoint, paste in your JSON body, add your headers, and hit send.

What makes these tools valuable for LLM debugging specifically is the ability to save and replay requests. You can build a small collection of test prompts, each with slightly different parameters, and compare the responses side by side. This is a quick way to test how changing max_tokens or swapping the model affects output quality and token usage.

Hoppscotch runs entirely in the browser, which means no installation. It also supports environment variables, so you can store your API key once and reference it across all your saved requests. For teams, sharing a Postman collection of LLM test cases is a lightweight way to document expected API behavior.

One underrated use case: testing stop sequences. Many developers never experiment with the stop_sequences parameter. A GUI tool makes it easy to add a stop string, fire the request, and immediately see whether the model halted at the right point. That kind of rapid iteration is harder to do through code alone.

Method 5: Build a Tiny Request Inspector in 30 Lines

If you want full control, write your own inspector. This does not need to be complex. A small Node.js script that wraps the native fetch API, logs everything, and saves responses to disk is enough for most debugging sessions:

const fs = require('fs');

async function inspectedFetch(url, options) {
  const logEntry = {
    timestamp: new Date().toISOString(),
    url,
    request: JSON.parse(options.body),
  };

  const response = await fetch(url, options);
  const data = await response.json();

  logEntry.response = {
    status: response.status,
    stop_reason: data?.stop_reason,
    usage: data?.usage,
    content: data?.content,
  };

  fs.appendFileSync(
    'llm-debug.jsonl',
    JSON.stringify(logEntry) + '\n'
  );

  return data;
}

module.exports = { inspectedFetch };

This writes one JSON line per API call to a .jsonl file. After a full agent run, you can open that file and replay exactly what happened, call by call. You can see where the model requested a tool, where it hit the token ceiling, and where it finished naturally.

Key Fields in LLM API Responses

✓

stop_reason
Why the model stopped generating.

✓

usage
Token usage details.

✓

model name
Identifies the model used.

✓

messages array
Contains conversation history.

Storing responses as .jsonl also makes it easy to pipe data into analysis tools later. Want to calculate average token usage per step? The data is already there. Want to spot which system prompt version produced the most max_tokens truncations? One grep and you have your answer.

For teams building documentation around their agent architecture, capturing these logs and writing them up in an online markdown editor creates a useful internal reference. And if your agent processes any images, tools like a AI background remover or a free image compressor can help you prepare visual assets before they ever reach the API, keeping your token counts lower and your costs predictable.

The Fields Most Developers Ignore

Across all five methods, the same two fields keep getting overlooked: stop_reason and usage. It is worth spending a moment on why they matter so much.

Node.js code showing a wrapped fetch function logging LLM request and response bodies

The stop_reason field tells you the exact reason the model stopped generating. There are four common values:

end_turn: The model finished naturally. You have a complete response.
max_tokens: You hit the ceiling. The response is cut off. Always handle this case.
tool_use: The model wants to invoke a tool. Your code needs to act, not just display text.
stop_sequence: The model hit one of your custom stop strings and halted there.

If your code only reads the text content and never checks this field, you will eventually ship a bug. A truncated response looks identical to a complete one from the outside. The user sees a cut-off answer and wonders why your product feels broken.

The usage field is just as important for long-term sustainability. Token pricing varies by model and provider. Tracking input and output tokens per call lets you catch prompt bloat early. An agent that starts at 500 input tokens per call and grows to 4,000 over a few months is not unusual. Without logging, you will not notice until the bill arrives.

Connecting the Raw Layer to Bigger Architecture Decisions

Understanding how these calls work at the HTTP level also changes how you think about system design. The stateless nature of LLM APIs is not a limitation to work around. It is a design constraint that shapes everything from memory management to cost optimization.

For teams building production agents, this raw-level knowledge connects directly to patterns described in microservices architecture thinking. Each LLM call is a self-contained unit. Orchestration lives in your application code, not inside the model. That separation is actually a feature.

If you are curious about how AI research teams approach these API patterns at scale, the Google AI Research blog and Google Cloud documentation both cover production patterns for model serving that complement what you learn from raw API inspection.

When your agent grows more complex and starts handling images alongside text, you will want to keep those image payloads lean. Running images through a free image resizer before encoding them into API requests can noticeably reduce payload size. Similarly, a reverse image search tool can help you verify that any images your agent processes are what they claim to be, especially in pipelines that pull images from external sources.

Start Small, Then Build Upward

The five methods above are not mutually exclusive. Most developers start with curl, graduate to a local proxy when things get complex, and eventually build a small logging wrapper for production use. Each step deepens your understanding of what the API is actually doing.

The goal is not to avoid SDKs forever. It is to understand the layer beneath them well enough that you are never surprised by what they do. When your agent misbehaves, you want to know within seconds whether the problem is in your code, your prompt, or the model's response. That speed comes from knowing the raw shape of every call.

Try starting with a single curl command against whichever LLM API you use most. Look at every field in the response. Ask yourself: what does each one mean? What would change if stop_reason were max_tokens instead of end_turn? That curiosity is what separates developers who truly understand their tools from those who just use them.

If you are building out a full agent from scratch in Node.js, check out the LLM tag on Stack Overflow for real-world debugging questions from other developers working through the same problems. The community knowledge there is genuinely useful when you hit edge cases that documentation does not cover.