最近发现上下文差距太大了能否显示更清楚上下文由哪些模块组成？

[Nicolas-One]

这个差距太大了，我都不知道到底因为啥上下文爆炸了，我希望能显示的更清楚，不然我就得去让他去扫dsh然后才能知道怎么回事儿。

[argszero]

This already exists — but it answers a coarser question than the one you are asking

Assuming the numbers in your screenshot are the composer's context meter: the breakdown you want is already there. The ring is a button — click it and a panel opens showing the heuristic composition as three rows plus a stacked bar.

• packages/client/ui-conversation/src/client/skeleton/ContextMeter.tsx — the ring and panel.
• Rows: context.system (system prompt), context.tools (tool schemas), context.messages (everything else), each rendered ~<tokens> from the contextBreakdown projection.

If you had not found it: the trigger is a 14px ring in the composer, and the whole meter renders nothing until the provider has reported both a pressure figure and a route capacity (contextOccupancy returns null otherwise, and the component returns null for a null occupancy — context-occupancy.ts:18-24, ContextMeter.tsx:85). On a route that advertises no capacity there is no meter at all, which is easy to read as "the feature does not exist".

Why the numbers do not add up — that part is documented, not a bug

The "差距" you are seeing is deliberate and is written down in the projection's own docstring (packages/llm/token-meter/src/projection.ts:49-57):

Heuristic composition of the next request's context: what the prompt is made of, not what it costs. All three figures use the meter's fixed density estimate, so they will not sum to the provider-anchored projectedTokens: the estimator systematically underprices CJK text and JSON schemas, which is exactly the error the anchoring in projectedTokens keeps out of the occupancy figure. Present these as approximations of composition, never as a total.

Concretely, the two sides come from different places:

what you see	source	nature
ring percent / ~used / window	projectedTokens ?? pressureTokens (context-occupancy.ts:18-24)	provider-anchored, what the model actually billed
the three panel rows	contextBreakdown	fixed-density estimate, 4 characters per token (estimate.ts:13)

That is why the rows carry a ~ and why the ring's overall length stays the provider-exact percent while the coloured segments only proportion themselves against the heuristic total (ContextMeter.tsx:97-105). A heavy CJK conversation is exactly the case where the two diverge most — the estimator charges 4 characters per token against text that really costs closer to one character per token, so the rows should be read as proportions of each other, never as a budget.

What is genuinely missing

Granularity, not the feature. ContextBreakdownProjection is three integers by design (projection.ts:59-66): it will tell you that tool schemas are half your context, but not which tool schema, and it will not tell you which of twelve system-prompt sections is carrying the weight. That is the question "why did my context explode" usually means, and the projection cannot answer it — the meter service keeps a running surface total and prices each node only as a delta (breakdown-projection.ts:1-6), so the per-node detail never survives into the published value.

So: if what you need is "which module is eating the window", the panel is the wrong altitude and you will still end up scanning the session. If what you need is "how much is prompt vs tools vs conversation", it is one click away.

[Nicolas-One]

不管在哪儿都有较大的差距。

[Nicolas-One]

zhe'ge这个就就更离谱了，经常这样，上下文爆炸，不知道到底怎么回事儿。偏差几十K没啥，这个600K了，就很离谱。