Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Reduce repeated Codex uploads and lossless continuation spill traffic

Open
  • Is something wrong?
#7,905 1 comment 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
12/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
bun, typescript
Domain
backend, networking

Research direction

The payload names no source files or tests. Start with the upstream WebSocket continuation path that omits an acknowledged input prefix, and find where idle sockets are retired at three minutes and twenty minutes of age. Then find the continuation storage that keeps cumulative records per response ID. Related work is #7806. Done means longer bounded socket retention with lossless compressed spill envelopes, legacy reads still working, and the isolation and cancellation behaviour kept intact.

Written by the indexing model from the issue text.

Description

enhancement streaming
Area

Streaming; proxy and routing; continuation storage

What are you trying to accomplish?

Keep long-running native Codex sessions from repeatedly uploading the same history, and reduce continuation-cache disk writes without losing replayable context. Ship the behavior upstream so normal package upgrades do not remove locally maintained optimizations.

What prevents this today?

An opt-in upstream WS continuation can already omit an acknowledged, exactly matching input prefix, but the current local extension retires idle sockets after three minutes and by twenty minutes of total age. A later request then uploads the whole history again even when its model, admitted caller, account, thread and route are unchanged.

Local continuation storage also retains cumulative input/output records per response ID. Large repeated records create substantial spill traffic. Merely increasing the cache budget postpones eviction and retains more duplicated data.

What should OpenCodex do?
  • Keep completed, eligible connections warm for a bounded longer interval when incremental upload is enabled, without raising socket-count, exchange-count or retained-prefix memory limits.
  • Continue only from a completed response belonging to the same admitted caller and unchanged history/envelope. Preserve account/credential/route isolation, cancellation and UNKNOWN/failure behavior.
  • Store profitable continuation spill records losslessly in bounded, self-contained compressed envelopes. Preserve legacy reads, original item content, response IDs, thread isolation and decoded-size limits; do not create fragile parent-file dependencies.
  • Include this behavior in the supported release path. A local workaround should refuse an incompatible update before replacement rather than silently start an unpatched package.
Example usage or interface

With codexWsIncrementalUpload: true, an isolated test using real Bun WebSockets sends two otherwise equivalent requests with a simulated four-minute idle gap:

Measurement Original retention Longer bounded retention
First create bytes 278,631 278,631
Second create bytes 278,751 148
Physical connections 2 1
Logical creates 2 2

For storage, a bounded read-only sample of eight existing continuation records encoded from 20,913,583 to 14,245,022 bytes (31.9% fewer physical bytes), with exact decoded-content equality. This is a sample, not a promised production reduction. WS JSON savings are not billing savings, whole-interface traffic, or a comparison against compressed HTTP.

Alternatives or workarounds

Local source patches demonstrate the benefit but can be replaced by package upgrades. Blanket history truncation changes the model's context; retaining more raw snapshots increases resource use. Self-contained compression avoids introducing cross-file recovery dependencies. Older readers cannot decode the new envelopes, so rollback must retain the decoder until those records expire.

Additional context

Related implementation: #7806. The follow-up preserves its admitted-caller scoping and live-config binding fixes. Local validation uses synthetic loopback providers and isolated storage; no production prompts, credentials or account identifiers are included.

Checks
  • I searched existing issues and documentation.
  • This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
  • I removed secrets and personal data.
Dominant language
TypeScript
Stars
16.9k
Forks
1.3k
Avg merge
15h 24m
Merged PRs (30d)
678

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from lidge-jun/opencodex

All issues in lidge-jun/opencodex

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.