Summary

All cron fires for an agent running in Persistent mode (the default) share a single session keyed as (agent_id, "cron"). This session can grow over time.

Update: cron_session_max_tokens and cron_session_max_messages config fields DO exist (see crates/librefang-types/src/config/types.rs:2685,2692) and are applied as a pruning step before each cron fire (kernel/mod.rs:12094-12124). Both default to None (disabled).

Remaining Gaps

1. No warning when approaching provider context window: There is no tracing::warn! when the cron session grows close to the model's context limit. The first indication of growth is a hard provider error.

2. No API observability: session_token_count is not exposed in the cron job status/history API, so operators cannot observe session growth trends.

3. Documentation gap: cron_session_max_tokens / cron_session_max_messages are undocumented in the dashboard and not surfaced in any config UI. Operators who need per-fire isolation typically have to discover these fields by reading the source.

4. Pruning happens before-fire, not gradually: Pruning drops old messages when the limit is hit, which causes context discontinuity. A warn-and-compact approach (similar to how session compaction works in LLM agent loops) would be more graceful.

Proposed Improvements

1. Emit tracing::warn! when a cron session exceeds a configurable fraction of the provider's context window before triggering the LLM call
2. Expose session_message_count and estimated session_token_count in the cron job status response
3. Document cron_session_max_tokens/cron_session_max_messages prominently in the cron configuration UI and docs
4. Add a gentle summarize-and-trim compaction mode rather than hard truncation