Cascade opens with Cmd/Ctrl+L or a click on its icon, and any text selected in the editor or terminal is automatically included in its context. That is convenient and therefore dangerous: context is gathered on its own, the mode switches with one click, and a rollback is promised by a button - and together this creates the feeling that any action is reversible. The feeling is deceptive.
The naive model is simple: Chat to ask, Code to do, a checkpoint to undo if something goes wrong. In that picture Cascade looks like a sandbox without consequences: try things, and roll back a bad attempt in one move. From this comes the boldness to change code in whole batches without saving intermediate states.
The difference between the modes is documented and not cosmetic. Code mode can create and modify files and call tools; Chat mode is optimized for questions about the code and at best proposes an edit for your acceptance. That is, Chat explains, Code acts - and the cost of a mistake differs between them. A todo shows a multi-step plan that the agent runs itself and updates as it goes, including on the basis of memories. The message queue preserves order: pressing Enter puts a line at the tail of the current turn, pressing it again on an empty box sends immediately, and extra items can be deleted from the queue before sending - a way to add a clarification without interrupting the work.
The naive picture breaks on the word "rollback". A checkpoint is created during a session and helps restore the project's state, but the documentation says plainly: a revert is currently irreversible. You cannot undo the revert itself inside Cascade's history. So a checkpoint is not a full undo but a one-way point of return, and relying on it as a safety net is a category error.
Hence the working technique: the real safety net is Git, not a checkpoint. Before rolling back or launching a large edit in Code mode, save the valuable diff as a separate commit or branch. Then even Cascade's irreversible revert does not carry your work away: it is already fixed in a system that can undo, compare and restore. A checkpoint is useful for quick in-session rollbacks, but the safety boundary is the commit: it is visible outside Cascade and survives closing the session.
Cascade's tools have a documented ceiling: up to 20 calls per prompt, after which continuation is requested with a button, while the Auto-Continue setting finishes what was started on its own, spending additional credits. This is worth knowing not for the number but for the behavior: a long task does not break off silently, but it is not free either, and Auto-Continue removes the pause at the price of a spend that is easy to forget. The continue button itself is not a failure but a routine pause after the ceiling of calls; it gives a moment to decide whether the task is worth the next step before spending credits further.
The wording about quotas is a dated snapshot, not the current price. Cascade's documentation mentions those 20 calls and Auto-Continue from its own era, while the self-serve usage system changed in March 2026. So the old words about limits cannot be translated directly into today's cost: the mechanism is checked against the current usage page, not against text written before the change.
Several Cascades can run at once - this speeds up parallel lines of thought but does not remove file conflicts. If two sessions edit the same files, a race arises, and the last writer overwrites its neighbor. Parallelism here is an interface convenience, not state isolation: separating edits across different files or worktrees is your responsibility, not the agent's. The practical conclusion is to separate parallel Cascades across different files, or better across separate worktrees, in advance, rather than expecting the interface to watch for overlaps on its own.
The cost of inattention is made of two irreversibilities. A revert carries away the uncommitted with no return. Parallel Cascades overwrite each other's edits without warning. Both look like "the agent lost my work", though in fact this is the absence of external fixing: no Git commit before the rollback, no separation of sessions across files. The radius of the error is real code, not a line in a history.
You should check the result not by Cascade's screen but with a different tool: git status and git diff show what actually changed and what is committed. Before a revert - a commit; after a session - a look into Git's history, not only into Cascade's feed. The typical failure is exactly here: "Cascade rolled back too much" - because there was no commit before the rollback; "the edits vanished" - because a second session overwrote the file; "a surprise with the limit" - because Auto-Continue quietly finished the task. Name the mode, fix the state in Git and separate the sessions - and most of these losses will not happen.