Measured diagnosis · 17 October 2026 · 9 min read

The AI node didn't fail — it ran out of budget before writing

The node is green, the request returned HTTP 200, usage shows billed tokens and yet content is empty. It is not a timeout, not the credential, not the prompt: the model spent everything you gave it on thinking. We measured this in two different flows, and the numbers explain the whole symptom.

The symptom, exactly as n8n shows it

An HTTP Request node pointed at a model API with reasoning enabled returns this (trimmed):

{
  "choices": [{
    "message": { "role": "assistant", "content": "" },
    "finish_reason": "length"
  }],
  "usage": {
    "prompt_tokens": 660,
    "completion_tokens": 1200,
    "completion_tokens_details": { "reasoning_tokens": 1200 }
  }
}

Three clues in one object, and all three matter:

• content empty but HTTP 200: the call completed. There is no error to catch.
• finish_reason: "length": the model did not finish, it was truncated.
• completion_tokens equal to your max_tokens and all of it in reasoning_tokens: the budget went to thinking, not writing.

And yes, those tokens are billed. An empty response is not free: it is the invoice for reasoning that never produced anything.

The numbers we measured

Same input, same prompt, same batch of four businesses. The only change: reasoning on or off.

The difference is not cosmetic: it is 3 to 7 times the output cost for the same work, plus a failure mode that shows up exactly when the batch is largest. In the meeting-extraction flow — a far heavier task than scoring a business — we measured 2,031 reasoning tokens against 1,216 of useful output. Two thirds of the budget went to thinking; with max_tokens at 1,200 that flow would never have written the JSON at all.

Why it gets worse when you upgrade the model

Intuition says the opposite: «I'm paying for the better model, it should work better». But the failure does not depend on model quality — it depends on the ratio between how much it reasons and how much you let it write. Stronger models reason more, so a max_tokens that worked on the cheap model can be too small on the expensive one — with the same symptom: green node, empty output.

Flow 01 ships with max_tokens: 1200 and runs clean on the fast model. Switch modeloIA to the pro model without touching the body and you will most likely see the empty response on the first large batch. It is not a defect in the kit: it is the parameter you must move together with the model.

The 60-second diagnosis

1. Read usage, not the node. If completion_tokens equals your max_tokens exactly, the model was cut off.
2. Read finish_reason. length = budget exhausted. stop with empty content = a different problem (prompt or filter).
3. Read reasoning_tokens. If it takes more than 50 % of the total, either disable reasoning or raise the limit; there is no third option.
4. Reproduce with a single item. If one item works and four fail, it is budget, not logic: reasoning cost does not scale the way you assume with batch size.

The three fixes, in order of preference

1. Disable reasoning when the task is formatting. Scoring against a rubric and returning six keys needs no deliberation; it needs obedience to the format. That is what the kit does by default, and it is why the measured cost is 117–121 tokens per lead instead of 351–800.
2. Raise max_tokens when the task genuinely needs to think. Extracting a full meeting into JSON is one of those: that is why flow 02 uses 4,000 with the pro model and 6,000 with the fast one. A high limit is not billed unless used; a low limit is billed and produces nothing.
3. Shrink the batch. Four leads per request is a compromise between speed and risk. If your prompt grows, lower the batch before the limit.

What you must not do: add a silent retry. Retrying the same request with the same budget produces the same empty response, billed twice. If the flow must retry, let it retry with a higher limit or a smaller batch — not by repeating the same roll.

The safety net that actually works

A flow cannot depend on the model behaving. Our merge node pairs by id and discards orphan or empty responses by design, so a bad response does not break the run: it yields fewer rows and leaves a trace. Flow 02 adds a quality gate on top: if extraction confidence is low or the company name is missing, nothing is written to the CRM and the reason is returned over HTTP.

That is the pattern we recommend for any AI automation: the model is a fallible data source, and the flow must know what to do when nothing arrives. A red node is visible; an empty response slips into the spreadsheet and you find it three weeks later.

Quick list for «the node is green but returns nothing»

1. completion_tokens == max_tokens → budget exhausted (this article).
2. reasoning_tokens high → disable reasoning or raise the limit.
3. finish_reason: "stop" with empty content → check the prompt and response_format.
4. HTTP 200 with content set to null → check whether the model returned the JSON in a different field (some do when asked for «JSON only» without strict mode).
5. All clean and still 0 rows → the problem is the next node: id pairing or stateful deduplication.

Related: the five stages of the flow · the scoring rubric · dedupe memory · all articles