Get API-Information on usage etc

From my understanding you currently only get the answer and a success flag back.
For me it would be quite interesting to also get information on tokens used etc (which OpenAI provides for example).
Is there a way to get that information out or does this need modification in the code? Would be happy to support, just need a little guidance on where to start.

This is the information on usage you get back when using the openAI-API

"usage":{
      "prompt_tokens":13,
      "completion_tokens":7,
      "total_tokens":20
   },

/typechat draft

/typechat reply

The built-in TypeScript clients do not currently expose the provider's usage metadata, such as input and output token counts. In typescript/src/model.ts they extract only the generated text, and typescript/src/typechat.ts then returns the validated application object. Adding a usage field only to the model response would therefore not make it appear in the translation result.

You can collect usage without changing TypeChat's core by supplying your own TypeChatLanguageModel, the interface for a model client, to createJsonTranslator. Its complete method can capture usage from the service response separately while returning the expected success-or-error text result. Simply wrapping the built-in complete method cannot recover metadata it has already discarded.

Your earlier pull request already explored forwarding this information and displaying token counts in the sentiment example. Thank you for that contribution. It was closed as stale without merging, so it remains useful prior work rather than an available feature.

Would collecting usage separately in your application meet your need, or do you need usage returned alongside translate results? If you need built-in support, should usage be reported per service request or as a total for the translation, including the extra request TypeChat can make to repair output that fails validation?

Related contributions: #80.

Automated response requested by the project owner. This does not accept work or authorize implementation.

I like being able to get this information. It probably shouldn't be part of the payload in terms of the returned object the LLM crafted but part of the response (i.e. it's there if you want to get at it). Additionally there's other meta information as well that users might want/need like content filtering, etc.

/typechat draft

TypeChat: Draft prepared; owner or maintainer input is still needed before work acceptance.

Owner request | Run and preview

Operational receipt only. This comment does not publish draft text, accept work, authorize implementation, or approve merging.

Owner guidance for the next proposal (not work acceptance):

For the initial TypeScript change:

Keep provider-supplied metadata alongside the response, outside the LLM-generated and validated application payload.
Expose per-provider-response details and translation-wide totals of reported token usage, including the initial response and any repair responses. Do not invent missing token counts or treat unavailable metadata as known zero usage.
Retain available usage and metadata when translation fails. Preserve validation, repair behavior, and the existing success/failure distinction.
Include token usage and available content-filtering metadata from the existing OpenAI/Azure client paths. Keep the core provider-neutral, with optional provider-returned filtering details rather than new moderation calls or raw response bodies.
Keep existing custom models and providers that return no metadata compatible. Use offline mocked tests, including repair and failure cases, and document the supported metadata and accounting semantics.

Please inspect the current model client, translator, and result interfaces when proposing the API and forwarding behavior. Preserve credit for the closed, unmerged prior work in #80.

These are requirements for a fresh proposal. This comment does not accept implementation work, authorize a build or merge, or close the issue.

/typechat draft

TypeChat: Draft and work-acceptance preview prepared for owner review.

Owner request | Run and preview

Operational receipt only. This comment does not publish draft text, accept work, authorize implementation, or approve merging.

/typechat accept 13194056713:18aab024f7626b0864bff03ea1165cfe650dac80991cad13141ac194195552d3

Accepted work

Approved by the project owner, robgruen, for issue #75.

Goal

Let TypeScript applications inspect service-reported token usage and available content-filtering information alongside TypeChat responses, including reported totals across repair and retained information on failure, without changing validated application data or requiring a particular provider.

Scope

Add optional provider-neutral metadata to TypeScript model and translation response envelopes on both success and failure, preserving existing text and application data types.
Extract supported usage and available filtering details from the existing OpenAI Chat Completions, OpenAI Responses, and Azure OpenAI client paths.
Retain each provider response's available metadata and aggregate reported token counts across initial and repair responses, preserving missing and partial reporting distinctions.
Add deterministic offline mocked regression coverage and TypeScript documentation, preserving credit for intuity-hans and the closed, unmerged work in PR 80.

Non-goals

Do not add metadata to model-generated or validated application data, weaken validation, or change repair limits and existing failure semantics.
Do not add providers, vendor-bound core types, new moderation calls, or complete raw provider-response bodies to metadata.
Do not estimate missing token counts, calculate prices, or claim reported-only totals account for usage the service did not report.
Do not change Python APIs or perform unrelated refactoring.

Acceptance criteria

Public TypeScript model and translation results expose optional provider-neutral metadata on both success and failure. Successful model data remains text, successful translation data remains the validated application object, and metadata is never inserted into that object or its schema.
Mocked responses from the existing OpenAI Chat Completions, OpenAI Responses, and Azure OpenAI client paths expose their supported reported usage and available filtering details through the optional metadata. Missing filtering details remain optional. Metadata does not contain complete provider response bodies, and extraction makes no additional service or moderation requests.
For an initial response reporting input 13, output 7, and total 20 tokens, followed by a repair reporting input 5, output 3, and total 8, translation exposes two ordered response records and reported totals of input 18, output 10, and total 28. Each response contributes exactly once, and separate translations do not share accumulated metadata.
Fixtures distinguish unavailable counts from reported zero counts. Mixed reported and absent usage produces reported-only totals with partial reporting distinguishable from complete reporting. An aggregate with no reported count remains absent, and missing total counts are not inferred from other fields.
Failure fixtures cover non-JSON text, JSON parse errors, schema and custom validation rejection, content-filtered responses, initial model failure, and failed repair. Each final failure retains all available metadata and reported usage while preserving existing message, rejected data, and responseText behavior. A later model failure does not erase metadata from an earlier response.
Existing validation and additional instance validation still determine success. Disabling repair makes one model call, the default permits at most one repair call, and getData still returns application data on success and throws on failure. Metadata never converts a rejected or filtered result into success.
A custom model whose complete method returns the existing promise of a text result without metadata still type-checks and translates valid output unchanged. Providers with no usage or filtering metadata remain usable without fabricated fields or a provider-specific dependency in the core result types.
Deterministic offline mocked tests cover the supported client formats, full and partial usage, absent metadata, reported zeros, successful repair, final failures, compatibility, and isolation between translations. The tests require no credentials or live provider access.
TypeScript documentation shows optional metadata on success and failure, lists supported token mappings and filtering fields for each existing API format, and explains per-response records, repair totals, partial reporting, and unreported usage. It credits intuity-hans for PR 80 without presenting that unmerged work as an available feature.

Existing contributions

#80 at 4f3e378

Proposal run | Approved scope policy

This accepts the scope above. It does not start or authorize an automated implementation run, increase any budget, or approve merging. Material scope changes require a new proposal and owner decision.

/typechat build 6592736337:18aab024f7626b0864bff03ea1165cfe650dac80991cad13141ac194195552d3

Implement accepted Issue #75 (#513)

Implemented in #513

docs: record verified automation pilot milestones (#514)

Navigation Menu

Repository navigation

Get API-Information on usage etc #75

Accepted work

Goal

Scope

Non-goals

Acceptance criteria

Existing contributions

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Get API-Information on usage etc #75

Description

Activity

robgruen commented on Oct 30, 2026

robgruen commented on Oct 30, 2026

robgruen commented on Oct 31, 2026

github-actions commented on Oct 31, 2026

robgruen commented on Nov 1, 2026

robgruen commented on Nov 2, 2026

github-actions commented on Nov 2, 2026

robgruen commented on Nov 3, 2026

robgruen commented on Nov 3, 2026

github-actions commented on Nov 3, 2026

robgruen commented on Nov 3, 2026

github-actions commented on Nov 3, 2026

Accepted work

Goal

Scope

Non-goals

Acceptance criteria

Existing contributions

robgruen commented on Nov 3, 2026

robgruen commented on Nov 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions