If you can explain how to make compaction not suck in opencode or Kilo Code, I would love to know how. I am really trying to make use of other harnesses but that's a major sticking point.

▲

9dev a day ago | parent [-]

Never compact. Not automatically, not manually. Instead, let it write ledgers and checklists or handover prompt if necessary, and start fresh sessions as often as possible.

▲

dannyw a day ago | parent | next [-]

What do you do for long-running goals / tasks where you are not interactively prompting?

	▲	9dev a day ago \| parent [-]
		Create a design spec and implementation plan first. If necessary, split that in phases. Then create a ledger that always holds the current status, and instruct the model to update that after it completes a task in the plan, and to append any issues it encounters during the implementation. Then you can let it run, and when it stops, point a fresh session to the ledger to pick up the work from where the previous one left off. You can get more fancy by using something like GitHub issues for coordination too and have multiple sessions create issues and epics and others to work on that in isolated worktrees, but the spec-plan-ledger approach usually works great for small to medium large projects.

▲

verdverm 18 hours ago | parent | prev [-]

second this notion, fresh sessions and markdown are far superior to compaction, which has high likelihood of wrecking the context