background-work

A set of rules for changing long-running background tasks such as file watchers, polling, and data synchronisation, with a focus on memory use.

In plain words
What is it for?
Use it when modifying watchers, polling, synchronisation schedules, or other always-running processes, and when investigating memory growth or testing performance with small and large archives.
Why use it?
It helps prevent background work from slowing down or consuming steadily increasing amounts of memory. It also avoids repeating work across an entire archive when only a small batch changed.

Agent

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add agents/kenn-io/agentsview/background-work
Clone the repo
git clone --depth 1 https://github.com/kenn-io/agentsview
Per session 0 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 762 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00000 $0.00762
Opus 5 $0.00000 $0.00381
Sonnet 5 $0.00000 $0.00152
Haiku 4.5 $0.00000 $0.00076

Measured 2d ago against content hash d1679d38e0ba, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

background-work scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

docs/agents/background-work.md · 61 lines

How it starts

The opening of the file, as written. The whole thing — 61 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Background Work and Memory

Read this file before changing watchers, polling, sync scheduling, or other long-running background work. Also read it before investigating memory growth.

  • Keep passive daemon memory within a few hundred megabytes on macOS, Linux, and Windows. Treat sustained growth beyond that range as a regression.
  • Bound watcher, polling, and sync work by the changed batch, not the full archive. Do not scan or load every stored session for each filesystem event.
  • Declare costly scheduling inputs as provider capabilities. Compute them only for providers that use them, and default new capabilities to unsupported.
  • Add cardinality-scaling regressions for background paths. Compare small and large archives and prove that unchanged work per event stays bounded. Cover deletion, tombstones, and persistent archives in the same tests.
  • Diagnose long-running memory with allocation and CPU profiles, live heap, forced-GC heap, and operating-system physical or dirty memory. Raw RSS does not prove live memory because it includes clean reclaimable mappings.
  • Profile branch binaries only against isolated, production-scale database and source clones. Never use live archives or agent transcripts.
  • Observe retention long enough to reproduce the reported growth window. On macOS, record vmmap physical footprint and dirty memory. Use portable Go allocation and heap metrics on Linux and Windows.

Usage cache backfill

  • Start usage-cache backfill only after the writable archive transaction that changed a session has committed. Mutation hooks enqueue session IDs; they never fill while holding the archive writer.
  • Foreground fills are per-session single-flight and detached from request cancellation. Cancelling one waiter must not cancel shared progress.
  • Detached fills and rollup builds hold their own cache-generation lease. Retirement cancels their coordinator context and waits for those leases before closing SQLite handles.
  • A writable daemon runs one newest-usage-first coverage pass after HTTP readiness. It installs at most 256 sessions per cache transaction and yields between batches. The pass fills normalized facts and daily rollups for the process-local timezone plus up to eight retained recently requested explicit timezones. Installed source and aggregate fingerprints, not a progress cursor, are the authoritative coverage records.
  • If a source fingerprint changes during a pass, recapture and restart the snapshot pass at most three times. Already installed current fingerprints make stable batches reusable; never pair facts from the newer source with rollup metadata from the older snapshot.
  • Sweep the archive deletion journal before and after the pass and between install batches. Queries also inner-join current archive sessions before ranking, so tombstone processing is hygiene rather than a correctness dependency.
  • Run incremental vacuum between batches only when the cache freelist exceeds 4,096 pages, and reclaim at most 256 pages per call.
  • Run PRAGMA optimize between substantial batches and after install-heavy foreground fills. Run full ANALYZE after generation creation and complete initial backfill, not after every batch.
  • Backfill logs aggregate counts and elapsed time only. Do not log session IDs, projects, paths, prompts, or fact contents.
  • Keep newest-first fact plus process-local-rollup coverage within 30 seconds and complete fact plus process-local-rollup archive coverage within five minutes on the protected production-scale benchmark clone. These are release gates, not reasons to delay daemon readiness. A foreground request for an unbuilt timezone or all-history coverage remains exact and may pay the remaining fill facts -> build rollups -> read cold cost.

Read the full file on GitHub · 61 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 61 lines · 0 tokens per session scan A d1679d38e0ba

Subscribe to this mod's changes

background-work is an agent published in the GitHub repository kenn-io/agentsview (5,707 stars, last pushed today), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 762 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.