Tuesday, 8:04 a.m. You paste a 90-word paragraph about cart abandonment and ask Grok to tighten it. Thursday, turn 60 of the same thread, someone drops a compensation-band screenshot “for tone.” Band 4 starts at $118,400. The thread title is still Untitled.
Sixty turns is how a writing job becomes a junk drawer. History kept every joke, every CSV peek, every “while you’re here.” Memory, if it is on, may file a summary you will not like. A Project bucket, if you have one, is not a vault and it is not git. Payroll-adjacent numbers do not belong in a paragraph-rewrite chat, on grok.com or anywhere else.
This is the habits post in the Grok series. You already have a review pass for drafts and a verify pass for live answers. Those habits die in a messy week unless the thread has a job, a name, and a split rule. If the file is confidential, the privacy post wins over convenience. History on grok.com is not the same list as Grok inside X; pick a surface on purpose (Grok.com, the apps, and Grok inside X). If the work is a repo, wait for Grok Build later in this series.
How chat history, memory, and projects differ
- How chat history, memory, and projects differ (and what they are not)
- How to name a thread like a ticket so Thursday-you can find Tuesday-you
- Which files belong in chat, and which files should never leave your disk
- When to split a thread instead of adding “one more question”
- A worked week: Omar’s four threads, including the payroll near-miss
History vs memory vs projects

Three layers get talked about as if they were one brain. They are not. As of writing, labels on grok.com, iOS, and Android move, and Grok on X does not always share the same history. Re-check Settings the week you adopt this. The distinctions below stay useful even when the menu names change.
History is the list of past conversations. On grok.com, as of the consumer FAQ, you open it from the history control in the corner. On iOS, it lives behind the profile picture. You can reopen a thread and keep talking. Context is that thread’s messages, until the product truncates or summarizes. History is a log, not a promise that every file is still attached, and not a promise that Grok on X can see a grok.com thread.
Memory (when it is enabled) is a cross-chat recall of selected facts, not a verbatim archive of every message. Treat it as a sticky note the product wrote to itself. It can be incomplete, stale, or overly inferential. As of writing, look under Data Controls or the equivalent Settings group, and assume EU/UK and surface rollouts differ. Do not store a secret in a thread and hope memory “will remember the salary band but forget it was sensitive.” Turn memory off for work accounts if policy says so. Delete threads you should not have started.
Projects (on grok.com, as of writing) are named buckets for related chats and files. The FAQ notes that some users on grok.x.ai miss Projects; use grok.com in a normal Chromium browser if you need that surface. A project is still a chat product. It is not Grok Build. It is not a shared drive with access control you can audit like Google Drive. It is not a place to park payroll, student records, or a production .env.
Grok Studio is gone. The FAQ says to use Grok Build instead. Everyday writing still happens in chat. Do not hunt for Studio to organize Omar’s week.
Files you upload live in the chat (and in a files manager on the web at grok.com/files as of writing). Deleting a chat is not the same as “the model never saw it.” Retention, training, and review follow the product’s current policy and your Data Controls. If you would not paste it into a ticket that a contractor might read, do not upload it.
Name the thread like a ticket
Untitled is how turn 60 happens. You will not remember that the cart paragraph lived in a chat that also argued about subject lines. Name the thread before the second message, the way you would name a ticket: team or area, job, and a short noun.
Patterns that work:
WK34-exec-summaryfor a dated writing job with a ship date.scangrid-hold-emailfor one outbound message (Dana’s world from the writing post).stores-visits-questionsfor analysis questions about a specific file.dash-name-brainstormfor a menu of names, no files attached.
Patterns that do not work: Grok, help, new chat, q3, misc, the recipient’s first name alone. Those names collide by Friday. If the product auto-titles from the first line, edit the title. First lines are often “can you…” which is a terrible unique key.
Put the job in the first user message too, in one sentence: “This thread is only for tightening the cart-abandonment paragraph for the Friday ops note. No other docs.” Future you, and the model, both need that fence. If memory is on, a named job is also less likely to bleed into a later chat as “Omar works on compensation,” which he does not, he only almost pasted a screenshot.
One thread, one primary reader. If Tuesday’s paragraph is for the exec note and Thursday’s paragraph is for a vendor, that is two threads even if the topic rhymes. Audience changes the forbidden words. Mixing audiences is how Plan B shows up again.
Files you should and should not upload
As of writing, Grok chat on web, iOS, and Android accepts a wide set of uploads: PDF, DOCX, TXT, CSV, XLSX, PPTX, common images, some audio and video. Web allows many files per message (the FAQ cites on the order of 100 on web, fewer on Android). Size guidance is on the order of 150 MB per file. Those numbers will move. The policy that should not move is yours: if the file has people, money, students, health, or secrets, it stays out of consumer chat unless your employer has a blessed path.
Safe enough for practice and for many internal drafts:
- A paragraph you wrote, pasted as text, with names already scrubbed.
- A toy CSV you built for the question (10 rows, fake store names).
- A public help article you saved as PDF, or a screenshot of a public docs page.
- An outline with placeholders instead of live customer emails.
Hard no, even if the upload button accepts the file:
- Payroll, compensation bands, offer letters, performance ratings.
- Student work with names, grades, or IDs. School emails with other families’ data.
- Customer extracts with emails, phones, ticket bodies, medical-adjacent notes.
- API keys,
.envfiles, SSO screenshots, invoice PDFs with account numbers. - A “small slice” of a warehouse export that still has employee_id.
If you need Grok to see structure, build a toy. “Eight rows, columns store, visits, add_to_cart, fake names” is enough for an explain or brainstorm job. If you need Grok to see the real 842 rows, you are probably past everyday chat. That is a warehouse job, or a carefully scoped Build job later, or a “do not use Grok” job per the wrong-tool post.
After the week, delete what you can. On the web, grok.com/files is the cleanup hatch as of writing. Deleting is hygiene. It is not a time machine, and it is not a legal hold. Do not upload on the theory that you will delete later. You will forget. Omar almost did.
Split when the job changes

Splitting feels fussy at 8:12 a.m. It feels obvious at turn 60. Use a hard rule so you do not negotiate with yourself.
Start a new thread when any of these is true:
- The audience changed (exec note vs vendor vs new hire).
- The job type changed (draft vs explain vs brainstorm vs “is this rumor true”).
- The data grain changed (one paragraph vs a table vs a live-search claim).
- The confidentiality changed (public docs vs anything with a person or a dollar).
- The thread is summarizing itself badly, contradicting an earlier fact, or repeating a SKU you already corrected.
- You would not want a coworker to scroll from message 1 to now in a screen share.
When you split, carry a three-line brief, not the whole transcript: goal, facts that are still true, forbidden words. Pasting 59 turns into the new chat re-creates the junk drawer with extra steps. If a file still belongs, attach it again in the new thread rather than trusting an old upload to stay attached and still be the version you mean.
Do not split by mood. “New chat because this one got snarky” is optional. Split by job. Snark you can fix with “plain tone, no jokes” in the next message. A compensation screenshot you cannot unsee.
| Put it here | Not here |
|---|---|
| A named thread for one job (draft, explain, or brainstorm) | Untitled, or a thread that already shipped a different audience |
| A grok.com Project as a bucket of related named threads | A dump of every Q3 file “so Grok has context” |
| Toy tables and scrubbed paragraphs | Payroll, ratings, student records, keys, customer extracts |
| Your wiki, Drive, or git for the source of record | Chat history treated as the official copy of the email you sent |
| Grok Build (later in this series) for a sandbox folder | Everyday chat asked to “edit the repo” |
| Memory off, or tightly reviewed, on work accounts | Hoping memory will recall salary bands and forget they were sensitive |
Worked week (Omar’s four threads)
Omar is a product analyst. Week 34 he owes a Friday ops note, a look at store-visit counts, a dashboard name, and (this is the trap) a side question from a manager about how PTO accrual appears on a pay stub. He used Grok on grok.com, work account, memory off because policy said so.
Monday he opened WK34-exec-summary. First message: “This thread is only the Friday ops note for leadership. Audience has 90 seconds. No files with people.” He drafted the cart paragraph here, then stopped. That is the 8:04 a.m. job from the lede, contained.
Tuesday he opened stores-842-visits-questions. He did not upload the warehouse extract. He built a 10-row toy CSV with fake store names and the same columns: store, visits, add_to_cart. 842 was the real count he already knew from the dashboard; it stayed in his note, not in an upload of 842 identified rows. He asked Grok to explain a dip in visits for a new hire. He ran the live-answer checks from the previous post on anything that smelled like an external benchmark.
Wednesday he opened dash-name-brainstorm. No files. Eight names, Fact-based vs Guess tags, he picked one, he left. Eleven minutes.
Thursday a manager pinged: “Can you explain the PTO accrual line so it sounds less legal.” Omar almost dropped a pay-stub screenshot into WK34-exec-summary because that thread was already open. Band 4’s $118,400 was visible in the same PDF export someone had used as a template. He did not upload it. He did not start a fourth Grok thread for payroll. He wrote three sentences himself from the HRIS help page, and asked HR to confirm the wording. That question was never a Grok job.
The failure version of Thursday is the lede: turn 60, screenshot in, title still Untitled, history now holding a compensation band next to a cart-abandonment metaphor. Even with memory off, the thread is a retention problem and a screen-share problem. Omar’s split rule saved him from living that version.
| Thread | Job | Files | Split or stop |
|---|---|---|---|
| WK34-exec-summary | Draft Friday ops note | None (paste scrubbed text) | Stop when the note ships |
| stores-842-visits-questions | Explain toy table to a new hire | 10-row fake CSV | Do not attach the real extract |
| dash-name-brainstorm | Brainstorm 8 names | None | Stop after the pick |
| (none) | PTO stub wording | Pay stub never uploaded | HRIS plus HR, not Grok |
If you would not want the first message and the last message on the same screen in a meeting, split the thread or do not start it.
Leaving the title as Untitled, then hunting
- Leaving the title as Untitled, then hunting on Friday for “the cart one.”
- Treating history, memory, and projects as the same brain. They are a log, an optional sticky note, and a bucket.
- Uploading the real extract because the toy CSV felt fake. Fake is the point.
- Pasting one more question into a shipped draft thread. That is how payroll lands next to a metaphor.
- Using grok.x.ai, then wondering where Projects went. The FAQ says grok.com.
- Assuming delete equals never-seen. Hygiene still matters. So does not uploading.
- Turning on memory for a work account “so it knows our SKUs,” then discovering it also knows a salary band from a screenshot.
History is a log
This week, cap yourself at three named threads. Title them before message two. Put a one-sentence job fence in message one. If a fourth job appears, either open a fourth thread or do it without Grok. Delete one old Untitled chat you no longer need, and glance at grok.com/files if you are on the web.
Next in this series: Grok at home, school, and work: four realistic weeks. Same model, different stakes, and a hard stop in each context. The thread habits from this post travel with you. Hub: Grok series.
History is a log (habits)
- History is a log. Memory is an optional sticky note. Projects are buckets. None of them is a vault or git.
- Name the thread like a ticket. Fence the job in message one.
- Upload toys and scrubbed text. Never payroll, students, keys, or customer extracts.
- Split when audience, job, grain, or confidentiality changes, or when a screen share would embarrass you.
- Omar’s Week 34: three Grok threads, one HR question that never entered chat, no $118,400 screenshot.
- As of writing, check grok.com, Data Controls, and grok.com/files. Labels move.
Sources
Research and further reading used for this article:
- xAI: Grok website / apps FAQ (history location, file types and size hedges, grok.com/files, grok.com vs grok.x.ai for Projects, Studio retired)
- xAI consumer FAQ (where you can use Grok; conversation history on app and grok.com)
- grok.com (consumer chat, Projects surface as of writing)
- xAI: Grok product page (chat apps versus other surfaces)
- Analytics Made Simple: privacy and work caution (training toggles, work vs personal accounts, sanitizing before paste)
- Analytics Made Simple: when Grok is the wrong tool (payroll, production data, jobs chat should not take)
- Analytics Made Simple: Grok series (hub; Grok Build comes after the everyday posts)
- Analytics Made Simple: Learn (related paths on this site)
Keep going
Same lessons in your feed
Short diagrams and hooks on Instagram, X, and Facebook.
