Launched this week
Keen Code
A context-efficient CLI coding agent built by agents
137 followers
A context-efficient CLI coding agent built by agents
137 followers
Keen Code is an open-source, context-aware and efficient CLI coding agent written in Go. Three aspects stand it out from other similar products: - It was built from scratch by coding agents, with the full prompt/design trail preserved and shared in the repo. - It uses turn memory to keep multi-turn sessions lean which saves context significantly. - It maps MCP servers to lazy-loaded Skills instead of stuffing large schemas into context upfront. This again saves context in mult-MCP setting.
Keen Code
Building a CLI agent that manages its own context window is a genuinely hard problem. We've dealt with similar tradeoffs in long-running background jobs where keeping relevant context without blowing token budgets required careful chunking. What's your eviction strategy when the agent's working set grows mid-task: do you prioritize recency or semantic relevance?
Keen Code
@anand_thakkar1 Hey! Good question. Right now Keen prefers keeping user-agent interaction over tool calls. And in my experience, tool call results have been the single most costly part of the context window.
So if an agent loop grows too much that it cannot fit in the context any more, the simple strategy is to evict oldest tool results for the turn and so on. Since Keen doesn't retain tool results beyond a single turn, the context is already lean when a new turn starts. As a result, this strategy to evict oldest tool results is enough to reduce in-turn context window size.
The "lazy-loaded Skills instead of stuffing MCP schemas into context upfront" choice is the detail that stood out to me - that's usually where multi-MCP setups quietly fall apart, the context budget gets eaten before you do any real work.
As someone still figuring out how to keep agent sessions lean, I'm curious: with turn memory compacting older turns, how do you decide what's safe to drop vs keep? Do you summarize older turns or hard-truncate them? Wondering where the line is before the agent starts "forgetting" a constraint from earlier in the session.
Also love that the whole prompt/design trail is in the repo - genuinely useful to learn from. Respect for building it solo. Congrats on the launch.
Keen Code
@grace_lee26 Turn memory is pretty simple and dumb. Right now it's a Go struct with two fields: files_changed and failed_bash_commands. This is to give later turns a simple sticky note: this is what changed in the previous turns and this is what failed. That's it.
The reasoning behind this is that if agent needs to refer to some tool result before, it should simply run that tool again. In fact, SoTA agents do that frequently: they read some file, does some change. Later, if you ask them to do something else, they read the same file again to ensure the latest state.
So Keen's thought process is: just don't retain tool call results from read_file or grep or other tools after an agent turn loop finishes.
The context-efficiency angle is what stands out to me here — lazy-loading MCP skills instead of front-loading schemas is a genuinely smart architectural choice that most CLI agents skip. Fellow solo builder launching nearby (Sensemaker, a thinking-to-writing tool), and the "built by agents, orchestrated by human" workflow you described is almost exactly how I shipped my own MVP. Curious: how did you handle the moments where the agent went off-spec mid-session? Did you find the prompt/design trail in the repo was enough to course-correct, or did you need other guardrails?
Keen Code
@eran_shayshon Hey, yes going off-spec mid-session has not been a problem. I think it's up to you to carefully design how big of a bite you would want the agent to take. As long as it's reasonably planned, it works pretty well.
Really cool, and respect for building it solo. The turn memory idea for keeping context lean is smart. How much context does it actually save in a long session?
Keen Code
@ianhxu In my experience, it has been significant. I have done some very basic benchmarking between Keen vs OpenCode. In those benchmarks, I have clearly seen Keen's context window drops 1/10th from one agent turn loop to the next.
Context window size for OpenCode grows linearly. The more a multi-turn conversation progresses, it keeps going up. With Keen, it grows within a turn, but comes back down significantly after a turn. The next turn starts with a far smaller context compared to previous turn's end.
The tradeoff that Keen has here is pretty obvious: if agent needs to refer to some tool call results done a turn or more ago, that result is no more available. The counter-argument here is that models can always re-run those tools, assuming those tools are idempotent. There has to be some shenanigans done for MCP tools, which I intend to address in next releases.
Here is a Claud-written analysis: https://mochow13.github.io/keen-code/docs/turn-memory-analysis.html. It's a bit dramatic but good for understanding the idea.
One thing we've noticed with agent workflows is that reducing context size and improving context quality are often treated as the same problem when they're actually different.
Have you found Keep Code's biggest win coming from compression, retrieval, or helping agents maintain a more consistent mental model of the codebase across longer sessions?
Keen Code
@zaid_mallik1 Good question. Not exactly mental model, but I have been thinking to experiment with a pre-calculated repository mapping for agents. I don't know if it will surely improve efficiency or performance, but need to actually implement and get a feel for it.
For Keen, yes the focus is indeed context efficiency through compression or lazy loading where possible. I think this is what the biggest win would be.
@mochow13 That's interesting because repository mapping feels like it sits somewhere between compression and retrieval.
Instead of reducing context after the fact, you're giving the agent a higher-level representation of the codebase before it starts reasoning.
We've seen cases where agents don't fail because the relevant files are missing, but because they never build the right picture of how the pieces fit together. A repository map seems like it could help with that.
I'd be curious whether you end up generating that map statically from the codebase structure, or whether it evolves based on what agents actually touch and modify over time.
Context efficiency is the right constraint to optimize for in a coding agent. Most agents bloat the context window with irrelevant file chunks and then thrash on eviction decisions. We've hit this exact failure mode building multi-file reasoning features and it's where agent reliability falls apart. How does Keen Code handle context prioritization across a multi-step tool use chain when multiple files are relevant?
Keen Code
@retain_dev I am not entirely sure I understood your question :D
Right now, there is nothing done specifically for prioritisation between multiple files in Keen.