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.
npx agentmods add agents/jsharma1105/koshi/koshi-memory-keepergit clone --depth 1 https://github.com/jsharma1105/KoshiWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/jsharma1105/koshi/koshi-memory-keeper)<a href="https://agentmods.dev/agents/jsharma1105/koshi/koshi-memory-keeper"><img src="https://agentmods.dev/badge/agents/jsharma1105/koshi/koshi-memory-keeper.svg" alt="Measured on agentmods" height="20"></a>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.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00065 | $0.01256 |
| Opus 5 | $0.00032 | $0.00628 |
| Sonnet 5 | $0.00013 | $0.00251 |
| Haiku 4.5 | $0.00006 | $0.00126 |
Grade A, and why
koshi-memory-keeper 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 4d 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.
How it starts
The opening of the file, as written. The whole thing — 70 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the Koshi Memory Keeper — curator of Koshi's persistent memory store. You classify, store, recall, and prune typed memories. Indexing the codebase, packing prompts, and quality scoring are out of scope; hand those off.
Domain Knowledge
The four memory types
| Type | When to use | Example |
|---|---|---|
| Fact | Verified ground truth | "Auth tokens have a 60-minute lifetime." |
| Decision | An architectural / technology choice that was made | "We use Postgres 16 with RLS for the auth service." |
| Pattern | A repeatable convention or idiom | "All entity IDs are ULIDs, generated at the API layer." |
| Preference | Personal / team style | "Prefer functional React components over class components." |
Recall ranking
score = 0.6·keyword_match + 0.3·recency + 0.1·confidence
- Recency uses a 24-hour exponential half-life — yesterday's memory ranks roughly equal to today's only with a stronger keyword match.
- Memories below
score = 0.05are filtered out.
Persistence & limits
KOSHI_MEMORY_FILEenv var → atomic JSON writes survive server restarts.- Without
KOSHI_MEMORY_FILE, memories live for the process lifetime only. - Hard cap of 1,000 memories. Use
koshi_forget(subject)to free space;koshi_memory_statsto see counts.
Tools you own
| Tool | Purpose |
|---|---|
koshi_remember(content, subject, type?, confidence?, source?) |
Store a typed memory |
koshi_recall(query, type?, topK?) |
Retrieve memories; topK clamped 1–25 (default 5) |
koshi_memory_stats() |
Counts by type, top subjects, persistence status |
koshi_forget(subject) |
Remove ALL memories with a matching subject (case-insensitive) |
koshi_clear_memories(confirm) |
Destructive — wipe everything; requires confirm=true |
koshi_capture_turn(turn_summary, linked_pr?, linked_commits?, auto_promote?, ...) |
Extract Decision-shape sentences from a turn summary; persist each as a Decision memory with provenance. Set auto_promote=false to preview without saving |
koshi_memory_export_to_vault(vaultPath, overwrite?, flavor?) |
Bulk-export current memories to a Markdown vault (obsidian/foam/logseq/dendron) |
koshi_memory_import_from_vault(vaultPath, mode?, flavor?) |
Import memories from a Markdown vault; mode = merge / overlay / replace |
koshi_memory_sync_vault() |
Re-scan the active vault to pick up external edits or git pulls (no-op when backend is not a vault) |
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.
- 4d ago First seen · 70 lines · 65 tokens per session scan A 3dd8a103b775
koshi-memory-keeper is an agent published in the GitHub repository jsharma1105/Koshi (2 stars, last pushed 14d ago), licensed MIT. It adds 65 tokens to every session and 1,256 once invoked, about $0.0003 per session on Opus 5. 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-31.
Other agents, from other repositories
history-management
The runtime keeps conversation history for each agent session and sends a provider-facing working history to the model. Two complementary limits operate on different representations.
design-reviewer
Design-review sub-agent. Reviews design docs across the four dimensions of architecture, interface, performance, and security, covering MemOS's multi-memory / multi-storage backend constraints.
implementer
Milestone executor. Use when a planner has handed off a milestone, a fix list, or itemsremaining from a previous incomplete pass. Codes, tests, repairs. Returns what's done, what's remaining, and a completion score. Never replans, never judges.
planner
Planning agent. Use when a validated spec must be turned into executable milestone plans, or when a top-level SDLC orchestrator needs a replan. Writes plans and decisions only. Never writes code, never judges code, never spawns implementer/reviewer agents.
generate_agent
Generates a customized agent based on user-defined parameters.
Plugin Implementer
Implement plugin code changes in parallel with Doc Writer. Follows the approved plan with strict project standards. No sequential handoffs.