Max_tool_calls exceeded: the counter appears to reset after compaction

There have already been reports that built-in tool calls can exceed max_tool_calls. I may have found a clue to one possible cause: the tool-call counter appears to reset after server-side compaction.

I observed a Responses API response where max_tool_calls was set to 10, but 18 built-in web search calls completed. The stored response output had this exact sequence:

  1. 8 completed web_search_call items, then hit the token threshold
  2. 1 compaction item ← Count reset here! …I think
  3. 10 more completed web_search_call items
  4. 1 more web_search_call, left at status “searching” ← the limiter kicks in, working fine

And, other same previous_response_id chain contained item, exactly 10 calls completed and the 11th stopped at searching — max_tool_calls: 10 was worked.

The affected response shows the same “stop at the 11th call” behavior, but only after the compaction. This suggests that the tool-call budget was reinitialized at the compaction boundary. 8 calls count before the compaction were probably reset.

So the observed behavior contradicts the documented behavior, and if it is reproducible, it may account for at least some of the reported cases where max_tool_calls is exceeded.

These were the parameters in effect when the behavior occurred:

{
  "model": "gpt-5.6-sol",
  "max_tool_calls": 10,
  "tools": [{"type": "web_search"}],
  "context_management": [
    {"type": "compaction", "compact_threshold": 100000}
  ],
  "background": true,
  "store": true,
  "previous_response_id": "..."
}

If necessary, I can try to reproduce the issue in my own environment.

2 Likes