<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Token Efficiency on RockB</title><link>https://baeseokjae.github.io/tags/token-efficiency/</link><description>Recent content in Token Efficiency on RockB</description><image><title>RockB</title><url>https://baeseokjae.github.io/images/og-default.png</url><link>https://baeseokjae.github.io/images/og-default.png</link></image><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 13 Aug 2026 01:01:43 +0000</lastBuildDate><atom:link href="https://baeseokjae.github.io/tags/token-efficiency/index.xml" rel="self" type="application/rss+xml"/><item><title>Memoket Kite Review 2026: Token-Efficient Memory Layer for AI Agents</title><link>https://baeseokjae.github.io/posts/memoket-kite-agent-memory-layer-2026/</link><pubDate>Thu, 13 Aug 2026 01:01:43 +0000</pubDate><guid>https://baeseokjae.github.io/posts/memoket-kite-agent-memory-layer-2026/</guid><description>Memoket Kite is an open-source, vector-free memory layer for AI agents that scores 93.51% on LoCoMo using just 1.51k tokens of reader context.</description><content:encoded><![CDATA[<p>Memoket Kite is an open-source memory layer for AI agents that replaces the standard embeddings-plus-vector-database stack with a single portable, topic-indexed file of structured facts. It scores 93.51% on the LoCoMo long-conversation benchmark and 85.60% on LongMemEval-S while reading only about 1.5k tokens of context — the top overall score on both benchmarks with no vector stack at all.</p>
<h2 id="what-is-memoket-kite-a-memory-layer-for-ai-agents">What Is Memoket Kite? A Memory Layer for AI Agents</h2>
<p>Memoket Kite (KITE) is a Python library, released under the Apache License 2.0, that gives AI agents persistent, source-backed memory. Its tagline is &ldquo;Follow the thread, not the nearest match.&rdquo; Instead of storing conversations as opaque embedding vectors and retrieving by similarity, KITE turns what an agent hears into typed, dated, topic-indexed facts that you can open and read in a plain file.</p>
<p>The library was created by Memoket and first published on 2026-08-12. It is a plain Python package — <code>pip install memoket-kite</code> — with a deliberately small API surface: <code>Memory.load</code>, <code>memory.remember</code>, <code>memory.recall</code>, and <code>memory.answer_with_evidence</code>. There is no vector database to provision, no embedding model to run, and no reranker to tune.</p>
<p>KITE is also the memory algorithm inside the Memoket wearable AI device, which offers 48 hours of continuous recording and instant voice capture. That consumer tie-in is unusual among agent-memory frameworks, which are almost entirely developer-facing infrastructure.</p>
<h2 id="why-agent-memory-matters-and-why-most-agents-have-amnesia">Why Agent Memory Matters (and Why Most Agents Have Amnesia)</h2>
<p>Most AI agents have no persistent memory. Every session starts from scratch, which means the same context gets re-injected into the model over and over. That is not just wasteful — it is expensive. Re-injecting context is one of the largest hidden token costs in production agent systems, and it grows linearly with every conversation you want the agent to remember.</p>
<p>The practical symptoms are familiar. An agent forgets a user&rsquo;s stated preferences between sessions. A correction you made last week does not stick. Domain rules that evolve over time are never reflected in the next run. Persistent entities — customers, projects, tickets — have to be re-explained every time.</p>
<p>A memory layer solves this by persisting what matters and retrieving only what is relevant. The decision guide from the 2026 agent-memory landscape is clear: you need memory if your agent runs repeatedly on related tasks, if corrections should stick, if domain rules evolve, if you track persistent entities, or if high token costs from re-injecting context are eating your budget.</p>
<h2 id="how-kite-works-from-conversation-to-cited-answer">How KITE Works: From Conversation to Cited Answer</h2>
<p>KITE&rsquo;s pipeline is straightforward and inspectable at every step. When an agent hears something, <code>memory.remember</code> extracts structured facts — typed, dated, and indexed by topic — and writes them to a single portable file. When a question comes in, <code>memory.recall</code> or <code>memory.answer_with_evidence</code> compiles the query into a symbolic plan.</p>
<p>That plan is the key differentiator. Every question compiles into a readable <code>select</code> / <code>where</code> / <code>pipe</code> expression that reveals exactly how an answer was matched. This is not a black-box similarity search; it is a deterministic, inspectable retrieval path. You can read the plan and see which facts were selected, which filters were applied, and how the final answer was assembled.</p>
<p>The answer itself comes with evidence. KITE links each response back to who said it, when they said it, and the actual words used. This &ldquo;shows its work&rdquo; behavior is a trust advantage over systems that return a plausible-sounding answer with no provenance.</p>
<h2 id="the-no-vector-stack-approach-structured-facts-over-embeddings">The &ldquo;No Vector Stack&rdquo; Approach: Structured Facts Over Embeddings</h2>
<p>The most provocative claim in the KITE pitch is that it needs no vectors at all. No embeddings, no vector database, no rerankers. Instead of representing memory as high-dimensional points in a similarity space, KITE stores structured, topic-indexed facts in one portable file.</p>
<p>Why does this matter? Vector retrieval has real costs. Embedding models add latency and compute. Vector databases are another piece of infrastructure to operate. And similarity search has a fundamental weakness: it has no notion of time or structure. A nearest match can be the wrong match — semantically close but factually stale, or close in embedding space but irrelevant to the actual question.</p>
<p>KITE&rsquo;s structured approach sidesteps these problems. Facts are typed and dated, so retrieval can be time-aware. Facts are topic-indexed, so retrieval is precise rather than fuzzy. And because everything lives in a plain file, the whole memory is portable, inspectable, and versionable — you can open it and read exactly what the agent knows.</p>
<h2 id="benchmark-results-locomo-and-longmemeval-s">Benchmark Results: LoCoMo and LongMemEval-S</h2>
<p>The headline numbers come from two long-conversation memory benchmarks, both run under one shared protocol with gpt-4.1-mini as the common reader and judge. Each figure ships with a sealed, reproducible run that recomputes offline.</p>
<table>
  <thead>
      <tr>
          <th>Benchmark</th>
          <th>KITE Accuracy</th>
          <th>Avg Reader Context</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>LoCoMo</td>
          <td>93.51%</td>
          <td>1.51k tokens</td>
      </tr>
      <tr>
          <td>LongMemEval-S</td>
          <td>85.60%</td>
          <td>1.65k tokens</td>
      </tr>
  </tbody>
</table>
<p>Two things stand out. First, KITE posts the top overall score on both benchmarks. Second, it does so while reading less context than any capable rival — roughly 1.5k tokens of reader context per answer. That combination of top accuracy and minimal context is exactly what &ldquo;token-efficient agent memory&rdquo; means in practice.</p>
<p>The token-efficiency angle is the differentiator. Rivals that read far more context to reach comparable accuracy pay more per query, and that cost compounds across every retrieval an agent makes. KITE&rsquo;s ~1.5k-token reader context directly attacks the cost of re-injecting context that drives most agent memory bills.</p>
<h2 id="kite-vs-mem0-letta-zep-and-cognee-how-it-compares">KITE vs. Mem0, Letta, Zep, and Cognee: How It Compares</h2>
<p>The established agent-memory frameworks KITE competes against are well funded and widely adopted. Mem0 has roughly 48K GitHub stars, Letta about 21K, Zep/Graphiti about 24K, and Cognee about 12K. KITE is new, so it does not yet have that community footprint — but it is positioning on architecture and efficiency rather than adoption.</p>
<table>
  <thead>
      <tr>
          <th>Framework</th>
          <th>Architecture</th>
          <th>License</th>
          <th>Approx Stars</th>
          <th>Vector Stack</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>Mem0</td>
          <td>Vector + graph</td>
          <td>Apache-2.0</td>
          <td>~48K</td>
          <td>Yes</td>
      </tr>
      <tr>
          <td>Letta</td>
          <td>Tiered OS-inspired memory</td>
          <td>Apache-2.0</td>
          <td>~21K</td>
          <td>Yes</td>
      </tr>
      <tr>
          <td>Zep/Graphiti</td>
          <td>Temporal knowledge graph</td>
          <td>Apache-2.0</td>
          <td>~24K</td>
          <td>Yes</td>
      </tr>
      <tr>
          <td>Cognee</td>
          <td>Knowledge graph + vector</td>
          <td>Open core</td>
          <td>~12K</td>
          <td>Yes</td>
      </tr>
      <tr>
          <td>Memoket Kite</td>
          <td>Topic-indexed structured file</td>
          <td>Apache-2.0</td>
          <td>New</td>
          <td>No</td>
      </tr>
  </tbody>
</table>
<p>The architectural contrast is the story. Mem0 pairs vector search with a graph for personalization. Letta manages memory like an operating system with tiers. Zep/Graphiti is strongest on temporal relationships via a temporal knowledge graph. Cognee structures institutional knowledge with a knowledge graph plus vectors. All of them run a vector stack.</p>
<p>KITE is the only top-scoring system on both LoCoMo and LongMemEval-S that uses no vectors. That is a meaningful claim in a field where vector retrieval is the default assumption. Whether that advantage holds at scale in production is the open question — but on the published benchmarks, the numbers are on KITE&rsquo;s side.</p>
<h2 id="key-features-time-aware-retrieval-explainability-and-honest-uncertainty">Key Features: Time-Aware Retrieval, Explainability, and Honest Uncertainty</h2>
<p>Three features separate KITE from a naive fact store.</p>
<p><strong>Time-aware retrieval.</strong> Nearest-match memory has no notion of &ldquo;now.&rdquo; KITE sorts facts by date, so when an agent asks about a person, event, or update, &ldquo;now&rdquo; means now. A fact that was superseded last week is not returned as if it were current. This is a concrete correctness win for agents that track evolving state.</p>
<p><strong>Explainability.</strong> Every answer compiles into a symbolic plan and carries evidence links back to who said it, when, and the actual words. You can audit why an agent answered the way it did. For regulated or high-stakes use cases, that provenance is hard to overstate.</p>
<p><strong>Honest uncertainty.</strong> KITE returns genuinely empty when something was never said. It does not hallucinate a nearest match to fill the gap. Knowing what an agent does not know is often as valuable as knowing what it does — and it prevents the confident-wrong answers that similarity search tends to produce.</p>
<h2 id="getting-started-quick-start-with-memoket-kite">Getting Started: Quick Start with memoket-kite</h2>
<p>Getting started is a three-call API. Install the package, load a memory, remember facts, and recall or answer with evidence.</p>
<div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>pip install memoket-kite
</span></span></code></pre></div><div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-python" data-lang="python"><span style="display:flex;"><span><span style="color:#f92672">from</span> memoket_kite <span style="color:#f92672">import</span> Memory
</span></span><span style="display:flex;"><span>
</span></span><span style="display:flex;"><span>memory <span style="color:#f92672">=</span> Memory<span style="color:#f92672">.</span>load(<span style="color:#e6db74">&#34;my_agent.kite&#34;</span>)   <span style="color:#75715e"># open a portable, topic-indexed file</span>
</span></span><span style="display:flex;"><span>memory<span style="color:#f92672">.</span>remember(<span style="color:#e6db74">&#34;Alice prefers concise summaries&#34;</span>)  <span style="color:#75715e"># store a structured fact</span>
</span></span><span style="display:flex;"><span>answer <span style="color:#f92672">=</span> memory<span style="color:#f92672">.</span>answer_with_evidence(<span style="color:#e6db74">&#34;How does Alice like her summaries?&#34;</span>)
</span></span><span style="display:flex;"><span>print(answer<span style="color:#f92672">.</span>text)      <span style="color:#75715e"># the answer</span>
</span></span><span style="display:flex;"><span>print(answer<span style="color:#f92672">.</span>evidence) <span style="color:#75715e"># who said it, when, and the actual words</span>
</span></span></code></pre></div><p>There is no vector database to stand up and no embedding model to configure. The memory is a single file you can open, read, and version. For a developer evaluating agent memory, that is the fastest possible path from zero to a working, inspectable memory layer.</p>
<h2 id="integrations-and-the-memoket-wearable-tie-in">Integrations and the Memoket Wearable Tie-In</h2>
<p>KITE&rsquo;s integrations for Claude Code, Codex, Cursor, and OpenCode are on the roadmap but not yet shipped. That is a gap versus frameworks like MemMachine, which already offer native MCP servers for Claude Desktop and Cursor, or Mem0, which has broad framework integrations. If you need a drop-in integration today, KITE is not there yet — you will be working with the Python API directly.</p>
<p>The more distinctive angle is the wearable. KITE is the memory algorithm inside the Memoket wearable AI device, which records continuously for 48 hours and supports instant voice capture. That means the same memory layer that powers an agent can power a personal, always-on assistant that remembers your life. Most agent-memory frameworks have no consumer product at all; KITE&rsquo;s is a genuine differentiator, even if it is not yet relevant to most developers.</p>
<h2 id="pros-and-cons-who-should-use-kite">Pros and Cons: Who Should Use KITE</h2>
<p><strong>Pros:</strong></p>
<ul>
<li>Top benchmark accuracy on LoCoMo (93.51%) and LongMemEval-S (85.60%).</li>
<li>Extremely token-efficient: ~1.5k tokens average reader context.</li>
<li>No vector stack — no embeddings, vector DB, or rerankers to operate.</li>
<li>Fully inspectable: readable plans and source-backed evidence on every answer.</li>
<li>Time-aware retrieval and honest uncertainty handling.</li>
<li>Apache-2.0, plain Python, portable single-file memory.</li>
</ul>
<p><strong>Cons:</strong></p>
<ul>
<li>New project with a small community footprint versus Mem0, Letta, Zep, and Cognee.</li>
<li>Integrations for Claude Code, Codex, Cursor, and OpenCode are still on the roadmap.</li>
<li>Structured-fact extraction may not suit every use case; some workloads genuinely need semantic similarity.</li>
<li>Benchmark claims are self-published and should be validated in your own workload.</li>
</ul>
<p>KITE is best suited to developers who want a lightweight, explainable, token-efficient memory layer and are comfortable working with a young open-source library. If you need mature framework integrations, a large community, or proven production scale, the established frameworks are the safer bet today.</p>
<h2 id="verdict-is-memoket-kite-worth-it-in-2026">Verdict: Is Memoket KITE Worth It in 2026?</h2>
<p>Memoket KITE is worth a serious look if token cost and explainability are your priorities. The benchmark results are the strongest argument: top overall accuracy on both LoCoMo and LongMemEval-S while reading about 1.5k tokens of context — a combination no vector-based rival matches on the published numbers. The no-vector architecture is genuinely novel in a field where embeddings are the default, and the inspectable, source-backed answers are a real trust advantage.</p>
<p>The caveats are equally real. KITE is a brand-new project with a small community, no shipped framework integrations yet, and self-published benchmarks. For production systems that need mature integrations and proven scale, Mem0, Letta, Zep, or Cognee remain the safer choices.</p>
<p>For a developer who wants to cut agent memory token costs, keep memory fully inspectable, and is willing to work with a young library, KITE is the most interesting new option in the 2026 agent-memory landscape. Start with the three-call API, run it against your own workload, and let the evidence — not the nearest match — decide.</p>
<h2 id="faq">FAQ</h2>
<p><strong>What is Memoket Kite?</strong>
Memoket Kite is an open-source, Apache-2.0 Python library that gives AI agents persistent, source-backed memory. It stores typed, dated, topic-indexed facts in a single portable file instead of using embeddings and a vector database.</p>
<p><strong>Does Memoket Kite use a vector database?</strong>
No. KITE is the only top-scoring system on both LoCoMo and LongMemEval-S that uses no vectors — no embeddings, no vector DB, and no rerankers. It relies on structured, topic-indexed facts in a plain file.</p>
<p><strong>How accurate is Memoket Kite on memory benchmarks?</strong>
KITE scores 93.51% overall accuracy on the LoCoMo long-conversation benchmark and 85.60% on LongMemEval-S, both with roughly 1.5k tokens of average reader context. These are the top overall scores on both benchmarks under a shared protocol.</p>
<p><strong>How does Memoket Kite compare to Mem0, Letta, Zep, and Cognee?</strong>
KITE is newer and has a much smaller community than Mem0 (~48K stars), Letta (~21K), Zep (~24K), and Cognee (~12K). Its differentiators are a no-vector architecture, top benchmark accuracy at minimal token cost, and fully inspectable, source-backed answers.</p>
<p><strong>How do I get started with Memoket Kite?</strong>
Install it with <code>pip install memoket-kite</code>, then use the three-call API: <code>Memory.load</code> to open a memory file, <code>memory.remember</code> to store facts, and <code>memory.recall</code> or <code>memory.answer_with_evidence</code> to retrieve answers with evidence. No vector database or embedding model is required.</p>
]]></content:encoded></item></channel></rss>