mksglu

OpenAI published "Harness Engineering" in February 2026. The thesis: engineers don't write code anymore. They design environments, specify intent, and build feedback loops. Agents do the rest. Codex proved the concept. Symphony showed the architecture in Elixir/OTP. I wanted the same thing with Claude Code.

So I built Hatice.

OpenAI published "Harness Engineering" in February 2026. The thesis: engineers don't write code anymore. They design environments, specify intent, and build feedback loops. Agents do the rest.

Codex proved the concept. Symphony showed the architecture in Elixir/OTP. I wanted the same thing with Claude Code.

So I built Hatice.

Six days ago I posted a write-up on Hacker News explaining how Context Mode reduces Claude Code's context consumption by 98%. I expected a handful of comments. I got 565 points, 107 comments, and the kind of feedback that makes you stay up until 4 AM shipping features.

What's new:

  - Five platform adapters: Claude Code, Gemini CLI, VS Code Copilot, OpenCode, Codex CLI
  - Session Continuity: survives context compactions, restores state automatically (~3h sessions vs ~30 min)
  - ctx_batch_execute: one call replaces 30+ individual commands
  - Three-layer fuzzy search: Porter stemming, trigram substring, Levenshtein
  - FTS5 deduplication, background mode, SSL cert auto-detection

Breaking: repo renamed claude-context-mode → context-mode, tools prefixed with ctx_.

  Install (Claude Code): /install context-mode
  Install (all platforms): npm install -g context-mode

  GitHub: https://github.com/mksglu/context-mode
  Release notes: https://github.com/mksglu/context-mode/releases/tag/v1.0.0

Four adapters are in beta — PRs welcome. The codebase is designed for Agentic Engineering: point your coding agent at it and let it propose fixes.

Thank you to everyone who commented, starred, and opened issues on the original post. You made this release happen.

Thanks, really appreciate hearing that! Glad it's working well for your team.

Yeah it's basically pre-compaction, you're right. The key difference is nothing gets thrown away. The full output sits in a searchable FTS5 index, so if the model realizes it needs some detail it missed in the summary, it can search for it. It's less "decide what's relevant upfront" and more "give me the summary now, let me come back for specifics later."

That's the theory and it does hold up in practice. When context is 70% raw logs and snapshots, the model starts losing track of the actual task. We haven't run formal benchmarks on answer quality yet, mostly focused on measuring token savings. But anecdotally the biggest win is sessions lasting longer before compaction kicks in, which means the model keeps its full conversation history and makes fewer mistakes from lost context.

That's a fair point and honestly the ideal approach. But in practice most people don't hand-curate their MCP server list per task. They install 5-6 servers and suddenly have 80 tools loaded by default. Context-mode doesn't solve the tool definition bloat, that's the input side problem. It handles the output side, when those tools actually run and dump data back. Even with a focused set of tools, a single Playwright snapshot or git log can burn 50k tokens. That's what gets sandboxed.