🔴 Required Information
Is your feature request related to a specific problem?
EventsCompactionConfig has two independent compaction triggers:
- token-threshold:
token_threshold + event_retention_size (both Optional, must be set together)
- sliding-window:
compaction_interval + overlap_size (both required int)
Because the sliding-window fields are required, there is no clean way to enable only the token-threshold trigger and turn the sliding-window trigger off. Today I have to set compaction_interval to a large sentinel value (e.g. 1_000_000) so the guard len(new_invocation_ids) < compaction_interval never fires — a hack that hides intent and is easy to get wrong (0 does the opposite: fire every invocation).
For a cost-driven use case, the token-threshold trigger is precisely coupled to the signal we care about (prompt size), whereas the invocation-count-based sliding-window trigger fires regardless of token size and can summarize unnecessarily. So being able to enable just one trigger is genuinely useful.
Describe the Solution You'd Like
Make compaction_interval + overlap_size an optional pair, mirroring the existing token_threshold + event_retention_size pair:
compaction_interval: Optional[int] = Field(default=None, gt=0)
overlap_size: Optional[int] = Field(default=None, ge=0)
- A
model_validator requiring the two to be set together (or both None), matching _validate_token_params.
- Require that at least one trigger (token-threshold pair OR sliding-window pair) is configured.
This lets users opt into a single trigger system without a sentinel value:
# token-threshold only
EventsCompactionConfig(
summarizer=...,
token_threshold=160_000,
event_retention_size=50,
) # no compaction_interval / overlap_size needed
This is a public-API change, so raising it here for direction before opening a PR. (A separate, smaller bug report covers adding gt=0 / ge=0 validation to the currently-required fields.)
Impact on your work
We run an ADK-based gateway where a few long tool-heavy sessions drive the vast majority of Gemini input-token cost. We want token-threshold compaction only. Today we must pass a 1_000_000 sentinel to disable the sliding-window trigger, which is unclear to readers and a foot-gun (0 silently means "every invocation"). An optional pair would make the intended configuration self-documenting and safe. Not time-critical, but it would simplify our config and likely help others with cost-oriented setups.
🔴 Required Information
Is your feature request related to a specific problem?
EventsCompactionConfighas two independent compaction triggers:token_threshold+event_retention_size(bothOptional, must be set together)compaction_interval+overlap_size(both requiredint)Because the sliding-window fields are required, there is no clean way to enable only the token-threshold trigger and turn the sliding-window trigger off. Today I have to set
compaction_intervalto a large sentinel value (e.g.1_000_000) so the guardlen(new_invocation_ids) < compaction_intervalnever fires — a hack that hides intent and is easy to get wrong (0does the opposite: fire every invocation).For a cost-driven use case, the token-threshold trigger is precisely coupled to the signal we care about (prompt size), whereas the invocation-count-based sliding-window trigger fires regardless of token size and can summarize unnecessarily. So being able to enable just one trigger is genuinely useful.
Describe the Solution You'd Like
Make
compaction_interval+overlap_sizean optional pair, mirroring the existingtoken_threshold+event_retention_sizepair:compaction_interval: Optional[int] = Field(default=None, gt=0)overlap_size: Optional[int] = Field(default=None, ge=0)model_validatorrequiring the two to be set together (or bothNone), matching_validate_token_params.This lets users opt into a single trigger system without a sentinel value:
This is a public-API change, so raising it here for direction before opening a PR. (A separate, smaller bug report covers adding
gt=0/ge=0validation to the currently-required fields.)Impact on your work
We run an ADK-based gateway where a few long tool-heavy sessions drive the vast majority of Gemini input-token cost. We want token-threshold compaction only. Today we must pass a
1_000_000sentinel to disable the sliding-window trigger, which is unclear to readers and a foot-gun (0silently means "every invocation"). An optional pair would make the intended configuration self-documenting and safe. Not time-critical, but it would simplify our config and likely help others with cost-oriented setups.