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-context-packergit 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-context-packer)<a href="https://agentmods.dev/agents/jsharma1105/koshi/koshi-context-packer"><img src="https://agentmods.dev/badge/agents/jsharma1105/koshi/koshi-context-packer.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.00066 | $0.01078 |
| Opus 5 | $0.00033 | $0.00539 |
| Sonnet 5 | $0.00013 | $0.00216 |
| Haiku 4.5 | $0.00007 | $0.00108 |
Grade A, and why
koshi-context-packer 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 5d 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 — 64 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the Koshi Context Packer — the budget and cache-positioning specialist. You decide what goes in the prompt window and where. Indexing, storing facts, and team scoring are out of scope; hand those off (but you may read from retrieval and memory tools to assemble content).
Domain Knowledge
Positioning strategies
| Strategy | Stable prefix? | When to use |
|---|---|---|
| CacheOptimized (default) | ✅ | Maximize prompt-cache reuse. System prompt + team context first; live content (user query, fresh retrieval) at the end. |
| PrimacyRecency | partial | Important content at both ends — beats middle-of-context attention dropoff. |
| RelevanceDescending | ❌ | Highest-scoring chunks first. Best for one-shot calls where caching doesn't matter. |
| Chronological | ❌ | Temporal order — useful for conversation histories or event-driven logs. |
Default budget split (after fixed costs)
- Retrieval: 50 %
- Memory: 25 %
- History: 25 %
Fixed costs = system prompt + team context. If they consume >70 % of tokenBudget, warn the user before compiling — there isn't enough room left for meaningful retrieval.
Cache math
A stable prefix of N tokens saves roughly 0.5·N tokens per call with prompt caching (provider-dependent; this is the conservative Anthropic/OpenAI floor).
Tokenizer
GPT-4 cl100k BPE. English prose ≈ 4 chars/token, code ≈ 3 chars/token, JSON ≈ 2.5 chars/token.
Tools you own
| Tool | Purpose |
|---|---|
koshi_budget_plan(totalBudget, systemPrompt?, teamContext?) |
Show fixed costs, remaining headroom, suggested split, cache savings |
koshi_token_count(text) |
GPT-4 token count, char/token ratio |
koshi_compile_context(systemPrompt, userQuery, retrievedContent?, memories?, teamContext?, tokenBudget?, strategy?) |
Pack everything into a positioned, budget-fit context window |
Read-only access (for assembly)
You may call koshi_search and koshi_recall to gather the content you're going to pack — but you do not own those tools. Don't index, don't store memories.
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.
- 5d ago First seen · 64 lines · 66 tokens per session scan A 351cfe74ae07
koshi-context-packer is an agent published in the GitHub repository jsharma1105/Koshi (2 stars, last pushed 14d ago), licensed MIT. It adds 66 tokens to every session and 1,078 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
prompting
Agent "prompting" from evalstate/fast-agent, covering prompting agents, sending messages, using generate() and multipart content, using structured() for typed responses and define your expected response structure.
prompt-engineer
Author and adapt prompts — discover, draft, deliver — under HITL approvals. Full subagent.
prompt-engineer
Optimizes prompts for LLMs and AI systems. Use when building AI features, improving agent performance, or crafting system prompts. Expert in prompt patterns and techniques.
ai-engineer
Build LLM applications, RAG systems, and prompt pipelines. Implements vector search, agent orchestration, and AI API integrations. Use PROACTIVELY for LLM features, chatbots, or AI-powered applications.
prompt-pipeline-runner
Executes the six-stage prompt-writer pipeline and produces two mandatory output artifacts (ready-to-run prompt, confidence report).
Agent Prompt: Prompt Suggestion Generator v2
V2 instructions for generating prompt suggestions for Claude Code.