Skip to main content
Stream terminal · not an HTTP error. This code arrives in the typed terminal error event on the run’s stream, when a run that started dies because the model answered but produced nothing usable — an unparsable submission at the parse stage. The run ends with status error; only signed receipts settle and the rest of the reservation is released. Distinguish this from declined_to_spend: a decline is a run that never spends — POST /v1/sessions still returns 201, the stream carries an abstain with the parse’s reasoning, and the session settles abstained at $0 (the pre-spend signal is estimate.would_run: false). It is not an HTTP 422; that code is reserved and not emitted today. parse_failed is different: the run started, and then could not turn the model’s answer into something usable.

​
The shape

message is prose for humans and may change; program against code. Stream codes are an open enum — handle an unknown code like internal.

​
How to fix

  • Rephrase the query — that usually helps more than retrying: name the entity you want one row to be, and keep constraints concrete.
  • Retrying the same text may help (model output varies), but repeated parse_failed on the same query is signal about the query.
  • Preview what the parse understands for free with POST /v1/sessions/estimate before spending.

​
Reproduce it

Rehearse the run-level error ending (typed terminal, reservation released) with the FN_TEST_ERROR sentinel — deterministic, $0.