You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Automatic usage limit warning and handoff suggestion within Composer.
#21253
Many users have a few lower-tier subscriptions, and run into usage limits. It is frustrating when we accidentally hit a usage limit, when we could have instead used the remaining quota to generate a handoff instead. Work gets stalled, even though other subscriptions could have taken over.
When the usage limit is known, and current context is also known, it should be possible to generate a crude estimate of the minimum token cost of the next message. For example, the current size of the context window is a known lower limit for the next message. The actual costs of the last message could be used as an estimate (since cache reads/writes affect the actual usage "cost"), or a multiplication factor could be applied to the current size of the context window, tuned to feel "right". A few options for implementation exist; for example, interrupt when the user hits send, or simply display a short message over the composer box as they type.
Even better would be an option to automatically generate the handoff AND create a new thread with a different provider/provider instance, so that work continues uninterrupted.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Many users have a few lower-tier subscriptions, and run into usage limits. It is frustrating when we accidentally hit a usage limit, when we could have instead used the remaining quota to generate a handoff instead. Work gets stalled, even though other subscriptions could have taken over.
When the usage limit is known, and current context is also known, it should be possible to generate a crude estimate of the minimum token cost of the next message. For example, the current size of the context window is a known lower limit for the next message. The actual costs of the last message could be used as an estimate (since cache reads/writes affect the actual usage "cost"), or a multiplication factor could be applied to the current size of the context window, tuned to feel "right". A few options for implementation exist; for example, interrupt when the user hits send, or simply display a short message over the composer box as they type.
Even better would be an option to automatically generate the handoff AND create a new thread with a different provider/provider instance, so that work continues uninterrupted.
All reactions