A proxy that quietly continues a coding model's cut-off thinking

A proxy built around one specific number

This is a small proxy server that sits between a coding agent and an upstream Responses-API endpoint, most commonly Codex, and solves one narrowly defined problem: a known reasoning-truncation pattern where the upstream response cuts off mid-thought. The middleware detects a specific numeric fingerprint in the token-usage field returned with each response, matching the formula 518 times some tier number minus two, and when it sees that exact pattern, it silently asks the model to continue thinking rather than handing the agent a truncated result.

The architecture is a single hop: the coding agent points at the proxy instead of the real endpoint, and the proxy talks to the real endpoint on its behalf. Streamed reasoning events pass through live as they arrive. The tentative final output, the actual message or function call, is held back rather than forwarded immediately, because whether that output is genuinely final or an artefact of a truncated round is exactly the thing the token-count fingerprint is checking. Only once the terminal event of a round arrives does the proxy know which of those two situations it is looking at.

This is a tool built by someone who noticed a specific, reproducible pattern in a production API's behaviour and wrote code against that exact pattern, rather than a general-purpose retry wrapper applied broadly and hoped for the best.

The disclaimer states the trade plainly, and that is worth taking seriously

Immediately under the project's one-line description sits a disclaimer that is unusually direct for a piece of open-source middleware: the project explicitly bypasses observed reasoning-truncation behaviour, and if using it is considered abusive, violates service terms, increases costs unexpectedly, or causes any other adverse consequence, the user bears sole responsibility.

That sentence deserves to be read as a serious statement rather than boilerplate. Working around an undocumented cutoff in a paid API's behaviour sits in a genuinely different category from fixing a bug in your own code, because the cutoff may exist for a reason the provider has not published, whether that reason is cost control, safety, or infrastructure limits, and continuing past it changes how much of the underlying service is actually consumed per request. The project does not pretend otherwise, and stating the risk plainly rather than burying it is the correct way to publish a tool like this.

The practical consequence for anyone considering it is to read that disclaimer as a real decision point rather than a formality to scroll past, and to understand that continuing a truncated reasoning round means paying for more of the underlying model's work than a single request would otherwise have consumed, which the response metadata described below makes visible rather than hiding.

Buffer, detect, decide: the actual mechanics of one round

The continuation logic runs in a fixed sequence for every upstream round. Reasoning events are forwarded to the agent live and rewritten with corrected sequence numbers, since they are safe to show regardless of how the round eventually resolves. Message and function-call events, the actual output the agent would act on, are buffered rather than forwarded, because the whole point is that they might turn out to be an artefact of truncation rather than a genuine answer.

When the terminal event of that round arrives, the proxy reads the reported reasoning-token count. If it matches the truncation fingerprint, sits within a configured tier window, carries encrypted reasoning content, and safety caps still allow continuing, the buffered tentative output is discarded entirely, the round's reasoning is appended to the next request's input along with a continuation marker, and a new upstream round opens automatically with no user or agent intervention. If none of that applies, the buffered output is flushed as the genuine final answer and one reconstructed terminal response is emitted.

The default continuation mechanism is a hidden assistant message with a specific message phase, functioning as an unobtrusive nudge telling the model to keep going; a legacy alternative using a synthetic paired tool call is also available for compatibility. Either way, the downstream agent only ever sees what looks like a single, ordinary response, with the hidden rounds folded away and their details relegated to metadata rather than exposed as separate turns.

A security guard that closes an obvious credential leak

Configuration supports pointing the proxy at an arbitrary Responses-compatible endpoint per request, by supplying a header that overrides the configured upstream URL, which is a genuinely useful piece of flexibility for anyone wanting to run the same proxy against more than one backend. It is also exactly the kind of flexibility that, done carelessly, becomes a credential-leaking feature, because a request-supplied destination combined with server-side credential injection would happily send the server's own stored token to whatever URL the caller named.

The README is explicit that this exact risk is guarded against: if a request supplies that override header, and the currently configured authentication mode would inject the server's stored credentials for that request, the request is rejected outright with an error rather than the credentials being forwarded anywhere. Using a per-request upstream override safely requires the caller to supply their own authorization header and a mode that only passes through caller-supplied credentials rather than injecting the server's own.

That is the correct fix for the correct failure mode, and it is worth noting because the alternative, quietly injecting stored credentials into whatever destination a caller names, is precisely the kind of subtle server-side vulnerability that is easy to introduce accidentally when adding a convenience feature and easy to miss in review until it has already shipped.

Keeping a folded stream alive without disturbing it

Because the proxy holds output back while deciding whether a round was truncated, a downstream connection can sit idle for the whole duration of a buffered round, and idle connections are exactly what timeout logic on either end is designed to close. The optional fix is a heartbeat: a no-op streaming event sent periodically while folding is in progress, which the README notes is a Codex-specific extension rather than a documented part of the standard Responses API streaming format.

The detail worth noting is how carefully the heartbeat is kept from interfering with the real event stream. It deliberately omits the sequence number field that real events carry, so it cannot disturb the ordering the agent relies on to reconstruct the conversation, and Codex is described as parsing the event just enough to reset its own idle timer before safely ignoring the event type it does not otherwise recognise. Passthrough traffic, meaning any request the proxy is not folding at all, receives no locally generated heartbeats and stays byte-for-byte transparent, which is the right default since there is no idle period to protect against in a request the proxy never buffers in the first place.

That combination, a real fix for a real idle-timeout risk that avoids touching anything the downstream agent actually depends on, is a small but well-executed piece of protocol engineering.

Running it, and what to check before you do

Setup is short. Install dependencies, copy the example configuration, and run the server:

uv sync
cp config.example.toml config.toml
uv run python run.py

The example configuration listens locally and accepts requests at a single path, and authentication defaults to passthrough mode, meaning the proxy forwards whatever authorization the caller already supplied rather than injecting anything of its own. Three auth modes are available in total, passthrough, inject, and a hybrid that falls back to injected credentials only when the caller supplied none, and the README states plainly that stored tokens in the configuration file, along with two named runtime files, should never be committed to version control.

The project is MIT licensed, reports 314 stars, 30 forks and two open issues, and the last push was 2026-07-13, so it addresses a specific and fairly recent upstream behaviour rather than a long-settled one, which also means the fingerprint it detects could stop matching if the upstream provider changes how it truncates.

Before running it, three steps in order. Read the disclaimer as a real decision rather than boilerplate, and decide whether working around an undocumented truncation pattern is something you are comfortable doing against your account and its terms of service. Watch the response metadata's billed-usage field once you are running it, since continuation means paying for more of the upstream model's work per logical request than a single round would have cost. And keep your configuration file's tokens out of version control exactly as the README instructs, particularly if you adopt the inject or hybrid authentication modes.

Editorial conclusion

This proxy fits a Codex or Responses-API user who has run into reasoning cut off mid-round and wants an automated fix rather than manually noticing and retrying, and its detection logic, a precise numeric fingerprint checked against a buffered tentative output, is a genuinely careful piece of engineering rather than a blunt retry wrapper. Its own disclaimer is unusually direct that this works around undocumented upstream behaviour at the user's own risk, and that statement deserves to be read as a real decision rather than boilerplate before adopting the tool. Watch the billed-usage metadata once running, since a continued round costs more of the upstream model's work than a single request would, keep configuration tokens out of version control, and expect the detection fingerprint itself to need revisiting if the upstream provider ever changes how it truncates.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. neteroster/CodexCont on GitHub
4. README