I love opencode but it chews through memory on my 64gb MacBook Pro. Can’t have too many long running sessions because the memory use just slowly creeps up.
It’s not about the terminal at all which as you noted accounts for minimal isage. It’s all the internal chat and history and everything else the agent tracks - all of which are smallish (and largish) strings allocated on the heap.
I don’t have the same issues with rust based tuis.
Codex works great in opencode until it gets up to around 200k context. Then it starts doing things like:
me: Can you implement the next thing
OpenCode+Codex: Yep I'll do that next.
<does nothing and returns to prompt>
me: Well?
OpenCode+Codex: <starts implementing>
me: Looks good, let's fix this one issue.
OpenCode+Codex: Sure let's do that.
<does nothing and returns to prompt>
me: <bangs head against wall>
--
I've found the codex cli to be much better in this regard, it doesn't nearly derp out so much at higher token counts.
Opus is still my favourite model (I've found 4.6 specifically gives me the best results in OpenCode), but with all the shenanigans Anthropic is pulling, Codex is a close enough substitute.
If you’re suggesting that the test favors those capable of arranging their thoughts and words before putting pen to paper then.... I’m not sure there’s a problem
- Opus. This was the first model family for me that produced good enough output _and_ could also be correctly steered to correct itself when not good enough. ChatGPT 5 level models are also good enough here but Opus still has an edge I think.
- OpenCode. The UX of OpenCode just seems to fit well with how I work - enough information about what the agent is doing that I can stop it if its getting stupid/doing something wrong, high enough level that I don't need to constantly babysit it. I keep trying Claude Code every now and then but continually get unsatisfactory results even with the same underlying model. Codex works better in this regard.
- Tokenmaxxing. At first I got the standard $30/month plan but would hit session limits in about 30 mins, then I needed to wait a few hours before I could continue so no net benefit in productivity. Then I upgraded to the 5x plan and could go 1-2 hours before hitting sessions limits. This also was no net benefit. Then I upgraded to the 20x plan and was swimming in a sea of tokens. The problem then becomes figuring out how to use them all so you are 'wasting' any of them.
It's the last one that really helped shift the mindset for me. My process now is something like this:
1. use the agent to build and refine an overview of what I'm trying to do and what I'd like to build. This gets saved to the docs folder in the repo.
2. use the agent to build out specific plans to build out what I need. Plans are reasonably high level and describe the what and the why along with important design decisions and measurements of success. Each plan is about enough to implement in a given session. I purposefully do not get it to specify code or tests in the plan as too much specificity in the plan causes the implementing agent to get hooked up on the details rather than trying to find a good solution. These are saved to plans/backlog/NNNNN-plan-name
3. Use the agent to help me review all plans and make sure they are consistent and fit with the overview, and also figure out dependencies between the plans, and which ones can be done in parallel.
4. Use the agent to start implementing - this involves moving the plan to plans/active/... creating a worktree and a branch and working on the feature. I will kick off multiple agents working in parallel where the dependency graph allows it. I review each implemented plan throroughly (I've written my own review tool for this) and iterate until the code meets my standards and the requirements. Then I move the plan to plans/completed/.. merge to main, remove the worktree and then kick off the next agent. Usually I'll be switching between reviewing code, kicking off the next plan in a separate agent, planning out new features, all in parallel.
This is the real productivity enabler. You need to have a backlog of well-scoped work and can then have multiple agents working on different parts of it. Human review is essential if you care about long-term maintainability of the code and ease of future improvement because the AI will still make many flawed decisions.
I tend to avoid other peoples skills. I've found it more productive to build my own as I go if I find myself repeating myself to the agent. Agents will regularly ignore instructions in skills anyway so it's all a bit hit and miss. I try to keep any skills that I make brief and too the point (the more concise, the less likely the agent will skip over it/ignore it).
Overall I've found I've manage to build things more quickly, and the things that I build are now very well documented and explained which helps both agents and humans understand the codebase.
I think OP was rather suggesting that we have a guideline to avoid comments about whether something was written by AI or not.
Without fail, every comment section will have posts by people talking about how something is AI generated. Yeah we get it. It used to be novel to spot this, but now most people are pretty good at spotting it too and/or don't care.
It's about as meaningful as noting an article is written in English.
> This requires using the extremely unintuitive `git rebase --onto A B C` invocation.
Unintuitive yes, and I'm not going to disagree with you on UX, but it's not a particularly difficult thing to learn if you use a rebase centric workflow and this is a command I use daily.
P.S. don't forget to use --update-refs (or add to your .gitconfig) ;-)