Loading today’s stories
Build1 distinct publisher3 min readPublished
OpenAI's create response reference is explicit that a chained request does not inherit earlier instructions, and because the field is optional, the turn that loses your JSON contract or your safety text still succeeds.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Two different problems ride in one request body. Response lineage answers what was said before. Request options answer how this call should behave. `previous_response_id` only addresses the first, and OpenAI's create response reference is explicit that earlier instructions do not travel with it: the continuation can send the same policy, a different one, or none at all [2].
The reason this bites instead of erroring is that both halves are individually legal. The `instructions` field is optional [4], so a continuation carrying a new input and a response ID is a complete request, and the thread's earlier turns are still in context [5]. My read of that combination: a model that can see its own prior JSON output will often keep emitting the same shape by imitation, so the omission surfaces as intermittent format drift rather than a clean failure. Nothing in the response tells you the contract was withdrawn.
The fix in the dev.to write-up is boring in the right way. Model, input, instructions and one optional state reference go into a single record, and `ArgumentException.ThrowIfNullOrWhiteSpace` rejects blank instructions before any transport code runs [8]. The same builder refuses a payload carrying both `previous_response_id` and `conversation`, on the grounds that moving to a durable Conversation object should be a deliberate code change rather than an HTTP 400 found in production [7]. A stack trace on your own machine is cheaper than a schema violation in someone else's parser.
Treat the validation claim as a claim about that author's workload. The verifier checks seven payload behaviors [10], and the merged pull request reports five repeated runs producing identical output with no account, API key, paid request, or model call [11], which is 35 assertion outcomes, none of them touching a model [14]. What has to be true for that to transfer: your dominant failure mode is omission at construction, not non-compliance after receipt. The author's stated reason for staying offline is that a live call adds latency and output variability without proving that every future call site builds the payload correctly [12]. The sample stops before HTTP and writes only a narrow JSON shape with string input and `store: true` [13], so it says nothing about what the model does with the policy once it arrives.
I would take this tradeoff in an application where a downstream parser depends on the JSON contract. The design detail worth copying is that the builder demands instructions rather than silently reattaching a stored policy, because replacing instructions mid-thread is a legitimate use of the chaining pattern that OpenAI's conversation state guide advertises [3]. Requiring the field keeps both paths visible, where auto-injection would move the silence one layer down.
Ranked by verification strength, evidence, and original report placement.
According to the dev.to write-up, a Responses API response ID carries conversation state forward but does not carry the prior top-level instructions, so turn two can quietly run without the expected output-format, tool, or safety policy.
The create response reference states that earlier instructions are not carried into a request that uses previous_response_id; the new request can supply the same instructions, different instructions, or none.
OpenAI's conversation state guide shows the chaining pattern directly: with previous_response_id, a new response can continue from an earlier one without resending the full conversation.
The API's instructions field is optional; the author makes it mandatory in his own request builder as an application invariant rather than an API requirement.
A continuation that sends only the new input and the earlier response ID has conversation context, but not the top-level policy.
The worked example uses model gpt-5.6, store: true, and the policy string "Answer in JSON with keys summary and risks.", repeated beside previous_response_id on the second turn.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · September 2, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Bedrock turns GPT-5.6 throughput into a routing choice, with residency as the price1 distinct publisher
build
Your inference bill is an architecture defect: declare the task before you call the model1 distinct publisher
build
MCP's empty-string cursor: the null check that hides most of a tool catalog1 distinct publisher
build
Two buyers, one price: Patel says 2027's new compute is already half spoken for1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Documented boundary, self-reported tooling
The claim everything else hangs from — a chained request starts with no inherited instructions — is attributed directly to OpenAI's create response reference, and the two payload snippets make the consequence legible. Past that line the ground softens: the seven verifier checks, the passing audits and the byte-identical output are the author describing his own repository, and no version or link pins the reference being quoted. Strong on the API fact, thin on anything a reader could verify without cloning the code.
One author's branch
Nobody else appears in this story. There is a merged sample on one main branch, run by the person who wrote it, and no team, product, issue thread or downstream user adopting the repeat-policy-every-turn rule. Putting a number on that would be manufacturing a footprint that the reporting does not describe.
Faintly dramatised, largely honest
The piece talks itself down more often than up: not an SDK replacement, instructions are not authorization, state choice deserves a product decision. What pushes it slightly past level is tone rather than substance — documented, intentional API behaviour is framed as something that happens 'quietly' — plus a gpt-5.6 model string that arrives unsourced and invites more currency than it has earned.
Portfolio post, no vendor money
A practitioner publishing his own repository on a platform that rewards a steady cadence, closing with an engagement prompt and a sign-off — the pull toward volume is visible. There is no product being sold, no sponsorship, and the advice argues for more local friction rather than for anyone's purchase, so the incentive shapes how often this gets written far more than what it says.
Act on the rule, hold the receipts
Confidence splits cleanly. The instructions boundary is safe to design around now. Everything asserted about the sample — audits, repeated runs, identical bytes — is uncorroborated, sits with a single publisher and a single author, and would take a second party minutes to confirm, which is exactly why its absence keeps this mid-range.