CrewAI 1.14.2, released April 17, 2026, extends the checkpoint TUI introduced in 1.14.1 (April 8) with resume/diff/prune commands, fork support, lineage tracking, and Flow API integration, completing an architecture move that replaces bespoke checkpoint stores with framework primitives. For teams running expensive multi-step agent pipelines, the practical change is that mid-run failures no longer require full restarts, and intermediate output variants can be forked and compared without re-executing prior steps.
What CrewAI 1.14.2 Ships
The headline additions to the TUI are resume/diff/prune commands, fork support with lineage tracking, and Flow API integration. The interface auto-detects JSON or SQLite checkpoint stores and renders them as a navigable tree. According to [CrewAI’s checkpointing documentation]1, the left panel groups checkpoints by branch with forks nested under their divergence point; the right panel surfaces metadata, entity state, and task progress. Users can resume from any checkpoint or fork a new branch interactively from within the interface.
[The 1.14.2 release notes]2 also add enriched LLM token accounting, breaking out reasoning tokens and cache-creation tokens separately, which is useful for pipelines that use extended-thinking models where cost attribution has previously been opaque. The from_checkpoint parameter on Agent.kickoff exposes the same checkpoint-based resume programmatically, separate from the TUI.
What 1.14.3 Adds
[CrewAI 1.14.3]3, released April 24, extends checkpoint and fork capabilities to standalone agents; previously the feature was crew-scoped. The same release adds Daytona sandbox tools, Bedrock V4 support, e2b support, and lifecycle events for checkpoint operations. According to the 1.14.3 release notes, MCP SDK cold starts were optimized by approximately 29%3.
How the Checkpoint Architecture Works
[CrewAI’s checkpointing documentation]1 describes two storage backends: JsonProvider, which writes human-readable JSON files, and SqliteProvider, which uses WAL journal mode for concurrent reads. CheckpointConfig controls storage location, trigger events, retention limits, and restore points; child entities inherit configuration from their parent unless overridden.
Checkpoint writes are best-effort. A write failure is logged but does not interrupt execution: the right default for a long-running pipeline, but it means you can arrive at a TUI session where expected checkpoints are missing without an explicit error trace pointing you there.
Fork, Edit, and Re-run
Forking creates a new execution branch with a unique lineage ID, so checkpoints from different branches don’t collide in the store. Within the TUI, selected checkpoints expose editable input fields and editable task outputs. Changing a task output and forking from that point invalidates subsequent tasks, which are re-executed with the modified context; prior steps are not touched.
A team debugging a pipeline that failed on task 8 of 12 can edit task 5’s output, fork, and observe the downstream cascade without recomputing tasks 1 through 4. The same mechanism supports hypothesis testing: altering what a research step returns and observing what changes downstream, without re-running the expensive parts.
The Competitive Landscape
The comparison axis that matters here is LangGraph, not AutoGen. AutoGen’s README notes the project is in maintenance mode as of 2026, community-managed, and directing new users toward Microsoft’s Agent Framework. Feature comparisons against AutoGen are diminishing in relevance.
LangGraph 1.1.10, released April 27, 2026, offers durable execution and time-travel (a state-inspection capability that predates CrewAI’s checkpoint work). What it does not expose, based on the public README and recent releases, is an interactive CLI TUI with editable checkpoint inputs and outputs, or a tree-view lineage browser. LangGraph’s recent checkpoint work (1.1.7 on April 17 fixed time-travel bugs; langgraph-checkpoint 4.0.3 on April 27 fixed JSON handling) suggests active development but oriented toward correctness rather than interactive tooling.
| Capability | CrewAI 1.14.3 | LangGraph 1.1.10 |
|---|---|---|
| Checkpoint resume | Yes | Yes (durable execution) |
| Time-travel / state inspection | Yes (TUI) | Yes |
| Interactive CLI TUI | Yes | Not in public docs |
| Editable checkpoint inputs/outputs | Yes | Not in public docs |
| Tree-view lineage browser | Yes | Not in public docs |
| Standalone agent checkpointing | Yes (1.14.3) | Not applicable (different paradigm) |
For teams evaluating CrewAI against LangGraph for a new system, the checkpoint TUI is a concrete infrastructure argument. Most LangGraph users have already built their own checkpoint tooling, which means the question is whether CrewAI’s out-of-the-box ergonomics justify a framework switch, or whether the LangGraph ecosystem and user base make that switch expensive regardless of features.
What Practitioners Should Watch For
The TUI is CLI-only. There is no web dashboard equivalent in 1.14.2 or 1.14.3. For teams that operate pipelines through web-based interfaces, or where operators without terminal access need to inspect checkpoint state, this is a real gap: the feature exists but isn’t accessible without a shell.
The best-effort write semantics deserve attention in production setups. A checkpoint store that silently drops writes under I/O pressure is one you can’t fully trust for recovery. For critical pipelines, validating checkpoint write reliability under load before depending on TUI-based recovery is worth the setup cost.
The 29%3 MCP SDK cold-start reduction in 1.14.3 is a separate optimization with practical value for crews that invoke MCP-backed tools frequently, particularly on cold-start-sensitive infrastructure like serverless runtimes or Daytona sandboxes.
Frequently Asked Questions
Which CrewAI execution models now support checkpointing and fork operations?
Before 1.14.3, checkpointing was crew-scoped; standalone agents could not resume or fork independently. The 1.14.3 release completes the rollout across all three execution models—crews, flows via 1.14.2’s Flow API integration, and standalone agents—meaning every CrewAI abstraction now shares the same resumability primitives. Teams mixing crew orchestration with standalone agent calls no longer need separate recovery logic for each execution path.
How does CheckpointConfig inheritance affect production pipelines with many nested tasks?
Child entities inherit checkpoint configuration from their parent unless explicitly overridden, so a root crew’s storage provider, trigger events, and retention limits propagate to every task by default. This means an overly broad wildcard trigger or a JsonProvider selected at the crew level cascades to all children, and teams should audit root configuration carefully to avoid silent misconfiguration across large pipelines.
How does CrewAI’s fork-and-edit model differ from LangGraph’s time-travel debugging?
LangGraph’s time-travel is oriented toward state inspection and replay correctness—evidenced by recent patches fixing time-travel bugs (1.1.7) and checkpoint JSON handling (langgraph-checkpoint 4.0.3)—while CrewAI’s approach is intervention-oriented. CrewAI lets operators mutate intermediate task outputs and fork execution to observe downstream effects, turning checkpoints from an audit trail into an interactive experimentation surface rather than a replay log.
Is there a web-based checkpoint interface for operators without terminal access?
The open-source releases remain CLI-only, but CrewAI maintains separate Enterprise HITL Management documentation for flow oversight, suggesting web-based human-in-the-loop checkpoint inspection may exist as an enterprise tier feature. Teams with mixed technical and non-technical operators should verify whether their use case falls under community or enterprise boundaries before treating the CLI gap as a permanent limitation.
When should teams choose SqliteProvider over JsonProvider for checkpoint storage?
SqliteProvider’s WAL journal mode suits production pipelines where multiple operators or automation scripts need concurrent read access without locking the store. JsonProvider’s separate human-readable JSON files are preferable when operators need to grep state outside the TUI, archive checkpoints in version control, or audit individual task outputs without querying a database.