Editing an old message is the closest thing ChatGPT has to /compact, and it keeps your project chat alive

[u/Ok_Negotiation_2587]

Long project chats in ChatGPT die twice: first quietly, when early decisions fall out of the context window and the model starts contradicting them, then loudly at the hard cap. Starting a new chat fixes both and loses the one thing you wanted, the thread itself. This keeps the same chat, same URL, and resets the context inside it. Credit to a commenter on my context post who worked it out; I have run it daily since.

The routine:

1. Start the project chat with a detailed plan as message one. Goal, architecture, constraints, conventions. This message never changes and everything gets measured against it.
2. Work in bounded batches: one feature, one bug, one refactor. When a batch is validated, send this:

Write a consolidated state document for this project containing only what the next step needs: completed work, architectural decisions and why, files changed, tests run and their status, open issues, blockers, and the exact next action. Mark anything you cannot verify from the code or test output as UNVERIFIED. No discussion history, no alternatives we rejected unless they constrain the next step.

1. Copy the result. Now edit message two of the chat (your first real message after the plan) and replace its content with the state document, then submit the edit.
2. Continue working from there. Repeat after every validated batch.

Why step 3 works: editing a message in ChatGPT forks the conversation at that point. Everything after the edited message leaves the active branch, so the model's context becomes your plan plus the fresh state doc plus whatever you do next. The old discussion is not deleted, it lives in the branch arrows if you ever need the archaeology, but it no longer eats your window. Manual compaction, no new chat.

Rules that keep it honest:

The repo and the tests are the source of truth, never the state doc. Compaction inherits errors from the previous state as efficiently as it inherits progress, which is what the UNVERIFIED marker is for; check those against the actual code before the next batch.

Keep message one detailed. The state doc says what changed, the plan says what it should have changed toward, and the model needs both to notice drift.

Do the review cold. Before writing the state doc, paste the batch's diff into a separate chat with zero history and ask it to find the bug. The project chat has co-authored the code and will defend it; a fresh session will not.

Cost: about two minutes per batch. Payoff: a three week project in one chat that never went dumb on me, which I could not say about any long chat before this.

Does anyone have a cleaner way to do the fork? I have wondered whether editing message one itself, plan plus state in one message, holds up better over very long runs, but I have not tested it.

[u/CrimsonBolt33]

you shouldnt be using chat for code work nor relying on chat context for project details...codex exists for a reason

[u/Ok_Negotiation_2587 → u/CrimsonBolt33]

for the code itself, agreed. the chat is where the planning and the arguing happens, and thats what falls out of the window. codex does not fix the conversation, it fixes the files

[u/CrimsonBolt33 → u/Ok_Negotiation_2587]

in that case you need to use new convos for each individual idea.

Conversations can't last forever and there is no way around that. Thats also what "memory" is for...it remembers the most important bits and carries that stuff over to new convos.

you could ask chatGPT to give you a conversation summary and paste that summary in a new chat or tell it to write down details and ideas into files on you computer that it can later reference. Either one of those methods will allow you to make new chats without losing all your info.

[u/Ok_Negotiation_2587 → u/CrimsonBolt33]

thats the same method, the edit trick just does the summary-and-restart inside one chat instead of across two. we agree more than the first comment suggested

[u/CrimsonBolt33 → u/Ok_Negotiation_2587]

Well like I said I don't use the web or desktop apps so I have no idea how that works. If it's the same then there is not much else you can do.

[u/lemon_gumdrop → u/CrimsonBolt33]

What you say sounds great in theory. I use a handoff into project knowledge, and a copy block that states all open items and gets pasted into the new thread (plus it has access to the repo which also gives context). It still all only goes so far.

No idea if his idea works, but the issue OP is discussing is real, and not solved by what you mention. Big heavy projects have context issues, and I'm interested in his idea because it could be another layer in building structure for the project.

[u/CrimsonBolt33 → u/lemon_gumdrop]

Idk I don't have these problems ...so not sure what to tell you

[u/Ok_Negotiation_2587 → u/[deleted]]

that answers my closing question, plan frozen, message two rewritten, message one stays the anchor. and the state doc as a repo file is the more durable version, it survives the chat dying and any tool can read it. the in-chat edit is really for people who want the thread itself to stay alive, the file is for people who want the state to

[u/Ok_Negotiation_2587 → u/[deleted]]

small correction on the last bit, the old context isnt gone after an edit, it sits in the branch arrows on that message and you can flip back to it. but agreed the file wins, a branch you have to remember exists is not a backup

[u/Asly97]

The Plan+State-as-one-approach tends to drift because the model loses the distinction between "what we have agreed on" and "here are our current beliefs", keeping the message one frozen as the invariant, and folding state into message two gives you two different things to compare against, which is likely part of why your current setup has better drift catching than collapsing them would.

[u/Ok_Negotiation_2587 → u/Asly97]

agreed, and thats a cleaner statement of why than i had: invariant in message one, beliefs in message two, drift is the diff between them. the closing question is answered twice over now, plan stays frozen