Skip to main content
GET
JavaScript
An agent that costs too much is almost always spending its window on something you did not expect: a tool set with three hundred tool definitions, a memory appendix nobody trimmed, a tool that returns a megabyte of JSON. This endpoint tells you which.

Two different units, side by side

This is the thing to internalize before you build anything on this endpoint.
  • contextLengths values are character counts. Every one of them.
  • inputTokens and cachedInputTokens are tokens.
They sit on the same object with no unit in either name. An objective whose rendered system prompt is 41 characters long reports systemPrompt: 41, right next to inputTokens: 660.
Do not sum contextLengths and compare it to inputTokens. One is characters, the other tokens. Use the components to see proportions, and use inputTokens for the absolute number.
Characters rather than tokens is a deliberate choice: it stores the raw measurement, so the token estimate can improve without rewriting history. Divide the total by inputTokens if you want your model’s rough characters-per-token ratio.

What each component is

The interesting one is almost always toolDefinitions. In the sample above, before the agent had said a single word, tool definitions were 1,246 characters against a 159-character prompt. Every objective pays that on every model call. That is what tool filters and progressive discovery exist to shrink. The second most interesting is toolResults, which is what tool result clearing reclaims during compaction.

It only sees the current window

Diagnostics describe the objective’s live context window, and they grow as it runs:
Everything reads zero before the first model call, because nothing has been assembled yet.
A terminal objective returns all zeros. STATE_FINALIZED, STATE_FAILED, STATE_CANCELLED, and STATE_TIMED_OUT all report inputTokens: 0 and every component at 0, even a run with sixty events behind it. The response is a 200, so you cannot tell “no data retained” from “used no context.”Read diagnostics while the objective is STATE_PENDING, STATE_RUNNING, or STATE_WAITING. For a post-mortem, list its context windows instead: those retain promptTokens and completionTokens per window, though not the component breakdown.

Use it to find the fat

Grab a healthy objective mid-run and rank the components. The one at the top is where your money is.
What to do with the answer:
  • toolDefinitions dominates. Narrow the tool set with an include filter, or turn on progressive discovery so definitions load on demand.
  • toolResults dominates. Enable toolResultClearing on the variation, or make the tool return less.
  • skillsMemory dominates. Your manifest is too big. Split the layer, or tighten the entry descriptions.
  • assistantMessages dominates. The agent is thinking in circles. That is a prompt problem, not a config one.
cachedInputTokens tells you how much of the window the provider served from its prompt cache. A high number is good: the stable head of your prompt (system prompt, tool definitions) is being reused across turns rather than re-billed.

List context windows

Per-window token counts, retained after the objective ends.

Preventing tool bloat

The fix when toolDefinitions is eating your window.

Create a variation

Compaction, tool result clearing, and the trigger threshold.

Compaction

What happens when the window fills anyway.

Authorizations

Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Path Parameters

workspaceId
string
required
Example:

"workspace_01HXKD2E5NQM3T9AYWCF133E3Q"

objectiveId
string
required

The ID of the objective. Supports "external_id:" prefix for external IDs.

Example:

"obj_01HXKD2E5NQM3T9AYWCFQAZGFV"

Response

OK

diagnostics
object
required

Diagnostics from the objective's most recent iteration.