---
title: "Configure TTL, start, and resume"
description: "Run the expiring chat sessions demo to configure AerospikeSaver TTL, start a LangGraph thread, and resume from checkpoints."
---

# Configure TTL, start, and resume

> For the complete documentation index see: [llms.txt](https://aerospike.com/docs/llms.txt)
> 
> All documentation pages available in markdown.

The cookbook wires a chat graph in [`agent.py`](https://github.com/aerospike/langgraph-aerospike/blob/main/cookbooks/expiring-chat-sessions/agent.py) and runs the TTL lifecycle in [`demo.py`](https://github.com/aerospike/langgraph-aerospike/blob/main/cookbooks/expiring-chat-sessions/demo.py). Open those files if you want to see how messages are constructed and how each invoke writes a checkpoint through `AerospikeSaver`.

## Run the demo (—skip-wait)

1.  From the repository root, run the demo with `--skip-wait` (Phases 1 through 3, without the TTL wait):
    
    Terminal window
    
    ```shell
    uv run python cookbooks/expiring-chat-sessions/demo.py --skip-wait
    ```
    
2.  Review Phases 1 and 2:
    
    Watch `checkpoint TTL` at the end of Phase 2. It should read `60 seconds`, confirming the TTL landed on the Aerospike record, not just in the saver config.
    
    ```text
    ================================================================
    
    Phase 1 - Configure TTL
    
    ================================================================
    
      namespace        : test
    
      thread_id        : session-demo-001
    
      default_ttl      : 1 minute(s)
    
      refresh_on_read  : False
    
      -> Every checkpoint write is stamped with this TTL by Aerospike.
    
    ================================================================
    
    Phase 2 - Start a chat session
    
    ================================================================
    
      user      > Hello, I need help with my order.
    
      assistant > Hi! I'm your support assistant. How can I help?
    
      messages stored  : 2
    
      checkpoint TTL   : 60 seconds (set natively by Aerospike)
    ```
    
3.  Confirm Phase 1 and Phase 2:
    
    Phase 1 constructed `AerospikeSaver` with a one-minute default TTL and `refresh_on_read=False`. From this point forward, every checkpoint write for `session-demo-001` is stamped at the Aerospike record layer, not in application memory.
    
    Phase 2 sent the first user message through the chat graph. LangGraph wrote a checkpoint containing the user message and assistant reply. The demo then read TTL from the Aerospike record metadata to confirm the stamp landed on storage, not just in the saver config.
    
    -   `messages stored` is `2` after the first turn (one user message, one assistant reply).
    -   `checkpoint TTL` reports `60 seconds`, matching the one-minute default.
4.  Review Phase 3 in the same output:
    
    Watch `messages stored`. It should read `4`, confirming the prior two messages were loaded from the checkpoint rather than starting a fresh session.
    
    ```text
    ================================================================
    
    Phase 3 - Resume the same thread
    
    ================================================================
    
      user      > Are you still tracking my conversation?
    
      assistant > Got it -- I've noted that down for this session.
    
      messages stored  : 4  (history preserved across the resume)
    
    ================================================================
    
    Done (--skip-wait)
    
    ================================================================
    
      Skipped the TTL wait. Re-run without --skip-wait to watch it expire.
    ```
    
5.  Confirm the resume loaded prior history:
    
    Phase 2 stored two messages for `thread_id=session-demo-001` and stamped the checkpoint with a one-minute TTL. Phase 3 tests whether that state is still there: the demo sends a second user message on the same thread while the TTL has not elapsed.
    
    `AerospikeSaver` loaded the Phase 2 checkpoint from Aerospike, appended the new user message and assistant reply, and wrote an updated checkpoint. No new session was created.
    
    -   `messages stored` increased from `2` to `4` (two prior messages plus the new user/assistant pair).
    -   The assistant reply is the second scripted line from `FakeListChatModel`. That response only appears when prior messages were loaded from Aerospike, not on a fresh thread.
    
    History stays on this `thread_id` until the TTL expires. [Prove expiry](https://aerospike.com/docs/develop/langgraph-expiring-chat-sessions/step/2/part/1/prove-expiry) runs the full demo without `--skip-wait` to show Aerospike reclaiming the records. This demo leaves `refresh_on_read` as `False`. When enabled, reads can reset the TTL window on each access.
    

::: note
To use a real LLM, replace the body of `_make_llm()` in `cookbooks/expiring-chat-sessions/agent.py` with your provider client. The graph shape and Aerospike behavior stay the same.
:::
::: undefined
-   I’ve run the demo through Phases 1–3 (TTL configuration, first turn, and resume).
-   I’ve confirmed the checkpoint TTL is set and message count reached four after resume.
:::

[Previous  
Clone and install](https://aerospike.com/docs/develop/langgraph-expiring-chat-sessions/step/1/part/1/clone-and-install) [Next  
Prove expiry](https://aerospike.com/docs/develop/langgraph-expiring-chat-sessions/step/2/part/1/prove-expiry)