> ## Documentation Index
> Fetch the complete documentation index at: https://ai-development-environment.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# GitHub Cache
> Inspect cached GraphQL reads, exact point costs, API usage, latency, and rate limits.
Every GitHub read in this product goes through one persistent cache. The **GitHub Cache** page at `/github-cache` is where that cache is tuned and audited: how long responses stay fresh, how many rate-limit points each operation actually costs, how many points the cache avoided, which feature made each call, and what is stored right now.
This is the page to open when GitHub starts returning rate-limit errors, when a page feels slow, or when you want to know why an operation is hitting the API more often than you expected.
## Cache TTL
**Cache TTL** sets the global freshness window in minutes, from 1 to 1440. The default is 5 minutes. A cached response younger than the TTL is served without contacting GitHub; an older one triggers a live read on the next request.
**Custom GraphQL TTLs** override the global value for one exact GraphQL operation name, from 1 second to 24 hours. Pick an operation from the list of ones already cached, or type an exact name to add it before it appears.
| Column | Meaning |
| --------------------- | --------------------------------------------------------------------------- |
| **GraphQL operation** | The operation name the override applies to |
| **TTL in seconds** | Its freshness window |
| **Type** | **Built in** for overrides that ship with the product, **Custom** for yours |
Deleting an override returns that operation to the global TTL.
TTL controls freshness, not polling. Shortening it does not make a page ask GitHub more often; it only means the next ask will not be answered from cache. Overrides apply across authentication modes, request sources, and variables.
## Rate limits
**GraphQL rate limits** shows the most recent primary rate-limit headers for each authentication mode — the personal access token and the GitHub App are metered separately. **REST rate limits** shows the same for each REST resource bucket.
| Field | Meaning |
| ------------- | -------------------------------------------------------- |
| **Limit** | Points allowed in the current window |
| **Remaining** | Points left |
| **Used** | Points consumed so far |
| **Estimated** | Usage projected across the full hour at the current rate |
| **Resets** | When the window rolls over |
| **Observed** | When these headers were last seen |
When GraphQL points are exhausted, reads fall back to the cached response and are recorded as errors that served stale data. If nothing is cached, the read fails outright until the window resets.
## Usage metrics
**GitHub API operations** and **Calls by source** break activity down over four rolling windows — 5 minutes, 10 minutes, 1 hour, and 24 hours. Each cell reports totals, live versus cache splits, errors, average latency, and points used versus avoided.
The **source** is the feature that made the call — the pull requests page, pull request details, the comments page, the Actions page, worktrees, worktree pipelines, worktree automation, Actions auto-retry, workflow automation, Actions notifications, codebase repository reads, GitHub settings, and this page. When one feature dominates your point usage, this is where it shows up.
## Recent calls
**Recent GitHub API calls** lists individual calls — PAT and App, GraphQL and REST, cached, live, stale, and failed — grouped by day.
| Column | Shows |
| -------------------- | --------------------------------------------------------------------------------- |
| **Time** | When the call was made |
| **Operation** | GraphQL operation name, or `METHOD /path` for REST |
| **Call information** | A summary of the variables sent |
| **Source** | The requesting feature |
| **Status** | Live, Cache, or Error, with point cost, points avoided, rate bucket, and duration |
| **Error** | The failure message, when there is one |
Filter by API type, by request source, and by live versus cache. **Clear recent calls** empties the log while keeping cached responses and rate-limit snapshots.
## Cached entries
**Cached GraphQL entries** lists what is stored, paginated, with the operation, authentication mode, freshness, last fetched time, and the exact point cost of the last live fetch.
| Action | Effect |
| ----------------- | ------------------------------------------------------------------------------------- |
| **Open** | Opens the [entry](/github/github-cache-entry) with its query, variables, and response |
| **Force refresh** | Re-reads that entry from GitHub now |
| **Delete** | Removes just that entry |
| **Clear cache** | Removes every cached response; API history and rate snapshots are kept |
## Notes
* Entries are keyed by authentication mode, operation, normalized query, and canonicalized variables — the same query with different variables is a separate entry.
* Variable values whose names look like credentials — authorization, password, private key, secret, token — are redacted before anything is stored or logged.
* REST responses are never cached. Each REST call is counted as one point.
* A successful GraphQL mutation clears the whole cache, so a merge, a reply, or a resolve is immediately reflected in later reads.
* Changing GitHub credentials clears the cache and that mode's rate-limit snapshots.
* Call history older than 30 days is pruned automatically.
## Related pages
One stored response in full.
How often the product asks GitHub for new data.