{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifiwyl3oj6m3xz3i74mpeyvtz267k6bsuq5q6cpzmtu7xexpjxnli",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mnctgidx2fw2"
  },
  "path": "/t/prompt-library-variables-used-for-input-seem-to-break-context-in-multi-turn-chats/1382366#post_1",
  "publishedAt": "2026-06-02T13:40:57.000Z",
  "site": "https://community.openai.com",
  "textContent": "Hi everyone,\n\nI’m working on a multi-turn conversational agent using the **Responses API** and the **Prompt Library** , and I’ve run into a strange behavior with how conversation history is handled when using prompt variables.\n\nI wanted to ask if this is a feature or if I’ve stumbled onto a bug.\n\nWhen calling a reusable prompt from the library, I’ve been passing the user’s message into a custom variable slot (like `{{input}}`) instead of passing standard message thread blocks.\n\nFor single-turn interactions, this works perfectly. The variable evaluates server-side, and the model responds exactly as expected.\n\nRecently, I used this same pattern for an agent that handles a continuous, multi-round conversation. After about 10 turns, the agent’s context completely degraded—it started hallucinating earlier questions, looping, and losing track of the conversation entirely.\n\nWhen I checked the **Logs > Responses** dashboard to see what payload was actually being generated, I noticed that the log thread contained **absolutely zero user messages**. It was just a continuous string of back-to-back `Assistant` replies and `Reasoning` steps.\n\nFrom what I can tell, because the `{{input}}` variable is evaluated server-side _after_ the API call is made, the raw developer log doesn’t append it as a formal `role: \"user\"` message in the conversation thread block. As a result, when the next turn happens, the model receives a context window where the assistant is essentially just talking to itself, causing the context to break.\n\nIs this the intended design? Should we strictly avoid using Prompt Library variables to carry primary user input if we plan on running multi-turn chats?\n\nOr is this a logging/payload sync issue where server-side variable injections should ideally be written back into the conversation history object?\n\nI wanted to check if anyone else has navigated this or if there’s a nice way to handle state when abstracting prompts to the dashboard.\n\nThanks for any insights.",
  "title": "Prompt Library variables used for input seem to break context in multi-turn chats"
}