Reported issues for token-optimizer-mcp
Pod holds 19 of 22 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.
Back to token-optimizer-mcp.
Most discussed
CRITICAL: 3-6x Performance Degradation - Add Server-Level Timing
CRITICAL Performance Degradation
Tasks that used to take 20 minutes are now taking 1-2 hours (3-6x slowdown)
Root Cause Analysis (from Gemini CLI)
Gemini identified THREE major bottlenecks in the PowerShell hooks:
1. Excessive External Process Spawns (10-50ms EACH)
Problem: Each call to invoke-mcp.ps1 creates a NEW PowerShell process
Impact: Happens on EVERY hook invocation
Fix: Dot-source invoke-mcp.ps1 as functions instead of spawning processes
Read the thread · 2025-11-01 · closed · 3 comments
Living wiki graph: Derived-Knowledge Retrieval (retrieve verdicts, not evidence)
Summary
Build a per-project living wiki graph the agent writes as a side effect of working and reads instead of re-deriving. Full design: docs/WIKI_GRAPH.md (#203).
Why this is the differentiator
Every token optimizer on the market — including ours today — reduces the cost of an operation. Compress the output, cache the read, diff the re-read. That is a bounded win: you
Read the thread · 2026-07-30 · closed · 2 comments
feat: add token savings data to current-session.txt for easy real-time monitoring
Problem
Currently, current-session.txt only tracks operation counts, NOT actual token savings:
{
"lastOptimized": 0,
"sessionId": "aad1f532-43d3-44af-ba65-6f89c409b122",
"sessionStart": "20251031-082211",
"totalOperations": 2201,
"totalTokens": 0
}
Users must manually call get_session_stats() MCP tool to see their savings. This creates friction for:
- Real-time monitoring during sessions
- Quick checks of optimization effectiveness
- Dash
Read the thread · 2025-10-31 · closed · 2 comments
smart_glob/smart_grep hang >120s (unbounded traversal) on large repo trees; native dir/rg return instantly
Summary
smart_glob and smart_grep (token-optimizer MCP v5.5.0) hang past the 120s tool timeout and get backgrounded/killed when run against a large/deep repository tree, whereas the native equivalents (cmd /c dir, ripgrep) return in well under a second on the same paths. The tools are advertised as bounded/paginated replacements for the built-ins, so timing out where the built-in is instant is a correctness/perf defect — and it forces a fallback to the very built-ins the routing p
Read the thread · 2026-08-28 · closed · 1 comment
contradictedAt is stored provenance with no reader
Found during #315 (wiki-graph gap closure, part 1 of 3).
hooks-core/curate.mjs writes two fields when a contradiction is recorded: contradictionReason and contradictedAt. The reason now has a reader — it is surfaced in the dispute disclosure when a finding is served. contradictedAt is read by nothing.
It is stored provenance with no consumer, which is the defect class #315 exists to close, in its quietest form.
Two honest options
- Give it a reader. The plausible one: age
Read the thread · 2026-08-26 · closed · 1 comment
[BUG]
Bug: Invalid schema for cache_warmup function
Description
The mcp__token-optimizer__cache_warmup tool fails with a schema validation error when called through Claude Code MCP client.
Error Message
{ "error": { "message": "Invalid schema for function 'mcp__token-optimizer__cache_warmup': In context=('properties', 'accessHistory'), array schema missing items.", "type": "invalid_request_error", "param": "tools[96].parameters", "code": "invalid_func
Read the thread · 2026-04-15 · closed · external user · 1 comment
feat: implement granular per-hook/per-action/per-MCP-server token analytics
Problem
Currently, token-optimizer-mcp tracks aggregate token savings at the session level, but lacks granular visibility into:
- Token usage per hook (PreToolUse, PostToolUse, etc.)
- Token usage per action (Read, Write, Grep, etc.)
- Token usage per MCP server (token-optimizer, filesystem, github, etc.)
This makes it impossible to identify optimization opportunities and pinpoint which hooks/actions/servers are consuming the most tokens.
Proposed Solution
Implement server-
Read the thread · 2025-10-31 · closed · 1 comment
Claude Code runs no semantic harvest at all: #300 unregistered stop-harvest.mjs
Measured while executing Plan 2 (#320) of the #204 work.
What happened
#300 unregistered plugin/hooks/stop-harvest.mjs. Four capabilities went with it, silently:
- The transcript archive — restored in Plan 2 Task 5, because the local extractors read it.
- The
harvest-workerspawn — still dead. - Refusal detection — still dead.
- The harvest off-notice — still dead.
The consequence
On Claude Code, with a valid credential present, no semantic harvest runs. `h
Read the thread · 2026-08-26 · closed · 0 comments
Most recent
Plan 3: close the defect class, not its instances (#204, part 3 of 3)
Tracking issue for Plan 3 of the #204 wiki-graph work. Part 3 of 3; Plan 1 shipped as #315, Plan 2 is #320.
The plan is committed and self-sufficient: docs/superpowers/plans/2026-08-25-wiki-graph-plan-3-detector-and-allowlist.md on branch feat/close-wiki-graph-gaps-plan2. Read the "Execution state and corrections" section at the bottom first.
Runs last. Its allowlist-emptying task is incomplete by construction until Plans 1 and 2 remove their entries.
Why this is the load-beari
Read the thread · 2026-08-26 · closed · 0 comments
Plan 2: make the graph produce findings, and measure whether they pay (#204, part 2 of 3)
Tracking issue for Plan 2 of the #204 wiki-graph work. Part 2 of 3; Plan 1 shipped as #315.
The plan is committed and self-sufficient: docs/superpowers/plans/2026-08-25-wiki-graph-plan-2-production-and-measurement.md on branch feat/close-wiki-graph-gaps-plan2. Its "Execution state and corrections" section at the bottom is authoritative over the task text above it ? the tasks were written before Plan 1 ran and are wrong in five specific places.
What Plan 2 is for
Plan 1 made the
Read the thread · 2026-08-26 · closed · 0 comments
Content-addressed anchors: a finding about a vendored file should reach every repo holding it
Extracted from #315 (wiki-graph gap closure, part 1 of 3), where contentAnchor was deleted rather than left dormant on the reachability allowlist.
The idea is worth keeping. From its docblock before deletion:
A vendored library file is the same file in every repository that holds it, whatever path each gives it. Anchoring to content as well as path means a finding about it appears in all of them with no promotion step and no path mapping — reach a per-session checkpoint cannot have even in
Read the thread · 2026-08-26 · closed · 0 comments
A drainer killed mid-claim strands its pending-invalidation records
Found during #315 (wiki-graph gap closure, part 1 of 3), in code that PR added.
drainInvalidations in hooks-core/pending.mjs claims the pending-invalidation queue by renaming it to a per-pid claim file, then reads and deletes the claim. That closes the original defect — a concurrent append being deleted unread — and two drainers cannot lose a record, because the loser's renameSync throws and its recovery block is guarded on its own pid.
The residual
A drainer **killed between the ren
Read the thread · 2026-08-26 · closed · 0 comments
Injected text is unescaped: a stored claim or dispute reason can forge lines in the model's context
Found during #315 (wiki-graph gap closure, part 1 of 3). Filed rather than fixed there, because it is a pre-existing class that PR widened rather than introduced.
The problem
Stored text reaches a model's context without escaping. Two surfaces:
hooks-core/curate.mjsstorescontradictionReasonasString(reason || '').slice(0, 400)— unfiltered — andhooks-core/inject.mjsrenders it with only a trim and a length cap.render()ininject.mjsemitsfinding.claimequally raw, a
Read the thread · 2026-08-26 · closed · 0 comments
Dashboard: /wiki route 404s + "active session" widget reads unwired path
Found two bugs in the shipped dashboard (npm run dashboard, dist/server/web-server.js), tested on v5.7.0 installed via npm install -g @ooples/token-optimizer-mcp@latest.
Bug 1: /wiki route 404s (res.sendFile fails despite file existing)
GET /wiki and clicking the "What it knows" nav tab both 404 with:
NotFoundError: Not Found
at createHttpError (node_modules/send/index.js:861:12)
at SendStream.error (node_modules/send/index.js:168:31)
at SendStream.pipe (node_mo
[Read the thread](https://github.com/ooples/token-optimizer-mcp/issues/311) · 2026-08-20 · closed · external user · 0 comments
### Codex plugin installs but MCP server exits before registering tools on Windows
## Summary
The token-optimizer Codex plugin is installed and enabled, but its MCP server exits before registering any tools on Windows. The packaged doctor also fails its server-response check. In addition, the doctor appears to inspect a stale Claude plugin installation (5.5.0) while diagnosing the current Codex/npm package (5.7.0).
## Environment
- Windows 11 (`Microsoft Windows NT 10.0.22631.0`)
- Windows PowerShell `5.1.22621.4249`
- Codex CLI `0.147.0`
- Node.js `v22.2.0`
- npm `10.7.0`
[Read the thread](https://github.com/ooples/token-optimizer-mcp/issues/307) · 2026-08-13 · closed · 0 comments
### feat: implement compression for stored optimization results
## Summary
Implement gzip compression for stored optimization results, session files, and cache data to reduce disk I/O and storage costs.
## Background
Currently, the token optimizer stores large amounts of data uncompressed:
- **Session files**: `current-session.txt`, operation CSV files (grow to several MB)
- **Cache data**: File content cache, optimization results (can be 10-100MB)
- **Operation logs**: CSV logs with full tool input/output (grow rapidly)
Gemini CLI uses gzip compr
[Read the thread](https://github.com/ooples/token-optimizer-mcp/issues/126) · 2025-11-03 · closed · 0 comments
### feat: implement LRU cache for expensive operations
## Summary
Implement a Least Recently Used (LRU) cache to store results of expensive operations (file search, edit correction, token counting, MCP API calls) and prevent redundant computation.
## Background
Currently, the token optimizer performs expensive operations repeatedly:
- **File search**: Scanning repository for patterns (takes 100-500ms per search)
- **Edit correction**: Running MCP `correct_edits` API (takes 500-2000ms per file)
- **Token counting**: Calling Google AI API or p
[Read the thread](https://github.com/ooples/token-optimizer-mcp/issues/125) · 2025-11-03 · closed · 0 comments
### feat: implement sophisticated token counting (beyond character/4)
### Problem
The current token counting mechanism is a mix of a simple estimation (length / 4) and a call to the Google AI countTokens API. This is not a robust solution for a production environment for several reasons:
* **Inaccurate Fallback:** The length / 4 estimation is highly inaccurate for different types of content (code, JSON, etc.) and different languages.
* **Vendor Lock-in:** The countTokens API is specific to Google AI models. The system should be able to handle models from othe
[Read the thread](https://github.com/ooples/token-optimizer-mcp/issues/124) · 2025-11-03 · closed · 0 comments
### feat: implement context delta tracking (only send changes)
### Problem
The current system sends the entire context with every request. This is inefficient and can lead to higher costs and slower response times, especially for long conversations.
### Desired State
A system that can:
* Track the conversation history and file state for each user session.
* Calculate the delta between the previous and current context.
* Send only the delta to the model.
* Persist session information across restarts.
### Revised Implementation Plan
This revised pl
[Read the thread](https://github.com/ooples/token-optimizer-mcp/issues/122) · 2025-11-03 · closed · 0 comments
The remaining reports are on [the project's issue tracker](https://github.com/ooples/token-optimizer-mcp/issues).