mochow13

Exactly! Thanks for your honest opinion.

That's a very good point. I myself have been getting hooked to terminal throughout the day and indeed, it requires a lot of reading. As a first iteration, Keen can have a concise mode where agent prose is precise, tool call rendering is minimal, bash outputs are hidden. That feels a good minimalist approach.

Thanks, I think I will work on this.

Thanks for your feedback! The greatest motivation behind building yet another coding agent it to try two things:

- Experimenting with the "new way of working" where I only drive the development instead of actively writing code and creating implementation plans or design docs. But yes, I have been thoroughly reviewing every line of code, design docs, and plans.

- Context efficiency. As I have shared in the comment above, Keen takes different approach for context handling. The first one is conservative: don't keep tool i/o beyond a single agent turn. This is why you will see that context window percentage goes down every time you send a new message in Keen. Secondly, MCP server full schemas are never loaded preemptively. In fact, only specific tool's schema in an MCP server is loaded only when needed. This process is driven by Agent Skills.

So the bottom line, the reason for building another CLI coding agent is to try out some ideas and experimenting with them, and also to build something substantial from scratch using agents.

Hi HN! Happy to share Keen Code, yet another CLI-based coding agent. I have been working on this solo since February as a side-project. While building this, I took the opportunity to experiment with context efficiency.

Here are three worth-mentioning things about Keen Code:

1. Built by agents

I built this whole thing from scratch using SoTA coding agents. My role was strictly a human orchestrator who created prompts and requirements, and reviewed designs and code written by agents. To remain fully transparent, the project has this ai-interactions folder that shares all the prompts and output docs. More details on this can be found here: https://mochow13.github.io/keen-code/TOUR.html.

2. Turn memory

To stop the context window from filling up during multi-turn loops, Keen completely discards raw tool inputs/outputs after a turn is completed. Instead, it distills lessons into a "turn memory" (a stupidly simple, deterministic Go struct) passed to the next turn. More: https://mochow13.github.io/keen-code/docs/turn-memory.html

3. Skills driven MCP servers

Instead of bloating the LLM context by loading massive Model Context Protocol (MCP) server schemas upfront, Keen abstracts them into local markdown "Skills." It lazily retrieves the exact JSON schema only when the LLM requests that specific tool at runtime. The approach is a little bit complex - details are here: https://mochow13.github.io/keen-code/docs/mcp-skills.html

I have been personally using Keen in developing Keen itself, and in my other projects. So far, I am quite satisfied with it. So I am looking forward to questions, feedback, suggestions and reviews. I am committed to this project for a long time and willing to enhance its usefulness.

Thanks in advance!

OpenAI is tailgating Anthropic apparently.