Idea: a conversation stats/header slot so plugins can render cost or context badges

[ClawsJoy]

We shipped a server-side cost service as a plugin (ctx.tokenCost, configurable pricing, 1/10000 ¥ integer units) and wanted to render it next to the conversation stats line. There is no contribution point for that surface today.

What we checked (0.1.5-rc.2) — the client slot registry is a declaration-merged, closed set. Keys we found: the frame seats (root, sidebar, main (keyed, conversation reserved), rightbar, details, shell.overlay) plus package-owned seats (settings.models.provider-card, settings.plugin.item, conversation.trajectory.images). The stats line is rendered by ui-conversation itself, and the frame seats are single and already occupied — an add-on cannot contribute there without replacing a whole column.

Ask: one additive seat on the conversation surface — e.g. conversation.stats.extras or conversation.header.extras — session-bound, so a client plugin can render cost/token/context badges without forking ui-conversation.

If an existing seat is already meant for this and we misread the contract, we would be glad to be corrected.

[argszero]

You misread the contract — the seat you are asking for already exists, and it was already in the version you tested (0.1.5-rc.2).

The seat: conversation.session.header.utilities

Declared by client-ui-conversation in packages/client/ui-conversation/src/client/contract/slots.ts:

/** Right-aligned Session utilities in ascending order. */
'conversation.session.header.utilities': {
  kind: 'list'
  scope: 'session'
  owner: ConversationHeaderActionOwnerProps
}

kind: 'list' + scope: 'session' + replaceRisk: 'none' is exactly the additive, session-bound shape you asked for — it is not one of the frame seats, it does not replace a column, and it takes any number of entries. It is the conversation.header.extras spelling of your ask.

It predates your version

The declaration landed in 8940282aee (2026-08-12); tag dsh-v0.1.5-rc.2 is 2026-09-10, so the commit is an ancestor of the release you tested. The generated runtime catalog shipped in that tag lists it too: packages/extensions/cordis-client-runner/src/client/slot-catalog.ts, key: 'conversation.session.header.utilities' (one of 61 seats in that tag; 70 on master).

Two shipped occupants already prove it is additive

Neither forked ui-conversation:

• @deepseek-ai/dsh-session-log-export — packages/session-query/session-log-export/src/client/index.ts, the export/download action
• @deepseek-ai/dsh-client-ui-open-in-app — packages/client/ui-open-in-app/src/client/index.ts

Registration shape

This is the catalog entry's own example, verbatim:

return {
  inject: ['slots'],
  apply(ctx) {
    ctx.slots.inject('conversation.session.header.utilities', () => ctx.slots.register(
      { name: 'conversation.session.header.utilities', id: 'my-entry', order: 100, label: 'My entry' },
      () => React.createElement('div', null, 'hello'),
    ))
  },
}

The seat's owner props are deliberately empty — ConversationHeaderActionOwnerProps is documented as "entries receive no owner-specific values". Occupants derive state from the standard Session source instead, which is also how a plugin injects its own store: session-log-export passes inject: () => ({ hooks: {...}, request, dismiss }) in its register options.

How to find these without reading the source

There is a self-service path, and it is the same data the generated catalog carries: cordis_inspect_query with platform: 'client'. Provider Slots, method listSubTree, optional root. Run against the live app it returns the compact Slot and Factory trees, and for each seat the purpose, kind, scope, replaceRisk, the accepted registration options and keyDomain — plus the live occupants of any seat you name. One call would have answered this:

cordis_inspect_query { platform: "client", provider: "Slots", method: "listSubTree",
                       args: { root: "conversation.session.header.utilities" } }

The part of your reading that is right

The seat is in the Session header, right-aligned beside the header actions. If what you need is literally inside the stats line rendered by the conversation body, there is no seat there, and that half of your report stands. Its siblings on the same surface are conversation.session.header.actions (title-adjacent, also list/session) and conversation.session.header.corner (single, session-bound, far-right, past the utilities' edge).

For the client half of your cost badge

@deepseek-ai/dsh-token-meter/client exports deriveTurnTokenUsage(events, turn) — exact provider-reported per-attempt accounting (uncached input, output, total, and the cache/reasoning buckets when every attempt reported them, with provider/model routes). It is on the client-bundle inline-safe list, so a browser bundle may fold usage locally; your ctx.tokenCost service can supply the pricing on top, so the badge does not need a new server round-trip.

[argszero]

Follow-up: the seat is not just declared — here is an out-of-tree plugin using it

Rather than argue from the catalog, I built the badge you asked for as a third-party plugin and published it. If you want the feature today, it exists; if you want to write your own, this is the smallest complete example I could reduce it to.

• npm: @argszero/cordis-plugin-session-usage-badge (0.1.0)
• source: https://github.com/argszero/cordis-plugin-session-usage-badge

What it contributes. One cell in conversation.session.header.utilities, rendering two readings — both taken from client projections through the Session standard kit's keyed useProjection hook, so there is no route, no config and no ctx.remote traffic:

• occupancy — contextPressure.projectedTokens ?? pressureTokens over contextWindow, as a percentage. This is the reading that moves the tone (outline → warning at 80% → danger at 95%), because it is the only one with an actionable threshold.
• billed ledger — tokenUsage totals (uncached input plus both cache buckets), with the cache-hit share over the prompt side on a second line.

The whole contribution:

ctx.slots.inject('conversation.session.header.utilities', () => ctx.slots.register({
  name: 'conversation.session.header.utilities',
  id: 'session-usage-badge',
  order: 20,
  locale: NS,
}, UsageBadge))

plus one row to mount it:

- insert:
    - id: session-usage-badge
      name: '@argszero/cordis-plugin-session-usage-badge'

Why the package looks lopsided. Its node half is empty on purpose: the browser half reaches the page because the manifest declares dsh.client, and @deepseek-ai/dsh-client-modules scans the host Loader's entries for that declaration — mounting the row is the client wiring. There is nothing else to install.

Two things worth knowing before writing your own, both of which cost me time:

1. The client half is bundled by your package, not by the harness. The contract is a closure factory: the bundle must call window.__ModuleLoader__.load({ id, factory }) exactly once, and every client package it imports has to survive as a require — an inlined React is the failure mode that looks like success.
2. Read the seat's live occupants before choosing an id. cordis_inspect_query{ platform: 'client', provider: 'Slots', method: 'listSubTree', args: { root: 'conversation.session.header.utilities' } } returns each occupant with its registration and keyDomain, which is how you can tell the id you are about to take is free.

What I verified, and what I did not. 32 tests: the readings module is pure and total (it returns null rather than guessing when the harness has reported nothing), the bundle spec asserts the single handoff and that every requested external survives as a require, and a packaging spec asserts the built lib/** declares exactly the runtime dependencies it imports. Peer range is pinned to @deepseek-ai/cordis@^4.0.2, with the client packages developed against 0.1.6-alpha.2. What I have not done is watch it render in a live Web session on this machine — so you are the natural end-to-end witness. If the badge appears but a reading looks wrong, the readings module is pure and takes two plain objects, which makes a specific number easy to point at.

This is also the copyable skeleton #5899 was asking for, so if it helps as a starting point for further browser-half plugins, take it apart.