Keen Code

Details

External ID

49250229

Source

HN

Company

—

Product

Keen Code

Website domain

github.com

Launched

Aug. 10, 2026

Cohort

—

Upvotes

6

Upvotes percentile

0.3125

Tags

—

Fetched at

Sept. 10, 2026, 5:32 a.m.

Updated at

Sept. 10, 2026, 5:32 a.m.

Description

Hello community!I am here to share a coding agent I have built solo from scratch using agentic engineering. Written in Go, it's a proper coding agent, has features you expect from a useful agent for your daily work, with a minimal and simple UI.I have named it Keen Code. The repo is here: https://github.com/mochow13/keen-codeEven though it started as an experiment, it is now a full-fledged coding agent for real software engineering work. It supports multiple providers, skills, MCPs, multi-agent orchestration through subagents, automatic compaction, etc.I have been using it for real production-grade work myself, and also for developing itself.Notably, I have worked on two separate ideas in this coding agent:1. Turn MemoryIn a multi-turn conversation, tool outputs are removed, only tool call traces are retained. Within a single agent loop, agent sees full tool results but in the next turn, it doesn't see the tool results anymore.The greatest benefit of this approach is that a lot of tool results that are not needed in following turns don't occupy the context. As a result, context window in a multi-turn conversation with Keen Code fills up much slowly compared to other agents. This is why you will regularly see context window coming down from 20% to 1% at the beginning of a new agent turn.Of course, this approach has its pros and cons. If agent requires tool result from a previous call, it doesn't have them. But my idea is that tool calls like read, bash, web_fetch are cheap. Do you need to refer to some earlier file you read? Read again. In fact, Claude Code or Codex frequently re-read a file, even though it has read the same file before.I have plans for more effort in this area. I have a few additional ideas to explore and possibly optimise this approach further.If you want to read about it: https://mochow13.github.io/keen-code/docs/turn-memory.html2. Skill-Driven MCPAnother idea I have implemented is skill-driven MCPs. The goal is similar to what Anthropic did with tool-search-tool: optimise context.In this idea, each MCP server receives a skill. But this skill is not typical "guidance" skill for MCP server usage, rather generated by Keen. Details here: https://mochow13.github.io/keen-code/docs/mcp-skills.htmlThe big advantage is that no server is pre-loaded completely with tool schemas by default. The agent only receives skill frontmatter for the server. If a server is needed, agent loads the full skill file which lists the tools with descriptions. Then agent reads the specific schema file for the particular tool it wants to invoke.The drawback is that each MCP call requires file read operation. But everything is locally saved upon discovery, so it's totally fine.---Apart from the above two, I am exploring and playing with other well-known context optimisation ideas like hashline edits.If the above ideas interest you, please do check it out! Here is the CLI usage guideline: https://mochow13.github.io/keen-code/docs/cli-usage.htmlSince the project is open-source, issues and contributions are more than welcome!

• Source listing
• Website