More Token usage when used with Claude code starting from Fable 5 start and now from last 2 days in 5.6 Sol too

[Veerus007]

Version

codebase-memory-mcp 0.7.0

Platform

macOS (Intel)

Install channel

npm

Binary variant

standard

What happened, and what did you expect?

Hi ,
I have been using using it for quite some time but after release of Fable 5 I saw this mcp used 5% , 10% or 20% jump when I asked Claude. I noticed even worst is when we are in the middle of some task and we hit the limit and once the reset happens and it starts working then it even some times consumed 50% of token in less than 5 min so I stopped using this map in Claude code by setting it in Claude.md and etc.

Fast forward till 2 days before we saw/seeing even now this (you might be aware of heavy drain of Codex tokens) heavy drain in GPT tokens , weekly is working like hourly drain and thing that has to work for week is exhausted in less than few hours in sol 5.6 medium too.,

Note I use this only in Claude & CODEX CLI VERSION. no other web/app only for coding purpose .

Now I have stopped using , if any fix for this please let me know.

Thanks & Regards,
Veeru

Reproduction

I have written above.

Regular use in Claudecode
Just one hit consumes 1% of 5hr .

More importantly what I noticed even drastic as mentioned in the above message :
when we are in the middle of some task and we hit the limit of Claude code CLI and once the reset to 100% happens and we start or ask it to continue , it starts working then it consumes upto50% of token in less than 5 min(I realised 1st time so noticed and intentionally tried at 99% and gave a task to see if it happens after token exhaust in next session and it was running like a minute/seconds of clock) so I stopped using this map in Claude code by setting it in Claude.md and etc.

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

No response

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.

[DeusData]

Thanks for raising this and for describing when the jump becomes visible. The reported CBM version is 0.7.0, which predates the current compact output path. On current main, search_graph emits grouped compact rows and blocks internal fingerprint/profile/body-token fields from agent output (src/mcp/mcp.c:3014-3025).

A client quota percentage does not identify which tool response caused the spend. Could you retest with 0.9.0 or the current 0.9.1 release candidate and provide one exact CBM tool name, its arguments, and the response byte size from a high-usage turn? That will let us separate CBM payload size from client/model accounting. Marked awaiting-reporter; thank you for helping pin it down.

[github-actions]

Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:

• the codebase-memory-mcp --version you're on
• the exact steps or command you ran
• a public repo (or a small dummy snippet) that shows the problem — please don't paste proprietary code

Once that's here we'll pick it straight back up. Heads-up: issues left awaiting-reporter are automatically closed after a few weeks of silence, but a comment reopens the door anytime.