From 8ea5e393b973a752c9f0e9bf86ed8f6622ddf101 Mon Sep 17 00:00:00 2001 From: Kishore Kumar Date: Fri, 12 Jun 2026 02:53:22 +0530 Subject: [PATCH 1/2] =?UTF-8?q?docs(changelog):=20zombie=20memory-loss=20c?= =?UTF-8?q?ounters=20=E2=80=94=20six=20observability=20families?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Fable 5 --- changelog.mdx | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/changelog.mdx b/changelog.mdx index 95d626e..ce06378 100644 --- a/changelog.mdx +++ b/changelog.mdx @@ -22,6 +22,24 @@ export const STAGE_SELF_MANAGED_M66 = "$0.0001"; usezombie is in **stealth-mode testing** and pre-production. APIs and agent behavior may change between releases without long deprecation windows. Email [usezombie@agentmail.to](mailto:usezombie@agentmail.to) if you want a hand calibrating an agent or to join as a design partner. + + ## Zombie memory loss is now measurable + + A zombie's learned fact could previously vanish — evicted past the per-zombie cap, windowed out of a hydration reply, or skipped during a capture push — with no signal anywhere. Every one of those loss events now increments a Prometheus counter on `GET /metrics`, so a dashboard answers "is my zombie losing memory?" the day it starts instead of three weeks later through a support ticket. + + ## What's new + + Six counter families, all global and label-free (per-zombie inspection stays in logs and the upcoming CLI read verbs, never in metric labels): + + - **`zombie_memory_hydration_dropped_entries_total` / `zombie_memory_hydration_dropped_bytes_total`** — entries and bytes the hydration byte-budget window cut from a reply; the cold tail stays durable in Postgres, these count what a run did not see. + - **`zombie_memory_cap_evictions_total`** — rows deleted by the per-zombie cap after a capture push, counted from the database's own deleted-row report; eviction is never blocked on telemetry. + - **`zombie_memory_capture_truncated_total`** — pushes that hit the push byte budget and stopped early, once per truncated push. + - **`zombie_memory_capture_skipped_total`** — capture deltas rejected by validation (oversized or empty key, content, or category), counted per delta. + - **`zombie_memory_search_zero_hits_total`** — memory searches that matched nothing, the recall-miss signal. A database error mid-read is never counted: only a cleanly empty result moves it, so infrastructure noise cannot impersonate recall loss. + + The three existing memory families keep their names, types, and meaning unchanged. + + ## Billing audit rows now always equal the wallet drain From c0f023e791a8b0435a7c11d49424804428ce19ad Mon Sep 17 00:00:00 2001 From: Kishore Kumar Date: Fri, 12 Jun 2026 03:00:54 +0530 Subject: [PATCH 2/2] docs(changelog): agent, not zombie, as the product noun in prose (greptile P2) AGENTS.md reserves zombie for brand/code tokens; metric names stay verbatim. Co-Authored-By: Claude Fable 5 --- changelog.mdx | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/changelog.mdx b/changelog.mdx index ce06378..f90a492 100644 --- a/changelog.mdx +++ b/changelog.mdx @@ -23,16 +23,16 @@ export const STAGE_SELF_MANAGED_M66 = "$0.0001"; - ## Zombie memory loss is now measurable + ## Agent memory loss is now measurable - A zombie's learned fact could previously vanish — evicted past the per-zombie cap, windowed out of a hydration reply, or skipped during a capture push — with no signal anywhere. Every one of those loss events now increments a Prometheus counter on `GET /metrics`, so a dashboard answers "is my zombie losing memory?" the day it starts instead of three weeks later through a support ticket. + An agent's learned fact could previously vanish — evicted past the per-agent cap, windowed out of a hydration reply, or skipped during a capture push — with no signal anywhere. Every one of those loss events now increments a Prometheus counter on `GET /metrics`, so a dashboard answers "is my agent losing memory?" the day it starts instead of three weeks later through a support ticket. ## What's new - Six counter families, all global and label-free (per-zombie inspection stays in logs and the upcoming CLI read verbs, never in metric labels): + Six counter families, all global and label-free (per-agent inspection stays in logs and the upcoming CLI read verbs, never in metric labels): - **`zombie_memory_hydration_dropped_entries_total` / `zombie_memory_hydration_dropped_bytes_total`** — entries and bytes the hydration byte-budget window cut from a reply; the cold tail stays durable in Postgres, these count what a run did not see. - - **`zombie_memory_cap_evictions_total`** — rows deleted by the per-zombie cap after a capture push, counted from the database's own deleted-row report; eviction is never blocked on telemetry. + - **`zombie_memory_cap_evictions_total`** — rows deleted by the per-agent cap after a capture push, counted from the database's own deleted-row report; eviction is never blocked on telemetry. - **`zombie_memory_capture_truncated_total`** — pushes that hit the push byte budget and stopped early, once per truncated push. - **`zombie_memory_capture_skipped_total`** — capture deltas rejected by validation (oversized or empty key, content, or category), counted per delta. - **`zombie_memory_search_zero_hits_total`** — memory searches that matched nothing, the recall-miss signal. A database error mid-read is never counted: only a cleanly empty result moves it, so infrastructure noise cannot impersonate recall loss.