context: usage typed as LanguageModelUsage forces callers to supply nested token detail the element never reads

Summary

ContextSchema.usage is typed LanguageModelUsage from the ai package:

interface ContextSchema {
  usedTokens: number;
  maxTokens: number;
  usage?: LanguageModelUsage;
  modelId?: ModelId;
}

The element only reads flat, optional-guarded counts — input, output, total, reasoning, cached input. But LanguageModelUsage nests reasoning/cache counts under inputTokenDetails / outputTokenDetails, and that shape has changed across ai majors.

The practical effect: a caller holding flat token counts (from server turn metadata, a persisted record, or a provider whose usage doesn't map 1:1) can't satisfy the type without inventing nested fields the component never touches — and gets churn whenever the SDK reshapes them.

Suggestion

Decouple the prop from the SDK type, since the element's actual requirement is much smaller:

export type ContextUsage = {
  inputTokens?: number;
  outputTokens?: number;
  totalTokens?: number;
  reasoningTokens?: number;
  cachedInputTokens?: number;
};

LanguageModelUsage remains structurally assignable for the flat fields, so existing callers passing it keep working.

Context

Raising as an issue, not a PR — this changes a public type and there may be a reason to stay pinned to the SDK shape. We carry it as a downstream override today and would prefer to drop it. Happy to send a patch if you like the direction.

Start at the ContextSchema usage prop definition and inspect the component's flat, optional-guarded usage reads. Check existing type checks or tests for callers passing LanguageModelUsage, then define the smaller public usage shape and verify both flat token-count callers and existing SDK-shaped callers remain accepted.