Dify Community Reports a Gap in Agent History Replay Caching; Random Tool Call IDs Could Raise Inference Costs

Dify’s tool-using agents have a caching issue that deployment teams may want to investigate. A community report published on October 9 said that when the system rebuilds history for the next turn, it generates a new random identifier for a previous tool call even when the call’s content has not changed. The reported environment was Dify 1.17.1 self-hosted from source, and the issue focuses on the history assembly flow for Function Calling agents. Issue report

The report points to organize_agent_history: the code iterates over past tool names, uses uuid.uuid4() to create a tool_call_id, then uses the same identifier for the tool call and its result. This keeps each pair matched within a turn, but the fields in the history messages differ each time they are replayed. The reporter’s suggested check is to have an agent use a tool, continue the conversation, and compare whether the ID for the same historical call changes between the requests sent in the two turns. Reproduction steps and code location

The technical risk stems from how prompt caching matches prefixes. Anthropic’s documentation says that caching covers tool definitions, system prompts, and messages; if content before a cache breakpoint changes, the prefix hash changes as well. So if the changing ID appears in the actual model request, it could prevent reuse of the historical prefix containing that call. Whether earlier, unchanged content can still be cached depends on the breakpoint configuration. This inference cannot be translated directly into a billing increase across all providers. How prompt caching works

The report proposes deriving a stable UUID from the history record’s primary key, tool index, and name, to preserve consistency across turns while keeping IDs unique within a turn. As of this check, the issue remains open. The technical reply on the page came from an automated bot and should not be treated as maintainer confirmation; the report also provides no controlled measurements of cache hit rates or costs. Proposed fix and discussion

Engineering teams can first save requests from adjacent turns and check whether the only difference is the ID, then compare server-side cache-read tokens and latency. Teams should monitor whether upstream adopts stable IDs, whether tool-result pairing passes validation, and whether other prompt-assembly fields still change. That evidence will help determine the fix’s actual benefit.