SWEGCA-VRS-FCC: a Codex CLI fork replacing compaction with VRS request assembly — feedback welcome

[raspie10032]

Hi, I'm building SWEGCA-VRS-FCC (Full Context Continuity), an experimental Linux fork of Codex CLI, and I'd appreciate technical feedback.

The fork removes the normal compaction paths and uses an in-process C++ library, libvrs, to assemble model requests from the original session records.

Preserving those records does not mean the entire conversation fits into every model request. The context window still applies. Past user messages and the ongoing turn are required input; if that required input exceeds the budget, the turn stops with an error.

I'd particularly appreciate feedback on:

• Whether the request assembly and token-budget rules miss important edge cases.
• Whether retries, tool interactions, and other model-input paths preserve the expected Codex behavior.
• What independent tests would best evaluate continuity during long coding sessions.

The README describes the current implementation, maintainer-run checks, and known limitations. One review limitation: the SWEGCA core source is not included; its compiled objects are bundled in the prebuilt library.

Repository:
https://github.com/raspie10032/CODEX-CLI-SWEGCA-VRS-FCC

Code review, reproducible failures, and suggestions for better evaluation are welcome.

[bomtobe-hgkim]

I work with BOMTOBE on Orke, a desktop workspace for Codex. I haven't tested this fork, but one synthetic continuity case seems useful: put a tool call just before the budget boundary, return a long tool result, then trigger a retry. Does the next request preserve the call/result pair and pending assistant instruction exactly once? That could reveal duplicate or stale context without relying on subjective long-session scores.

[raspie10032]

Thank you for taking the time to suggest this, @bomtobe-hgkim! It gave me a concrete and useful case to check.

I tried a scoped version against the published Linux fcc-v1.1.1 executable, using a localhost mock Responses endpoint and real local shell tools. I ran eight scenarios twice in fresh sessions: HTTP errors, interrupted streams, repeated failures, two tool calls in one response, a mixed Unicode result, a partially streamed assistant message, and an oversized result.

The initial request was around 90% of a synthetic 40,000-token allowance under FCC's byte-based estimator; the successful post-tool requests were around 95%. Across these runs, each call/result pair and the assistant continuation appeared exactly once per request, the full tool outputs were preserved, and the tools were not re-executed on retry. The captured input arrays were identical across retries, including after the unfinished assistant text. The oversized-result cases stopped with an explicit context-window error before sending another request.

One detail I want to be clear about: I represented the pending instruction as an assistant commentary message before the tool call. Queued user or agent messages still need separate coverage. These were local synthetic HTTP tests, so I wouldn't generalize the results to live-provider retries or long-session continuity yet.

Thanks again for the thoughtful suggestion. It helped me make the checks more concrete, and I appreciate you taking a look!