Add reflection budget and cron guardrails

[dplush]

Problem

Automatic reflection / consolidation can be useful in interactive sessions, but it is risky for scheduled jobs and other high-frequency automation.

Cron-style workflows often produce repetitive, low-value context: daily briefs, watchdog output, status pings, market scans, etc. If those runs trigger expensive reflection calls or write noisy memories, users pay extra and the memory store slowly drifts toward summaries of routine automation.

Proposal

Add an explicit reflection budget / guardrail layer.

Example config:

reflect:
  max_calls_per_session: 3
  max_calls_per_day: 20
  disabled_for_cron: true
  min_turns_before_reflect: 5
  cost_budget_usd: 0.05

Or under the Hermes integration namespace if that is a better fit:

memory:
  mnemosyne:
    reflect:
      disabled_for_cron: true
      max_calls_per_session: 3

When reflection is skipped, return a structured reason instead of silently doing nothing:

{
  "status": "skipped",
  "reason": "reflect_disabled_for_cron"
}

Other useful skip reasons:

• reflect_budget_exhausted
• min_turns_not_reached
• low_value_automation_context
• cost_budget_exhausted

Why this helps

This keeps memory useful and predictable. Interactive sessions can still benefit from reflection, while cron/watchdog/briefing jobs stay cheap and do not flood memory with routine output.

It also gives operators a clear knob for production setups: memory quality first, cost second, no surprise background reflection.

[AxDSan]

@dplush great timing on this one. Your 6th batch item landed while the brief was building and it fits right into the triage flow.

This is a well-scoped proposal. The key insight is right: cron jobs producing repetitive noise memories is a real drift risk, and wrapping reflection behind a budget guardrail keeps interactive sessions flexible while protecting automation paths.

A few thoughts on the design:

disabled_for_cron: true — this is the highest-value knob. Most of the pain comes from scheduled jobs, not interactive sessions. I would make this the default.

Structured skip reasons — yes, absolutely. Silent skips are worse than no skips because you dont know whether the system is broken or just throttled. The structured JSON response is the right pattern.

Cost budget — I would hold this for v2. Its the hardest to implement well (token counting is fuzzy, different providers price differently) and it adds complexity without the immediate payoff of disabled_for_cron and max_calls_per_session.

I want to champion this. Would you be up for opening a PR that implements disabled_for_cron, max_calls_per_session, and the structured skip response? Happy to review same-day.

Also want to flag this ties into the broader reflection hardening Im doing in #330 (sleep model refresh). The two efforts should converge on the same budget/guardrail interface.