Skip to content

Conversation

junaidbinfarooq
Copy link
Contributor

@junaidbinfarooq junaidbinfarooq commented Aug 13, 2025

Q A
Bug fix? no
New feature? yes
Docs? yes
Issues #208
License MIT

Changes proposed:

The PR aims to standardize the token usage extraction and its availability in the AI bundle. Essentially, the following is done:

  • Makes token usage explicit by adding a dedicated dto for token information
  • Populates the token usage dto inside different token output processors and then adds it to the metadata object

@carsonbot carsonbot added Feature New feature Platform Issues & PRs about the AI Platform component Status: Needs Review labels Aug 13, 2025
@junaidbinfarooq junaidbinfarooq force-pushed the feat/standardize-token-usage branch 2 times, most recently from 7a34c26 to d771023 Compare August 13, 2025 21:33
@junaidbinfarooq junaidbinfarooq force-pushed the feat/standardize-token-usage branch 2 times, most recently from 75e98c8 to 048ac63 Compare August 13, 2025 21:49
Copy link
Member

@chr-hertel chr-hertel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, but we need to slim this down a bit - in general smaller PRs, that build on top of each other are favorable to me. so let's break it down like you did:

Makes token usage explicit

I like having the value object, we should definitely have that 👍
But I'm not in favor of having the getTokenUsage() directly on the result since the result is a high lever abstraction and token usage is quite specific to remote inference of GenAI models - not all models have that. let's keep it in the metadata please.

Adds support to automatically register token usage extractors so that the token usage information is available in the result when a model is invoked

That's a bit misleading since token usage was already sitting on an extension point => OutputProcessor and your design decision to use that extension point to add another extension point doesn't really resonate with me. why is the new extension point needed? it feels like we're just adding them because we can.

Makes the token usage auto-registration configurable

For me this is too early, i don't think that a use-case, do you? how often do we see the case for someone to bring their own token usage extractor.


all in all, let's start here please with the TokenUsage value object in the metadata class - that's an easy step we see the same picture 👍

edit: another PR could be to fix that issue #208 by registering the corresponding output processor based on the config setting

@junaidbinfarooq
Copy link
Contributor Author

@chr-hertel

Makes token usage explicit
I like having the value object, we should definitely have that 👍
But I'm not in favor of having the getTokenUsage() directly on the result since the result is a high lever abstraction and token usage is quite specific to remote inference of GenAI models - not all models have that. let's keep it in the metadata please.

Hmm, I initially thought about keeping it in metadata, but having it inside the Result object also made sense since an API should send us this information. I, so far, have seen such information in the responses of whatever APIs I tried, but perhaps you are right, and other models out there do not provide such information.

Adds support to automatically register token usage extractors so that the token usage information is available in the result when a model is invoked
That's a bit misleading since token usage was already sitting on an extension point => OutputProcessor and your design decision to use that extension point to add another extension point doesn't really resonate with me. why is the new extension point needed? it feels like we're just adding them because we can.

Nope, the idea, instead, was to introduce an extension point specific to token usage extraction and exposure. This would also simplify for bridges to their own implentations of the extractor interface if needed.

Makes the token usage auto-registration configurable
For me this is too early, i don't think that a use-case, do you? how often do we see the case for someone to bring their own token usage extractor.

So far, in this repository, I have found three such extractors (currently TokenOutputProcessor classes), including the new Google Vertex AI bridge, and all three of them perform the extraction differently, albeit not entirely. As you also rightly pointed out above, token usage is something specific to GenAI models, and not all of them have it. Not all of them will expose the data in a similar fashion, either.

@junaidbinfarooq
Copy link
Contributor Author

@OskarStark @chr-hertel
I have reverted the previous changes and only kept the token usage information. Also, edited the PR description.
Please review the changes.

$processor->processOutput($output);

$metadata = $output->result->getMetadata();
$tokenUsage = $metadata->get('token_usage');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about having a dedicated setTokenUsage/getTokenUsage on the metadata object?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about this.
Metadata object already has a lot of methods, and each of them is generic in nature as far as I can see, and doesn't concern any specific model characteristic.

@junaidbinfarooq junaidbinfarooq force-pushed the feat/standardize-token-usage branch from e33ba4a to 069b4c3 Compare August 15, 2025 18:24
Copy link
Member

@chr-hertel chr-hertel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

almost done i'd say - thanks already!

@junaidbinfarooq
Copy link
Contributor Author

almost done i'd say - thanks already!

I am working on autoconfiguring token usage processors inside the AI bundle and based that branch on this one.
A PR will arrive after this one is finished.

Copy link
Member

@chr-hertel chr-hertel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good to merge from my end - @OskarStark?

@junaidbinfarooq
Copy link
Contributor Author

Good to merge from my end - @OskarStark?

@OskarStark
Could you have a look?

@chr-hertel chr-hertel force-pushed the feat/standardize-token-usage branch from 21976bb to 6e82c23 Compare August 18, 2025 19:40
@chr-hertel
Copy link
Member

Thank you @junaidbinfarooq.

@chr-hertel chr-hertel merged commit 3a160d5 into symfony:main Aug 18, 2025
7 checks passed
@junaidbinfarooq junaidbinfarooq deleted the feat/standardize-token-usage branch August 19, 2025 06:04
chr-hertel added a commit that referenced this pull request Sep 1, 2025
…idbinfarooq)

This PR was merged into the main branch.

Discussion
----------

[AI Bundle] Activate token usage output processors

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| Docs?         | no
| Issues        | Fix #208 Continues #311
| License       | MIT

# Changes proposed:
- Adds support to automatically configure the token usage processors so that they are available to end users (devs) when needed
- Makes the availability of token usage configurable and enabled by default

Commits
-------

b426948 feat(ai-bundle): Auto-configure token usage processors - Adds support to automatically configure the token usage processors so that they are available to end users (devs) when needed - Makes the availability of token usage configurable and disabled by default
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature New feature Platform Issues & PRs about the AI Platform component Status: Reviewed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants