A session that survives running out of room.
Long agentic sessions accumulate tool calls, file contents, and command output until the model's context window fills. Kryex's context engine is built to make that failure structurally rare, and — when it does happen — transparent and correctable rather than invisible. Four real capabilities, each a case study below: not an eight-line paragraph, the actual problem, how Kryex solves it, and what it means in practice.
The problem in practice
Once a model's context window fills, either the call fails outright, or — with a naive approach — the oldest turns get silently dropped, often taking the very instruction the developer gave at the start of the task with them. Every one of the capabilities below exists to make that specific failure mode either not happen, or be visibly recoverable when it does.
Context Finder — no guessed limits, no arbitrary ceiling
Every AI coding agent has to answer one question: how much context can this model actually hold?
Almost every agent tool answers this with a single hardcoded number — a generic “200K context limit” applied to every model, regardless of what that model actually supports. That number is either wrong or wasteful: a model that genuinely supports 300K or 350K tokens gets throttled at 200K for no reason, losing real capacity the developer is paying for and the model can actually use. A model that's weaker than assumed fails unexpectedly once the real ceiling is hit, because the agent never found out where that ceiling actually was.
Kryex doesn't set a fixed limit and doesn't guess. It resolves the effective context window for whichever model is active through a layered strategy: an explicit administrator- or user-set override takes precedence if one exists; otherwise Kryex uses what it has actually calibrated from real observed failures for that specific model (see Discovery mode below — the model itself tells Kryex where its real ceiling is, the first time it's pushed there); and only when neither is available does it fall back to a conservative static default. The ceiling is discovered, not assumed.
Two developers on the same team use different models — one on a 200K-context model, one on a 350K-context model Kryex hasn't seen before. Kryex doesn't cap the second developer's model at 200K just because that's a common industry number. It lets that session run until it either observes the model's real behavior or has an explicit calibration for it, and compresses at roughly 70% of the model's actual window from then on — not an arbitrary shared ceiling applied to every model regardless of what it can really do.
No developer is throttled below what their model can actually do, and no session fails on a model whose real limit was never verified. The ceiling reflects the model, not a guess about the model.
How the ceiling gets used: three compression modes
Once Kryex knows (or is finding out) a model's real ceiling, it runs a calibrated, three-mode compression policy rather than compressing on a fixed schedule.
Discovery mode
For a model Kryex hasn't yet observed the real failure point of, it doesn't pre-emptively compress at all — it lets the conversation grow until the model itself reports a genuine token-limit error. That real failure is the calibration signal for every session after it.
Calibrated mode
Once a real ceiling has been observed, compression triggers pre-emptively at roughly 70% of that model's effective context window — comfortably before the hard limit, so the developer never sees the failure at all in normal use.
Force mode
If a call fails anyway, the emergency-recovery path forces a compression pass immediately, escalating aggressiveness on repeated failures — half the recent conversation kept verbatim, then a quarter, then a tenth — so one insufficiently aggressive pass doesn't fail the same way twice.
A hard kill switch (KRYEX_DISABLE_COMPRESSION) exists for administrators who want this off entirely. When compression runs, it never cuts mid-tool-cycle — the cutoff snaps to a clean conversational boundary so a tool call is never separated from its result — and it auto-pins the developer's most recent instruction before compressing, so the agent never loses sight of what it's currently doing.
Editable working memory
The agent's summary of its own past work can be wrong — and normally, nobody can fix that
Once a long session gets compressed, the agent's understanding of everything before the cutoff is only as good as its own summary of it. If that summary drifted from what actually happened or what actually matters, every later step in the session inherits that mistake — and in most agent tools, there's no way to correct it. The agent just keeps silently misremembering its own earlier work.
The compressed summary in Kryex isn't a black box. It's stored, versioned per compression round, and editable by the developer directly. A full compression history is kept per session, so a developer can inspect exactly what any given round condensed, and correct it if the agent got it wrong.
An agent compresses a session and summarizes 'refactored the auth module to use JWT' — but the actual decision was to keep JWT for one legacy endpoint and switch everything else to session cookies. The developer edits the summary directly. Every subsequent step in the session runs against the corrected version, not the agent's original (wrong) one.
The single most common failure mode in long-running agent sessions — the agent quietly misremembering its own earlier work — has an actual fix, not just a hope that the summary was right.
Cross-model context migration
Switching models mid-task shouldn't mean starting over
A developer mid-session realizes a cheaper, faster, or more capable model would serve the rest of the task better — but in most tools, changing the active model means losing the conversation, because the new model's context window doesn't match the old one, and there's no mechanism to reconcile that.
A developer can swap the active model mid-session — for example, moving from a 200K-context model to one with a 32K window — and the session survives the swap. The context engine resizes the compression to fit the new model's actual window rather than failing outright or silently truncating, and anything the developer pinned stays intact through the transition.
A developer starts a large refactor on a high-context model to explore the whole codebase, then switches to a smaller, cheaper model to grind through the mechanical part of the change once the plan is set. The session — and everything pinned in it — carries over.
The model becomes a configuration choice made per-task, not a one-way door a developer is locked into because of accumulated conversation history. This is called out in the product's own competitive positioning as a capability that exists nowhere else in the market today.
All four of these work together: Context Finder decides the real ceiling, the three compression modes manage it, editable memory keeps what survives accurate, and cross-model migration means none of it is lost if the model itself changes mid-session.