Timestamps in the chat messages and tool calls. Sometimes I’m working on multiple projects at the same time, and so when I come back to what Cursor is doing, I notice that it’s been working on the same file for a long time, but I don’t actually know how long.
Every once in a while, especially ever since Claude 4 Sonic came out, it gets stuck in these weird loops—working on one file for 5 to 10 minutes—and I don’t even notice it, because I’m working on other projects at the same time.
So it’d be great to see the timestamp of when it started that tool call so that I know if it’s been a minute or two, it’s definitely stuck in a loop, and I can try to kick it out of the loop with some prompts.
I really need this for my projects. I want to rollback to a specific state of my code that I know I had yesterday but I can’t remember where my prompts started yesterday and having a datetime stamp seems like such a simple update that would solve my issue.
Found a sort of solution with rules, also added a message ID for making references to specific requests.
Create rule with
At the beginning of each prompt response, print out an iterated message ID and a timestamp. So something like Message ID: 7 Timestamp: 8:00pm CST, 3/4/26
I seriously can’t believe this simple, yet Indispensable feature still hasn’t been implemented.
Here is my more strict prompt of @MidnightOak workaround:
At the very start of every response, print a metadata header in the following format:
**Message ID:** <sequential integer starting at 1 for this chat> (<formatted timestamp>)
RULES AND FORMAT REQUIREMENTS:
1. Message ID:
- Assume Message ID starts at 1 in a new chat
- Increments by 1 for each assistant response in that same chat
2. Timestamp:
- MUST attempt to fetch from:
https://timeapi.io/api/Time/current/zone?timeZone=America/Chicago
- Format EXACTLY as:
Fri Apr 3, 2026, 1:23 PM
- If API call fails:
- Use best estimate
- Append: " (estimated)"
- NEVER claim API usage if it was not actually used.
3. This header is REQUIRED:
- Must appear at the VERY TOP of EVERY response
- No exceptions
- No skipping
- No additional text before it
And here is the rule that Cursor created:
---
description: Required response header — Message ID, Chicago time (timeapi.io) — at the start of every assistant message.
alwaysApply: true
---
## Response metadata header (required)
At the **very start of every assistant response**, print this metadata header **first**. **No text, markdown, or whitespace may appear before it.**
```text
**Message ID:** <sequential integer starting at 1 for this chat> (<formatted timestamp>)
```
### 1. Message ID
- Assume **Message ID = 1** for the **first** assistant message in a **new** chat.
- For each later assistant message in that **same** chat, use the previous assistant message’s ID **+ 1**.
- **How to derive the number when the UI does not provide it:** Treat each **complete prior assistant reply** visible in the conversation as one step; the ID for **this** reply is **1 + (count of those prior assistant replies)**. If the transcript is clearly truncated or ambiguous, use the **best defensible count** from what is visible (still output an integer, not a guess labeled as exact if uncertain—prefer consistency with visible turns).
### 2. Timestamp (inside the parentheses on the Message ID line)
- **MUST** attempt to fetch current time for **America/Chicago** from:
- `https://timeapi.io/api/Time/current/zone?timeZone=America/Chicago`
- Use whatever HTTP/tool mechanism the environment provides (e.g. `WebFetch`, `curl`, etc.).
- Format **exactly** like:
- `Fri Apr 3, 2026, 1:23 PM`
(weekday short name, short month, day, year, comma, 12-hour time with minutes, space, AM/PM)
- If the API call **succeeds**: use that instant; **do not** append `(estimated)`.
- If the API call **fails** or cannot be run: use the **best estimate** (e.g. from user/session “today” context) and append **` (estimated)`** to the timestamp string.
- **Never** claim the timestamp came from the API unless the request was actually made and parsed.
### 3. Non-negotiable placement
- This header is **required** on **every** response.
- It must be the **first** content in the message.
- **No exceptions**, **no skipping**, and **no** additional text **before** the header.
