# How fresh is Gitsu MCP data? Cached vs fresh reads Author: Sahil Dave Canonical: https://gitsu.app/docs/gitsu-mcp-cache-freshness Published: 2026-10-07 Updated: 2026-10-07 Last checked: 2026-10-07 > **TL;DR** A Gitsu MCP cached answer is as recent as the GitHub data Gitsu holds, and the reply names its source and age. list_items and list_fields try the running app, a saved snapshot, then GitHub. Cached get_item uses the running app; its comments and blocking details can have separate ages. Use fresh: true on get_item for a fresh GitHub item read. Background polling and rate-limit waits mean cache age is information to check, not a freshness guarantee. Gitsu MCP cache freshness is the age of the GitHub data behind an answer, shown alongside the source that served it. A fast local reply can contain older data, so check the source and age when the decision depends on recent changes. Gitsu makes the local read path explicit. The [millisecond read measurements](/features/mcp-local-reads) describe how quickly a cached request was answered; they do not establish how recently its contents changed on GitHub. ## Where did this MCP answer come from? Read the source line to distinguish the running app's cache, a saved board snapshot and a GitHub read. | Source line | Meaning | What to check | | --- | --- | --- | | `from Gitsu · 2 min ago` | The running app supplied cached data | Whether that age suits the task | | `from snapshot · 2 h old` | A saved MCP board snapshot supplied the data | Whether work may have changed since that GitHub read | | `from GitHub` | The tool used a GitHub read | The board and result it names | The ages above illustrate the reply format. They are not default ages or service guarantees. For `list_items` and `list_fields`, Gitsu tries the running app first, then the snapshot, then GitHub. A requested column the cache does not hold can also require a GitHub read. The snapshot file's rewrite time is not its data age. Gitsu tracks when the GitHub response arrived; a local patch or rollback must not make an old answer appear newly fetched. ## How do I request a fresh GitHub answer? Set `fresh: true` on `get_item` to request GitHub data instead of the cached item answer. For one item, using an illustrative issue number: ```json { "number": 42, "fresh": true } ``` These are tool arguments. Add the actual `project_id` and, when needed to distinguish an issue number, the repository. The [MCP server reference](/features/mcp-server) explains item lookup and board discovery. `list_items` and `list_fields` do not expose a `fresh` argument. Their normal source selection still applies. For a fresh repository-wide issue list, use the [GitHub CLI or GitHub MCP integration](/docs/github-issues-ai-agent) rather than adding an unsupported flag to Gitsu's board-list call. Use a fresh read before a decision that depends on a teammate's latest change. A cached read may be sufficient for exploring a loaded board or finding which item to inspect next. Check the source line after the call rather than assuming the answer came from memory or GitHub. ## How often does the board cache refresh? The documented normal board polling interval is three minutes plus up to one minute of jitter, including when the window is hidden, but rate limits can delay it. When the remaining GitHub budget drops below ten percent, hidden-window board polling waits for the reset time. With no budget left, polling waits whether the window is visible or hidden. That policy preserves some capacity for the person using the app. Board polling does not mean every part of an item refreshes in the background. Item details and comment threads follow their screen's visibility instead. A cached comment thread can therefore be older than the board rows around it. Read the age returned for the data you are actually using. ## Why can an item answer contain several ages? Board rows, opened-issue details and comments are separate cached reads, so Gitsu reports their ages separately when it uses them together. The documented answer format can include: ```text from Gitsu · 2 min ago Sub-issue list, blocker titles and what this blocks: from Gitsu · 10 min ago Comments: from Gitsu · 4 min ago ``` This is an illustrative response. It makes the distinction visible instead of presenting all parts as equally recent. Ask for comments with `include: ["comments"]` or blocking details with `include: ["blocking"]`. Gitsu can use memory when the required cached data is complete; otherwise it reads GitHub. The lean answer also identifies extra cached parts and missing parts, helping the agent request the detail it needs. ## What happens when Gitsu is closed? Board lists and field reads can use the saved snapshot, while `get_item` needs GitHub because item detail is not carried in that snapshot. Keeping bodies out of the board snapshot avoids carrying every issue's body through list reads. The trade-off is that a saved board list cannot supply the cached item-detail path on its own. Writes also require the running app. For a reliable reading routine: 1. Check the board named in the answer. 2. Read the source and each relevant age. 3. Request missing comments or blocking details explicitly. 4. Use `get_item` with `fresh: true` when the item's available ages are too old for the decision. [MCP views](/features/mcp-views) render the tool's structured answer; the card itself does not make another board request to freshen it. ## How we checked The source ladder, fetchedAt-based ages, background rate-limit policy and separately aged item/comment answers documented in Gitsu's sidecar implementation and tests. ## Frequently asked questions ### How do I force a fresh GitHub read through Gitsu MCP? Set fresh: true on get_item. Gitsu bypasses the cached item answer and reads GitHub; check the response source line. list_items and list_fields do not expose that flag. ### What does from snapshot mean in a Gitsu MCP answer? The board answer came from the saved MCP snapshot. Its age describes the underlying GitHub read, not the time the file was rewritten. ### Do Gitsu MCP comments have the same age as the board? Not necessarily. Cached comments and opened-issue details carry their own ages, so one answer can contain parts fetched at different times. ### Are Gitsu MCP cached reads always less than four minutes old? No. Board polling normally runs every three minutes plus up to one minute of jitter, but it backs off for GitHub rate limits. Saved snapshots and item details can be older. Read the age in the reply. ## Related resources - [Gitsu MCP: GitHub Projects reads in milliseconds](https://gitsu.app/features/mcp-local-reads) - [GitHub Projects MCP views: cards inside your AI chat](https://gitsu.app/features/mcp-views) - [The Gitsu MCP server for GitHub Projects v2](https://gitsu.app/features/mcp-server) - [Gitsu MCP priority filters: find P0 items](https://gitsu.app/docs/gitsu-mcp-priority-filters)