9 comments

  • damsta1 minute ago
    I don't like any of current solutions when it comes to compaction. I'd love to have a way to say what exactly should be summarized, because most of the time I just need to compact some noisy MCP tool calls, test runs and things like that. Just let me pick what should be summarized and keep the rest as is.
  • novaRom27 minutes ago
    Compaction is painful if you run just one local LLM, the best way to avoid it is to keep context as small as possible.<p>One trick I find useful is to have one model with two KV caches running and while first cache has produced tokens, second cache immediately summarizes them during input tokens are being generated (tools time), then harness switches to the second KV cache which takes newly produced input tokens while KV in first cache is getting replaced with compacted summary tokens. This is a kind of ping pong, so we trade more space for less time. Still experimenting but it looks it works, and nice bonus it improves GPU utilization. Btw I have my own harness and model serving code, but it can be easily implemented in any other harness and model server.
  • storus34 minutes ago
    The advantage of running local stack is that you can do the compaction at the time of inference, i.e. some tool call runs out of context, you can just pause inference, purge&#x2F;replace old tool calls with their summaries or just logs by operating directly over tokens on a GPU, rebuilding KV cache (one time prefill hit) and resuming the inference, easily being able to e.g. read 1000 markdowns, each 50k long, in a single LLM call. That&#x27;s not possible with current agentic harnesses using LLM calls.
  • kennywinker53 minutes ago
    Compaction has been a pretty painful part of local llm usage. Scrapping the current context and parsing almosy 128k of context then generating something like 5-10k tokens - that can take quite a while when you’re working with 10t&#x2F;s-45t&#x2F;s (depending on the model).<p>I pretty much just start a new session whenever i fill the context.
  • searealist9 minutes ago
    I expect Pi is mostly used with OpenAI plans, and OpenAI has a dedicated compaction endpoint you should probably be using with their models instead of a compaction prompt.
  • Gecko40721 hour ago
    Can someone recommend a Hermes alternative that is less token hungry? Pi did not work well for my use case.
    • pkulak41 minutes ago
      I keep my max context really small for personal assistant agents; they don&#x27;t need it. Especially since compaction keeps anything important around anyway. I use 60k with Pi.
    • skinfaxi1 hour ago
      I found hermes to be really lightweight, though I am on a relatively older version and built a custom plugin to lazily load mcps (that&#x27;s probably in hermes proper by now). Compared to kilo it seems to consume far fewer tokens.
  • randomblock11 hour ago
    TLDR: It keeps ~20k tokens of recent conversations, then hands the rest of the conversation to another model with a special system &amp; user prompt. This then fills out a template with relevant information.<p>See: <a href="https:&#x2F;&#x2F;github.com&#x2F;earendil-works&#x2F;pi&#x2F;blob&#x2F;main&#x2F;packages&#x2F;coding-agent&#x2F;src&#x2F;core&#x2F;compaction&#x2F;compaction.ts#L463-L498" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;earendil-works&#x2F;pi&#x2F;blob&#x2F;main&#x2F;packages&#x2F;codi...</a>
  • cyanydeez51 minutes ago
    [dead]