Keen Code
A lean Go terminal coding agent with hash-anchored edits and multi-provider switching, built to keep context cost low.
- Source repo
- mochow13/keen-code
- Stars
- ★ 89
- Last updated
- 4d ago
- License
- MIT
- Primary language
- Go
- FA score
- 53/100 · Major gaps
At a glance
- Works with
- Universal · cross-platformChatGPT · OpenAI API · Claude API
- You'll need
- Typical use
- Backend or Go engineers who live in a terminal and want read-edit-test loops without leaving the shell.
- Main limitation
- Deliberately opinionated scope: the author avoids features deemed non-essential, so users wanting richer IDE-grade tooling or a large plugin ecosystem may find it thin.
- Source review
- 53/100 · Major gaps
What does this agent do, and when should you use it?
Keen Code is a terminal-based AI coding agent written in Go, positioned alongside Claude Code and Codex CLI but deliberately minimal and opinionated. It bundles ten core coding tools, provider switching across Anthropic, OpenAI, Codex OAuth, Gemini, DeepSeek, Kimi, GLM, MiniMax, OpenCode Go, Yolo-Auto and Amazon Bedrock, MCP server integration, a skills system, parallel subagent delegation and configurable tool-history retention. Its signature mechanic is hashline editing: read_file prefixes each line with an N:HASH| anchor and edit_file applies a multi-op array atomically against one snapshot, rejecting stale anchors. Sessions, memory, compaction, a FileGuard-based permission model and a headless keen run mode are all documented, making it a fit for engineers who want to keep control of both models and workflow.
Running keen opens an interactive TUI session in the current directory. The agent reads and searches files via read_file, glob and grep, writes changes via write_file and edit_file, executes shell commands through bash, fetches URLs with web_fetch (HTML converted to Markdown), asks clarifying questions with ask_user, fans up to 10 bounded tasks out to subagents defined in .agents/agents/ via delegate_task, and invokes connected MCP tools through call_mcp_tool. On the model side it supports Anthropic, OpenAI, Codex via ChatGPT OAuth, Gemini, DeepSeek, Kimi, GLM, MiniMax, OpenCode Go, Yolo-Auto and Amazon Bedrock, switchable with /model. Sessions persist and resume, and context can be compacted with /compact. Across turns the default is a compact TurnMemory summary; /tool-history full retains full tool outputs for the current session. A FileGuard permission layer lets working-directory paths pass, prompts on sensitive paths, and denies system or .gitignore paths.
- Backend or Go engineers who live in a terminal and want read-edit-test loops without leaving the shell.
- Teams that switch models per task, using
/modelto move between Anthropic, OpenAI, Gemini or Bedrock within one session. - Platform teams with internal tool services that want them exposed to the agent through MCP with on-demand schema loading.
- Users who need to parallelize work by delegating bounded tasks to subagents with their own provider, model and permissions.
- Teams embedding a coding agent into scripts or CI, using
keen run "<prompt>"with--format jsonfor headless calls. - Developers who care about edit correctness and want changes applied atomically against line-hash anchors rather than drifted content.
How do you install or deploy this agent?
Script install (to /usr/local/bin if writable, otherwise $HOME/.local/bin):
curl -fsSL https://raw.githubusercontent.com/mochow13/keen-code/main/scripts/install.sh | bashPin a specific version:
curl -fsSL https://raw.githubusercontent.com/mochow13/keen-code/main/scripts/install.sh | bash -s -- -v v0.16.1Or install globally with npm:
npm install -g keen-codeRun without a global install:
npx keen-code --versionVerify the install:
keen --version
which keenHow do you use this agent?
Start an interactive session in your project:
keenUse custom model and MCP configuration files:
keen --model-config ./model-config.json --mcp-config ./mcp-config.jsonThese replace the defaults at ~/.keen/configs.json and ~/.keen/mcp/configs.json; missing or invalid custom files fail startup without falling back. Headless mode:
keen run --format json --model-config ./model-config.json "Explain this project"In-session commands include /model to switch providers, /thinking to set reasoning effort, /mcp to connect and inspect MCP servers, /skills for skills, /memory for persistent memory, /compact for compaction, /tool-history full|none to toggle tool retention, /allow-permission for always-allow tools and /emptyq to clear the queue. Choosing ChatGPT/Codex opens a browser sign-in flow that stores OAuth credentials in ~/.keen/auth.json.
What are this agent's strengths and limitations?
- Hash-anchored editing: read_file emits N:HASH| anchors and edit_file applies a multi-op array atomically against one file snapshot, so stale anchors are rejected instead of silently editing drifted content.
- Broad provider coverage — Anthropic, OpenAI, Codex OAuth, Gemini, DeepSeek, Kimi, GLM, MiniMax, OpenCode Go, Yolo-Auto and Amazon Bedrock — all switchable at runtime with
/model. - Each connected MCP server is auto-converted into an
mcp:<server>skill with a tool table and JSON schemas, keeping tool discovery prompt-efficient without a dedicated tool-search mechanism. - Cross-turn context defaults to lean TurnMemory summaries, with
/tool-history fullavailable when exact earlier outputs matter, so token cost is an explicit user choice. - Headless
keen runwith--format json,--completion-signaland--sessionmakes it scriptable for CI and automation pipelines. - The whole codebase was written by AI agents, with prompts and specs archived in .ai-interactions, giving a public case study of agent-driven development.
- Deliberately opinionated scope: the author avoids features deemed non-essential, so users wanting richer IDE-grade tooling or a large plugin ecosystem may find it thin.
- Full tool outputs are not retained by default, so older observations must be re-read or re-searched, adding latency and extra calls on long tasks.
- Requires your own model provider API key or a ChatGPT OAuth sign-in; environments without outbound network access cannot operate.
- A missing or invalid
--model-config/--mcp-configfile aborts startup with no fallback to the defaults. - As a fast-moving individual project, breaking changes are plausible — for example the former
--configflag was renamed to--model-config.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Keen Code This agent | 53 · Major gaps | — | ★ 89 | 4d ago | Go | ChatGPT · OpenAI API · Claude API |
| zerostack | 57 · Major gaps | CLIFree + model costs | ★ 1.7k | 3d ago | Rust | OpenAI API · Claude API |
| agentty | 44 · Major gaps | CLIFree + model costs | ★ 613 | 1d ago | C++ | OpenAI API · Claude API |
| Oh My Pi | 54 · Major gaps | CLIFree + model costs | ★ 38k | today | TypeScript | Codex · OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
The permission docs are substantive: the Guard denies system dirs, .gitignore'd files and $HOME dotfiles by default, writes always require approval, dangerous bash commands force a prompt, and plan mode strips write tools — supporting least privilege and user confirmation (2 each). However yolo mode and /allow-permission can bypass all prompts including dangerous commands, and no rollback/undo mechanism is documented, so external_effects and rollback score 1. Sensitive data: OAuth tokens are stored 0600 in ~/.keen/auth.json with namespacing, but the docs admit OAuth error strings are not token-redacted, capping this at 2. Dependency security rests only on go.mod plus a weekly CodeQL workflow; no lockfile audit, SBOM or vulnerability-response notes, so 1. Source attribution mentions inspiration from pi-hashline-edit but is not systematic, and publisher identity is unverified, so 1.
Internal consistency is good: permission states, the command table, and the MCP OAuth state machine and failure states agree with each other (2). Failure messages are specific — auth_required/auth_failed/disconnected with recovery steps, and the --completion-signal exit-code contract (2). Dependency availability evidence is weak: go.mod declares go 1.26.0 / toolchain go1.26.10 and pins several pseudo-versions with future timestamps that static review cannot confirm are fetchable, with no vendoring or checksum discussion, so 1.
Audience and scenarios are clear (terminal coding agent, multi-provider, headless mode, subagents); capability boundaries are well documented (plan/yolo modes, read-only adversary tools, tool-less /btw); trigger precision has explicit rules (slash commands, @ file mentions, queue cap of 5, router thresholds) — 2 each. Environment fit covers only Unix-style paths and /usr/local/bin installs with no Windows guidance, and the install path is a curl|bash pipe, so 1.
README has a clear table of contents and docs/ is organized by topic; install notes cover both script and npm (2 each). Naming stability is weakened by a breaking rename: --config became --model-config and the old flag is rejected, with only a passing migration note, so 1. Examples are plentiful but there is no FAQ or dedicated known-limitations section, so known_limitations is 1. LICENSE is full MIT text (2). CHANGELOG and ROADMAP appear only as links with no content evidence, so versioning_changelog is 1. Maintenance responsibility is unclear given the unverified publisher and only a referenced CONTRIBUTING, so 1.
Output usability shows concrete design: atomic hashline-anchored edits, TurnMemory context compaction, --format json headless output, /usage accounting (2). Marginal value over existing coding agents lies in context efficiency and skill-driven MCP discovery (2). Cost-benefit tradeoffs are explicitly reasoned (lean default context for lower token cost, opt-in /tool-history full) but lack quantified benchmarks, so 2.
Many README claims trace to specific docs and code paths (internal/mcp/oauth.go, internal/filesystem/guard.go), giving claim_traceability 1 since most are self-description rather than verifiable artifacts. Cross-source corroboration is limited: README, docs and go.mod agree on some features, but no test files or CI results are included to cross-check, so 1. Fact/inference separation is partial — supported vs unsupported OAuth features are listed — but some performance and security conclusions are asserted without support, so 1.
- Yolo mode and /allow-permission skip all confirmations including dangerous bash commands, relying solely on the Guard; avoid in production.
- Installation pipes a remote script via curl | bash and the publisher is unverified; review scripts/install.sh and pin a version first.
- go.mod declares go 1.26.0 and several pseudo-version dependencies with future timestamps whose real availability and safety cannot be confirmed statically.
- The docs admit OAuth error strings are not redacted by token value, so logs or terminal output may leak sensitive data.
- The --config to --model-config rename is breaking; older scripts will fail at startup.
- No rollback/undo mechanism is documented, so executed writes and dangerous commands have no built-in recovery path.