Track SelectorGroupChat token usage with new Message type #4771
+41
−4
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The below changes are not meant to be merged but rather are here to open a discussion about how to correctly track the token usage for the calls that occur internally in some agents/teams such as the SelectorGroupChat.
The problem is how do we pass a message from
SelectorGroupChat.select_speaker()
to somewhere where we are tracking the token usage (specifically we want to also track the tokens used insideselect_speaker
)? I thought about publishing to theoutput_topic
a new type of Message, one that tracks only Token Usage, however, in the future it could track other things that are not meant to be consumed by the agents.To consider
Some tests are failing!
SelectorGroupChat
are failing becauseSelectorGroupChat.run(...)
is generating more messages than expected, that's becauseBaseGroupChat
is additionally yielding the newUsageEvent
messages. We need to yield them for Console to receive them and account themBaseGroupChat
only yields messages that are notUsageEvent
, note that these messages would still be considering when computing the token usage that gets return with theTaskResult
.Console
would no longer be receivingUsageEvent
needed for its internal token_usage track.Why are these changes needed?
Related issue number
#4719
Checks