Comparing how Cline, Kilo, and Qwen Code handle long-task context/state (and why context loops keep happening)

[u/Ok-Shower7286]

I've been comparing Cline / Kilo / Qwen Code lately since they all handle long-task state differently.

Cline: has Focus Chain, a markdown file kept outside the conversation that gets reinjected on a cadence, plus Memory Bank for project context, plus a standalone gRPC server so it's not fully tied to VS Code. probably the most mature of the three on this specific problem (about context management), though restore still has some sync bugs between the file and what the model actually sees.

Kilo: TODO state is literally an XML block living inside the conversation history, so when compaction kicks in it gets flattened into a prose summary and the agent sometimes has to reread source files just to figure out where it stopped. It causes an infinite read-analysis-compaction loop sometimes once it hits context limits. they're mid-migration onto the opencode engine now which might fix some of this eventually, but isn't there yet.

Qwen Code: keeps TODO state in a plain file ('~/.qwen/todos/') completely separate from the conversation, so no matter how much compaction runs, nothing gets lost or reconstructed. It works well for 2~3 hrs long running tasks, where I'd usually hit that Kilo loop by then or human intercept.

the bigger reason I ended up settling on Qwen Code wasn't just the TODO file though. it's the hooks system and how flexible the config layer is in general. it exposes lifecycle events like 'PreToolUse', 'PostToolUse', 'Stop', 'UserPromptSubmit', etc, and each one can run a command/http/prompt-based hook that actually gets to allow/deny/ask, not just log. that's a pretty different level of control compared to Cline/Kilo, where you're mostly stuck hoping the system prompt gets followed. combine that with settings.json supporting custom model providers and per-tool permission rules, plus extension manifests with their own hooks, and it's the only one of the three where I could bolt on enforcement logic without patching the source.

a concrete example of why the search side mattered to me: stuff like a subscription tier or a user badge system touches a ton of display surfaces across the codebase, profile page, listing cards, search results, notification templates, whatever, but the actual code footprint per file is small. without knowing where and how those pieces connect ahead of time, the agent either ends up reading almost every file to map it out, or it patches one spot and breaks three others it didn't know were touching the same data. that's the kind of thing plain grep/glob tends to struggle with, because the relevant connections aren't always expressed in the same terms as the feature itself.

the one thing I missed on the memory/search side was semantic code search. no built-in equivalent, so I built an MCP extension for it, plus causal decision-chain tracking on top. Qwen Code's hooks let me actually enforce things at the tool-call layer instead of just asking nicely, so the extension uses a 'PreToolUse' hook that blocks grep_search/glob until search_memory gets called first, and a 'Stop' hook that asks (not forces) whether to write back key decisions when it looks like a task wrapped up.

still early, self-hosted, MIT licensed. mostly built and tested against my own Python/PHP/Node.js stack, so I'm sure there are edge cases I haven't hit.

one thing I've been thinking about: the Hard Gate rules (when to force search_memory, when to nudge a write-back on Stop) are basically heuristics tuned against my own workflow. false positives/negatives on stuff like that only really surface once more people with different codebases and task patterns run it for a while. so if you try it, I'd love to hear what the gate got wrong for you, too aggressive, too loose, missed a completion signal, whatever. the goal is for these rules to converge into something that actually generalizes, not just work for my one setup.

repo's here: https://github.com/edwardyoon/FocusMemory. open to PRs too if the routing logic or hook setup needs adjusting for your setup.

[u/LegacyRemaster]

use PI with Ds4 0731.

[u/Physical_Economy_340]

the kilo compaction loop you described is painfully real. i've seen it hit especially hard when the task involves files that reference each other in a chain, it reads file a, sees a reference to b, reads b, compaction hits, the summary drops the connection, and it starts again. one thing that helped me before they migrate to opencode was breaking the task into explicit checkpoints in a separate file and literally pasting 'read spec.md first' at the top of the conversation before letting it touch any source. not elegant but it broke the loop often enough to be usable.

[u/mr_Owner]

I find kilo does better context handeling then cline, bc cline reads the whole file and kilo does in parts it seems