Let a custom ACP agent declare that it reports usage - #3896
Merged
Merged
Conversation
A shipped agent opts into the usage surface with `providerUsage`, but the custom-agent schema is strict and has no such field, so an agent configured through `customAgents` can never appear there — even when it runs the very CLI a shipped agent runs and the bridge already knows how to read its usage. That is the common shape for a custom entry: the same agent launched differently. Ours runs Cursor with an explicit `--agent-endpoint` so its traffic goes through a credential hub rather than straight to the vendor; it is `dialect: "cursor"` in every other respect, including the usage the bridge can fetch for it. Today that card is simply blank, with no way to say otherwise. Adds the field and passes it through to the definition. Default is unchanged: an entry that does not ask for it stays off the usage surface. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
|
Thanks @OXI-717 for the PR. This repo needs approval before a PR. Join the #contributors channel in Discord (https://discord.gg/kvBU6tJhcJ) and explain what you want to open a PR for and why. A maintainer then adds you to the allow list. This PR now closes on its own. Reopen it or open a new one after approval. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Root cause
A shipped ACP agent opts into the usage surface with
providerUsage, whichacpProviderDeclarationturns intomaintenance.usage. The custom-agent schema(
customAcpAgentSchema) is.strict()and has no such field, andcustomAcpAgentDefinitionnever sets one — so an agent configured through thecustomAgentssetting can never appear in Provider Usage, even when it runs the same CLIa shipped agent runs and the bridge already knows how to read usage for its dialect.
That is the common shape of a custom entry: the same agent, launched differently. Mine
runs Cursor with an explicit
--agent-endpointso its traffic goes through a credentialbroker instead of straight to the vendor; it is
dialect: "cursor"in every otherrespect, including the usage the bridge can fetch. The card is simply blank today, with
no way to say otherwise.
Change
providerUsage?: booleanoncustomAcpAgentSchema, passed through incustomAcpAgentDefinition.surface, so nothing new shows up for existing configurations.
Verification
pnpm exec turbo run typecheck test --filter=bb-plugin-provider-acp→ 9 files, 17 testspassing, including two added cases: an entry asking for the capability declares
maintenance.usage === true, and one that does not staysfalse. Removing thepass-through line turns the first red (
expected undefined to be true), so the test pinsthe behaviour rather than the shape.