Tool call history and performance
Every tool keeps a history of its calls: what it was asked, what it returned, and whether it succeeded. For custom AI tools and custom code tools, the history also shows what each call cost and how long it took. Use it to see how a tool is really being used, to find the calls that went wrong, and to turn real calls into test cases.
Where to find it
A custom-built tool: open the thunk's Custom-built tools pane, select the tool, and open the Call history tab.
A tool from a connection or library: open the tool's detail in the thunk's Connections pane and expand Call History.
You can also start from a run. In a step's or work item's activity log, a call to a custom-built tool has a Call history link under it. The link opens that tool's Call history tab with that call expanded and outlined. If the call is older than the most recent 100, the tab says it is not in the list.
If the tool hasn't run yet, the tab says No call history recorded yet. History fills in as the tool is called. The list shows the most recent 100 calls.
Reading a call
Each call shows its status, the Inputs the caller passed, and the Output the tool returned. Expand a call to see its details. If the inputs are a large property the step already had, or the output is a large result the agent then wrote onto the work item, map those fields so the agent does not copy them. See Map a tool's inputs and outputs to the work item.
A custom AI or code tool with Reuse identical lookups on also shows a cache hit or cache miss chip on the call. cache hit means this call reused a recent result and did not run the tool (and did not call tools it would have called). That chip is not the model's cached prompt tokens on the Cost view. See Cache results of a custom AI or code tool.
For a custom AI tool, a call is a complete run of the tool's own AI agent. Expanding it shows that run step by step — what the agent read, which tools it called, and what it decided — the same way you would review a workflow step's run. When a call took longer than you expected, that run's Why so long? breaks its time down. See Analysis of AI behavior.
Turn a call into a test
Each call has Add to tests. It saves that call's inputs as a new test case for the tool, so a real-world case — especially one that went wrong — is checked every time the tool changes. See Automated tests for custom tools.
Add to tests is unavailable while the tool builder is changing the tool.
Performance views for AI and code tools
A custom AI tool's history has five views, chosen at the top of the tab:
View | What it shows |
Calls | The list of calls described above. |
Cost | What the tool's calls cost. |
Working time | How long each call spent doing the work, with the waiting it measured taken out. |
Wall clock | Each call's whole span, from start to finish, waiting included. |
Tokens/sec | How fast the model generated its answer — output tokens per second of model time. Time spent running tools is not included. |
The cost, time, and speed views work like the Cost and Time tabs in Monitor, but for one tool: typical and worst-case figures, a chart of every call over time, and a list of the heaviest calls, each of which opens the call itself. You can colour the chart's dots by a second reading, such as the model a call ran on; the choice carries across views, so you can compare cost and time for the same calls. See Token Costs and Time Analysis for how to read these figures.
The performance views cover calls the tool made while doing real work. Runs from Try It and tool tests appear in the Calls list but are not counted in the cost, time, and speed figures, so those figures describe real use; each view says how many calls it is based on.
Code tools
A custom code tool's history has the same views except Tokens/sec: the code itself does not use an AI model, so there is no generation speed to show.
Cost is what the AI tools the code called cost. A code tool is billed only for those, so a call that called no AI tool costs nothing.
Working time and Wall clock also say how much of the time was spent waiting on the tools the code called, and how much was the code's own work. A slow call that is mostly tool time points at a tool it calls, not at the code.
A call with no recorded figures, such as one made before these views were added, stays in the Calls list, and each view says how many it leaves out.
Other tool types — database, spreadsheet, and connection tools — show the Calls list only.
Using it
After a change to a tool, compare its cost and time views before and after, to see whether the change made it slower or more expensive.
When a tool fails for some callers and not others, open the failed calls and compare their inputs with calls that worked. The difference is usually a missing or badly formatted input — tighten that input's description.
For a shared tool, the history shows every call from every step that uses it, so it is the quickest way to see how the tool is actually used.