Jcode 0.99: Account Failover and Idle Session Hibernation

Jcode 0.99, released on October 19, extends account failover to Desktop and SDK clients and adds idle-session hibernation. For developers keeping several coding sessions open, the changes address two familiar interruptions: a provider usage limit stopping a turn and inactive sessions continuing to occupy memory.

The release also improves large-session reloads by showing the local transcript immediately and transferring only new history. The important details are in the boundaries: failover uses approved accounts, and default hibernation drops rebuildable caches while retaining the daemon's canonical conversation.

Automatic failover uses an approved account pool

The server-side router handles qualifying usage-limit and rate-limit failures for clients that opt into server failover. The source account must belong to the auto-switch pool, the destination must be approved for that pool and cross-provider failover must be in its automatic countdown mode.

This extends a workflow already available through the terminal client to Desktop and SDK clients that cannot run the terminal's client-side countdown. It does not silently make every saved account a fallback destination.

The server tries at most three alternative accounts after the initial failure. It also stops automatic retry once the model has produced a partial reply, rather than asking another account to start the same turn again. Generic connection errors and context-length failures are not treated as reasons to switch accounts through this path.

The practical setup question is which accounts and providers should be eligible. A fallback route can have different billing and data-handling terms, so a team should choose that pool deliberately. The feature helps use already-authorized capacity; it does not add quota or remove provider limits.

Default hibernation keeps the conversation in memory

The session configuration defaults to hibernating after 30 minutes without work or interaction. Setting the idle interval to zero disables the feature. Its default terminal mode is caches, which releases rebuildable rendering data for a lightweight wake.

On the daemon side, the hibernation implementation releases derived provider-message caches and tool indexes. It retains the canonical transcript, frozen prompts and tools, undo state, and provider and hook state.

That distinction changes the expected savings. A long conversation can still occupy memory after hibernation because its underlying history remains live. The intended benefit is removing reproducible allocations without having to reload the entire session from disk before another interaction.

The code also avoids hibernating while a turn, live tool, queued alert or compaction operation needs the session. These checks matter for agents with background activity: a quiet interface is not always an idle session.

Deeper terminal modes trade continuity for memory

Two optional terminal modes go further. transcript drops the terminal client's in-memory transcript and retrieves it from the server when waking. Local-only notices and the exact scroll position are not retained.

The exit mode terminates the client process and leaves a small waiter to resume the session on the next keypress. The configuration describes a wake of about a second, although that is not a measured guarantee for every machine or conversation.

These modes affect the terminal client and should not be read as evidence that the daemon discards all session history. Start with cache-only hibernation, inspect the reported memory change, then choose a deeper mode only if its tradeoff fits how you resume work.

Check the package before upgrading

Release packages cover Linux, Intel and Apple Silicon macOS, Windows and FreeBSD, with specific architectures listed on the release page. The Windows executables are unsigned, and the project explicitly warns that publisher or SmartScreen warnings may appear.

For an upgrade trial, use an existing long session to check transcript continuity and memory reporting, then test a permitted fallback route with a controlled usage-limit failure. Those checks establish whether the reliability improvements work in your setup without assuming every session saves the same amount of RAM or every failed request can be retried.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help developer-tool founders explain reliability improvements, technical tradeoffs and product launches in clear stories that support adoption.

Book a 30-minute call.