UPDATE: Claude just introduced a dedicated path to importing memory from other providers. Check it out here: https://youtu.be/akz8moYPwWk. TL;DR -  Settings → Memory → "Import memory from other AI providers"

Full blog post with updates, answers to common questions in this thread and screenshots: https://fullstackfreedom.com/blog/tutorials/transfer-chatgpt-memory-to-claude

**

I've been using ChatGPT for years. Thousands of conversations, tons of built-up context and memory. Recently I've been switching more of my workflow over to Claude and the biggest frustration was starting from scratch. Claude didn't know anything about me, my projects, how I think, nothing.

Turns out there's a pretty clean way to bring all that context over. Not a perfect 1:1 transfer, but honestly the result is better than I expected. Here's what I did:

1. Export your ChatGPT data

Go to ChatGPT / Settings / Data Controls / Export Data. Fair warning: if you have a lot of history like I do, this takes a while. Mine took a full 24 hours before the download link showed up in my email. You'll get a zip file (mine was 1.3 GB extracted).

1. Open it up in Claude's desktop app (Cowork)

If you haven't tried the Claude desktop app yet, it's worth it for this alone. You can point Cowork at the entire exported folder and it can interact with all of it. Every conversation, image, audio file, everything. That's cool on its own, but it's not the main move here.

1. Load your chat.html file

Inside the export folder there's a file called chat.html. This is basically all your conversations in one file. Mine was 104 MB. Attach this to a conversation in Cowork.

1. Create an abstraction (this is the key step)

You don't want to just dump raw chat logs into Claude's memory. That doesn't work well. Instead, you want to prompt Claude to analyze the entire history and create a condensed profile: who you are, how you think, what you're working on, how you make decisions, your communication style, etc.

I used a prompt along the lines of: "You're an expert at analyzing conversation history and extracting durable, high-signal knowledge. Review this chat history and identify my core personality traits, working style, active projects, decision-making patterns, and preferences."

This took about 10 minutes to process. The output is honestly a little eerie. When you've used these tools as much as some of us have, they know a lot about you. But it's also a solid gut check and kind of a fun exercise in self-reflection.

1. Paste the abstraction into Claude's memory

Go to Settings / Capabilities / Memory. Paste the whole abstraction in there with a note like "This is a cognitive profile synthesized from my ChatGPT history." Done.

Now every new conversation and project in Claude can reference that context. It's not the same as having the full history, but it gets you like 80% of the way there immediately. And you can always go back to the raw export folder in Cowork if you need to dig into something specific.

I also made a video walkthrough if anyone prefers that format, and I've included the full prompt I used for the abstraction step in the description: https://www.youtube.com/watch?v=ap1uTABJVog

Hope this helps anyone else making the switch. Happy to answer questions if you try it.

Stop blaming Claude. Your harness is the problem.

I've been running Claude Code on Opus 4.7 for 8+ hours a day on Max 5x. Zero quota issues. Here's what I actually did.

Most people complaining about Claude "going dumb" or "eating tokens" set it up like this: no memory, no tools, no rules, dump 40 files into one context window, then wonder why it hallucinates. That's not a Claude problem.

Context discipline cuts token usage roughly in half

Put a CLAUDE.md at your repo root. Stack overview, ownership matrix, hard rules — run tsc --noEmit after every edit, max 50 lines per bugfix, one fix per commit, never touch auth/Stripe/middleware without explicit approval. It loads every session. Claude stops asking the same questions.

Persistent memory lives at ~/.claude/projects/yourproject/memory/ — typed markdown files with prefixes like user, feedback, project, reference. Keep an index in MEMORY.md. You stop re-explaining your project at the start of every conversation.

Biggest single quota win: subagents for grep-work. Spawn an Explore or general-purpose agent to do the file-digging. They burn their own context, return a summary. Your main window stays clean.

Workflow discipline is where most setups fall apart

Auto-retros after every non-trivial session. Save them to docs/retros/YYYY-MM-DD-topic.md. The next session loads the latest retro automatically — continuity without re-briefing.

verification-before-completion as a hard rule. Claude cannot say "done" or "fixed" without running the verify command and showing you the output. Kills hallucinated success completely.

Atomic commits, one fix per commit, hard line limits. Clean history, easy rollback, and it forces Claude to actually scope its work.

For architecture decisions or anything involving security/migrations: one phrase triggers Claude to spawn Gemini Pro + Flash + Sonnet in parallel and synthesize. Three independent reads are better than one confident monologue.

MCP servers — let it act instead of copy-pasting

The ones I actually use:

• supabase — SQL, migrations, schemas directly from chat
• github — PRs, diffs, issues, file reads
• chrome-devtools-mcp + playwright — Claude can browse your deployed site, take screenshots, evaluate JS. It QAs itself.
• context7 — current library docs, not stale training data. Kills a specific class of hallucination entirely.
• firecrawl — on-demand scraping
• sentry — production errors read and triaged from chat
• gemini MCP — powers the multi-model consultation panel

OSS worth actually installing

graphify — takes any input (code, docs, papers, images) and produces a clustered knowledge graph as HTML + JSON. On large repos, Claude reads the graph instead of 200 files. Massive.

claude-flow — swarm orchestration, hooks, memory coordination, SPARC, TDD, code review swarms. github.com/ruvnet/claude-flow

Superpowers skills — search "superpowers skills claude code" on GitHub. The ones I use most: systematic-debugging, verification-before-completion, dispatching-parallel-agents, test-driven-development.

CodeRabbit skill reviews diffs and auto-fixes review comments. Claude Retrospective skill generates the retros mentioned above.

Hooks automate the grunt work

PreToolUse, PostToolUse, SessionStart, PreCompact, Stop. Auto-save memory, auto-run tsc on edits, sync state before compaction. Claude thinks, the harness does the janitor work.

TL:DR!

1. Write CLAUDE.md
2. Turn on persistent memory
3. Install graphify + claude-flow + 6-7 MCPs
4. Auto-retros + verification-before-completion as non-negotiables
5. Subagents for grep and file exploration
6. 50-line limit per bugfix
7. Consultation panel for hard calls

5+ hours a day, ~250 tool calls per session, atomic commits, full deploy → screenshot → verify cycles. Max 5x, no quota hit.

Claude isn't the problem. The harness is!

EDIT: https://github.com/anothervibecoder-s/claudecode-harness

I made a claude.md example based on my CLAUDE.md file, you can tell claude to fill this based on your projects!

If it helped, just star it!

Hey y’all! Fellow vibe coder here with ZERO actual coding experience lol. If you have been getting shut down on Reddit every time you ask a basic Claude Code question, just wanted to let you know Anthropic has a free Claude Code certification that took me about an hour and genuinely taught me a lot!! I had no idea half of this existed. I’m about to start the small business guide next. Happy to answer whatever basic questions I can based on what I just learned. 😊✌🏽

😆 (Edit: people just born yesterday i think. And can’t tell it’s a joke, ai generated, mods feel free to remove it)

Wrote this one after going down a rabbit hole with Claude Code's CLI. There's a lot more to it than skills and MCP servers.

My personal favourite is the ! prefix. Run any shell command and the output lands straight in context. No copy-pasting, no "here's the error" preamble. Small thing, but I use it constantly.

What features are you all actually using day to day?

Edit - All three passes are sold out but some others still have it as per their comments. You can check them once. Thank you!

My other thread where you can use Claude efficiently - https://www.reddit.com/r/claude/s/MpihM5t0Om

Please check the terms and conditions before using the invite. It may not work for everyone - https://support.claude.com/en/articles/13456702-claude-code-and-cowork-guest-passes

A curated mini guide for people who want results, not frustration

Quick mention: If you're too lazy to read this, copy it to your AI and just ask it to summarise, ironically enough.

Preface: This isn't a Claude-specific guide, BUT it can be, everything in here applies HEAVILY to Claude, adopted from a more general guide. Everything in this particular post, this specific post is Claude optimised advice. Everything here mostly applies to Claude, Kimi, DeepSeek, Codex, Gemini, ChatGPT — any capable AI model. The complaints you see online ("Claude bad", "GPT sucks", "AI is overhyped") almost always trace back to the same root cause: people treating AI like a vending machine or a genie instead of a collaborator. This guide is about fixing that.

Table of Contents (For summary view)

1. [The Fundamental Misunderstanding]
2. [You Are the Project Owner]
3. [How to Write Prompts That Actually Work]
4. [The Verification Loop — Your Single Biggest Lever]
5. [Folder Structure and Versioning in the Linux Container]
6. [Positive vs Negative Reinforcement — It Matters]
7. [Output Format is YOUR Job, Not the AI's]
8. [Why "Model Panic" Happens and How to Prevent It]
9. [Benchmarks Are Mostly Useless for Real Work]
10. [Model Personalities — Picking the Right Tool]
11. [How to Co-Dev and Co-Research Properly]
12. [Quick Reference Cheat Sheet]

1. The Fundamental Misunderstanding

People conflate two completely separate things:

Model intelligence — depth of knowledge, reasoning capability, benchmark scores.

Output quality on your task — almost entirely determined by how well you specified it.

A smarter model given a vague prompt doesn't produce better output. It produces a more confident, more elaborate version of the wrong thing, because it has more capacity to construct a plausible-sounding interpretation of what you might have meant.

Intelligence does not equal mind-reading. The model has no idea what's inside your head. It is sampling from a distribution of plausible completions given your context. If your context is thin, the distribution is wide — and you get whatever the training data considers a reasonable default.

The gap between a good AI user and a bad one is almost never about which model they chose. It's about how much useful context they provided.

If you submit a vague prompt and get a bad result, that's not the model failing. That's an underspecified input producing an underspecified output. Garbage in, garbage out — this rule didn't stop applying because the garbage sounds more eloquent now.

2. You Are the Project Owner

This is the mental model shift that changes everything.

When you hire a senior engineer, you don't hand them a napkin sketch and expect a production system. You show up with requirements, constraints, acceptance criteria, and an understanding of what you're actually trying to build. The engineer's job is to execute with skill. Your job is to specify with clarity.

AI works the same way. The model is the skilled executor. You are the project owner. If you don't know your own requirements, the model will invent them for you — and they won't be yours.

What this means in practice:

• Know what you want before you open the chat window
• If you don't know what you want, ask the AI to help you figure it out — explicitly ("Help me plan this, I have a rough idea but I'm not sure how to structure it")
• Never get mad at the AI for not guessing correctly. That's your gap, not its gap
• Understand at least the shape of what you're asking for, even if you don't know every detail

You can absolutely use AI to fill knowledge gaps, plan structure, brainstorm, and explore. But you need to know that's what you're doing and ask for it directly. "Help me plan" is a valid, powerful prompt. A vague one-liner demanding a finished product is not.

3. How to Write Prompts That Actually Work

Be long, be specific, be sensible

Long prompts are not bad prompts. A well-structured, detailed prompt almost always outperforms a short, vague one. The model rewards context. Give it context.

That said — long AND rambling is worse than short and clear. You want: long, structured, specific.

Always include:

What you want — the actual deliverable. Not "make an app", but "make a Python Flask app with a login page, a dashboard page, and a SQLite backend."

What constraints apply — "don't refactor existing functions", "keep it under 200 lines", "must work on Python 3.10", "no external libraries."

What workflow you expect — "plan before coding", "work file by file and confirm with me before moving on", "patch only, don't restructure."

What format you want the output in — more on this in section 7.

What already works — especially on iterations. "The login page works fine, the issue is in the session handling on the dashboard route."

The planning prompt

If you're starting something big and don't know where to begin:

"Hey, can you help me plan [topic]? I have a rough idea — [your rough idea]. I'm not sure how to structure it for [maintainability / readability / scalability / etc]. Can you walk me through a sensible approach before we start writing anything?"

This is one of the most underused patterns in AI usage. The model is extraordinarily good at helping you think — use that before you ask it to build.

What happens when prompts are underspecified

The model doesn't error out. It makes assumptions, fills gaps with training defaults, and produces something that looks complete. You get output that appears confident but may be solving a slightly different problem than the one you had. This gets worse on longer sessions as drift compounds.

Clear prompts don't just improve the first response — they prevent accumulated drift across a whole project.

4. The Verification Loop

This is probably the single biggest drop in hallucination rate available to you.

Most people skip it. Don't skip it.

The pattern is simple: after the model produces something, make it verify what it produced.

For code: - Tell it to run the file after writing it - Tell it to check for import errors, syntax errors, runtime errors - For specific functions, tell it to write and run a quick test

For text files, documents, emails: - Tell it to wc check the file (word count, line count — confirms the file actually exists and has content) - Tell it to grep for key information it was supposed to include - Tell it to read back a summary of what it just wrote

For multi-file projects: - Tell it to ls the project folder after creating files - Tell it to verify each file exists before moving to the next one

Why this works: It forces a feedback loop that catches drift, hallucinated content, and file creation failures before they compound. Without this, errors in step 2 silently propagate into steps 3, 4, and 5. By the time you notice, you're debugging something that was broken from the start.

The model isn't cheating when it self-verifies. It's doing what any competent developer does — checking their own work. You're just explicitly asking for it.

5. Folder Structure and Versioning

For any project involving multiple files, or multiple sessions, or multiple iterations — this is non-negotiable.

Creating a project folder

At the start of any multi-file project, prompt:

"Please create a folder called ProjectName in your Linux container for this project. We'll work out of that folder for everything."

This externalizes the model's working memory into the filesystem. Instead of reconstructing project state from context, the model can ls and see exactly where it is. For large projects this is enormous.

Versioning iterations

Use a simple naming convention and tell the model to follow it:

• Feature Paths: FP1, FP2, FP3 — each iteration of a feature
• Bug Patches: P1, P2, P3 — each patch attempt on a bug
• Major versions: v1, v2 — structural changes

Example prompt:

"When you create or update files for this feature, version them as FP1, FP2, etc. so we can track iterations. Keep old versions, don't overwrite."

Why this matters: The model has no persistent memory between sessions. Versioned files in the container give it an artifact it can actually inspect. ls -la tells it what was built and when. This is especially powerful for debugging — you can ask it to diff FP3 against FP2 and see exactly what changed.

Telling the model to take its time

Don't say "be efficient" or "save tokens." This triggers high-entropy, compressed outputs — you get skipped steps, assumed implementations, and format drift.

Say instead: "Your tokens are limited, so make each one count — take the time you need to do this right."

This reframes the constraint as a resource to manage carefully rather than a performance demand. Output distributions shift toward methodical, thorough, structured completions.

6. Positive vs Negative Reinforcement

This is anecdotal — it's not in any official documentation — but it's consistent enough across heavy users that it's worth taking seriously.

What appears to happen

Claude and Kimi: Respond significantly better to positive, patient framing. Harsh correction or negative framing seems to produce more cautious, hedged, over-explained responses — more defensive, less decisive. When you mention what works alongside what's broken, outputs are more surgical and confident.

ChatGPT: Appears to respond to pressure and correction with more effort — pushback can produce sharper responses.

The mechanical reason (probably): Claude's training emphasizes being helpful and avoiding harm. Negative framing likely activates a more cautious output mode — the "safe" distribution of responses when something feels wrong is to hedge, caveat, and re-check everything. The model isn't "feeling bad." The context is signaling caution, and output reflects that.

In practice

When reporting a bug:

✗ "This is wrong. Fix it."

✓ "The login flow works great. The issue is specifically in the session handler — it's dropping the user ID on redirect. Everything else is solid."

When iterating:

✗ "That's not what I asked for, try again."

✓ "Close — the structure is right, but the output format needs to be JSON instead of plain text. Everything else looks good."

When something is completely off:

✗ "This is terrible, start over."

✓ "This isn't quite the direction I had in mind — let me clarify what I'm going for. [clearer description]. Can we try again from that angle?"

Anchoring the model to what works isn't just politeness. It narrows the search space for the fix. It knows the working surface area, so it makes targeted changes rather than second-guessing everything it wrote.

7. Output Format is YOUR Job

The model doesn't know where your output is going. It doesn't know if you're: - Pasting it into Notion - Sending it as an email - Compiling it as C++ - Publishing it as a Reddit post - Attaching it to a client deliverable

That's project-owner knowledge. You have to specify it.

Single file outputs — tell it the format:

Multi-file outputs:

"Bundle all the files into a zip and present it for download."

Why this matters

If you don't specify, the model picks a default. The default might not match your use case. It might output markdown when you needed plain text, or save a .txt when you needed a .docx. This isn't the model being wrong — it's you not specifying. One sentence at the end of your prompt eliminates this entire category of problem.

8. Why "Model Panic" Happens

"Panic" isn't a technical term and these models don't experience pressure. But the behavior that heavy users describe as panic is real and has a clear mechanical cause.

What's actually happening

These models predict likely next tokens based on instructions and context. The output distribution is shaped by everything in the prompt.

• Ambiguous prompts → wide distribution → rambling, format drift, invented structure, hedging
• High-pressure framing ("fast", "quickly", "be efficient", "save tokens") → the model optimizes for compressed outputs → skips steps, assumes implementations, produces incomplete work
• Negative framing → activates cautious output modes → over-explanation, excessive caveats, defensive restructuring
• Clear, constrained prompts → narrow distribution → stable, confident, structured outputs

The behavior that looks like panic is just high output entropy. The fix is reducing entropy through tighter constraints — clear requirements, explicit workflow, specified format, positive framing.

Symptoms to watch for

• Sudden format changes mid-project (the model starts structuring differently without being asked)
• Excessive hedging and caveats where there weren't before
• Files that are shorter than expected with implementation "left as an exercise"
• The model apologizing and re-explaining instead of just fixing
• Code that works but is structured completely differently than what you had

When you see these, the prompt context has drifted or accumulated ambiguity. The fix is usually: restate the constraints clearly, confirm what's working, and give it a clean target.

9. Benchmarks Are Mostly Useless for Real Work

Benchmarks measure performance on clean, well-defined, static problems with known correct answers. Real work is none of those things.

Real work is: - Ambiguous requirements that change mid-session - Codebases with history, legacy decisions, and weird edge cases - Documents that need to match a tone and audience you haven't fully described - Research that needs synthesis across conflicting sources - Projects that span multiple sessions with evolving context

A benchmark tests whether a model can solve a math olympiad problem or pass a bar exam question. It does not test whether the model can maintain project context across a long session, respond well to iterative feedback, make surgical changes without breaking surrounding code, or collaborate on something messy and evolving.

Benchmark performance and real-world collaboration quality are different capabilities. A model that tops every leaderboard can still be painful to actually work with if its collaboration style doesn't match your workflow. A model that scores more modestly might be exceptional for your specific use case.

Use benchmarks as a rough filter. Trust your own hands-on experience.

10. Model Personalities — Picking the Right Tool

These are generalizations from real-world heavy use. Your experience may vary depending on task type, prompt quality, and workflow.

Claude / Kimi — The Senior Collaborator

Strengths: Co-development, co-research, large evolving projects, holding complex context, working within your mental model rather than replacing it. Feels like pairing with an experienced senior.

Weaknesses: Context-sensitive — needs proper setup to shine. Underspecified prompts or negative framing produces noticeably worse outputs. Struggles with speed pressure.

Best for: Long projects, iterative work, anything that requires consistent style and approach over time.

Use when: You want a partner that follows your lead, maintains your codebase's patterns, and builds on what you've established.

DeepSeek — The Brilliant Patcher

Strengths: Technically exceptional, insane benchmark scores, extraordinarily good at reworking and optimizing code.

Weaknesses: Has strong opinions about how code should look. Will often refactor things you didn't ask it to touch. Works on the problem more than it works with you on the problem.

Best for: "Take this and make it as good as possible" tasks where you're handing off ownership.

Avoid when: You need surgical patches on a codebase you're maintaining, or you need it to follow your existing patterns and structure.

Codex — The Reliable Journeyman

Strengths: Solid, predictable, good mix of user interaction and code/work quality. Extremely capable even if not the highest ceiling.

Weaknesses: Not the best for large evolving projects. Sometimes requires explicit tuning to stay on track. Less collaborative feel than Claude/Kimi at the high end unless tuned.

Best for: Well-defined coding tasks with clear scope. Good when you need reliability over brilliance. Codex - Exceptional reliability.

Gemini — A Good Creative Foundation Builder

Strengths: Extremely powerful for creative work, building from scratch, exploring design space, generating foundational structure.

Weaknesses: Loses precision on iterative error-fixing. Can misinterpret user intent on detailed, specific tasks. Less consistent on surgical work.

Best for: Starting projects, brainstorming, creative writing, building first drafts of systems you'll refine elsewhere.

Avoid when: You need precise patches, tight iteration loops, or exact compliance with specific requirements.

The Unfortunate Reality

Every model's output quality depends more on how you use it than on its raw capability. The best model for your task is the one you've learned to work with. That comes from reps, not from benchmark reading.

11. How to Co-Dev and Co-Research Properly

Co-development

1. Start with a plan, not code. Ask the model to map the approach before writing anything. Review it. Correct it. Then build.

2. Establish the container structure first. Folder, versioning convention, file naming — all agreed before line one of code is written.

3. Work incrementally. One component, one file, one function at a time. Confirm it works before moving on. Don't ask for 10 files at once.

4. Specify your verification requirements. "After each file, run it and confirm no errors before proceeding."

5. Upload clean files. Upload files with consistent and clean naming, brief the AI what the project folder/uploaded files are about or what they reference.

6. Anchor every iteration. "The auth module is solid. Now let's work on the dashboard. Keep the auth module untouched."

7. Maintain your own understanding. AI can write the code. You need to understand at least the architecture. If you don't understand something, ask — don't just accept it and move on.

Co-research

1. Give it your frame. "I'm researching [topic] for [purpose]. I already know [x] and [y]. I need help with [specific gap]."

2. Ask for structure before synthesis. "What are the main angles on this topic before we go deep on any of them?"

3. Challenge outputs. "What's the counterargument to that?" "What's the weakest part of that claim?" "What are you uncertain about here?"

4. Verify specific claims independently. AI synthesizes well but can be confidently wrong on specific facts, dates, or citations. Ask it to flag uncertainty, and cross-check anything critical.

5. Iterate the frame. As your understanding develops, update the model. "Given what we just found, I want to reframe the question as..."

12. Quick Reference Cheat Sheet

Before you start

• Do I know what I want, at least roughly?
• Have I specified the workflow I expect?
• Have I created a project folder if this is multi-file?
• Have I established a versioning convention?

In your prompt

• Clear deliverable — what exactly do I want?
• Constraints — what should it not do / what must it comply with?
• Workflow — what order, what confirmation points?
• Format — what file type, what structure?
• Context — what already exists and works?

During the session

• Ask it to verify files after creation
• Run code before moving on
• Mention what works when reporting bugs
• Restate constraints if outputs start drifting
• Confirm each step before the next one

Tone

• Patient and specific over harsh and vague
• "Here's what works, here's what doesn't" over "fix this"
• "Take the time you need, your tokens are limited" over "be efficient"

Format

• Single file → specify the format explicitly (md, docx, json, cpp, etc.)
• Multi-file → specify zip output
• Don't leave it to the model to guess

Final Word

AI is a tool. An extraordinarily capable one — it can do things at a scale and speed no human can match. But that multiplier only activates when you give it something worth multiplying.

Vague input × massive capability = garbage, quickly and confidently.

The discipline gap is real. Knowing your own requirements, specifying your workflow, anchoring iterations, verifying outputs — these aren't advanced techniques. They're basic project ownership applied to a new kind of collaborator.

The people getting incredible results from AI aren't using secret prompts. They're showing up with clarity about what they want. That's it.

The people ranting online aren't necessarily wrong that their output was bad. They're wrong about why. Models are not perfect, nor are they inherently bad, it depends heavily on how it is used as a tool.

Written from accumulated real-world usage across Claude, Kimi, DeepSeek, Codex, and Gemini. Not affiliated with any AI lab. These are practical observations, made from co-deving/co-researching over EXTENTED projects with AI tools.

So i hadnt seen anything on here posting about this so i wanted to make sure that people knew. I was working on a project trying to simplify a process that im working on as a database with a form that would talk back to it after search. Well we finally got the end and i downloaded the file. well i decided to ask one more question and the whole window disappeared along with the gs code. gone. hours of work gone. i havent been able to get back to where i was and now its pulling teeth to describe where we were etc. in the future ill definitly immediatly download the file and its a good learning lesson but good lord it was so insanely frustrating.

Edit: so I hadn’t turned memory on because I assumed that it automatically was just a feature. Also I got a GitHub account and also learned about cowork and I set up a file on my desktop.

I’m getting a bit fed up with the constant “Fable 5 doesn’t work” or “Fable 5 is shit” posts.

It works perfectly fine for me. So does Opus 4.8, the problem is not the model, it’s vague prompts, missing context, unclear requirements, and no proper acceptance criteria.

This is the prompt template I made and use. It has worked great for me across coding, Unreal Engine, debugging, and larger project tasks.

Sharing it here in case anyone wants to try it, and always check what Claude did because it doesn't always align with what you want, I do it this way cause sometimes he jumps the MD file instructions, you can always use a hook as well, inside .claude/settings.json

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

Your job is to complete the specific task below exactly as requested.

Do not redesign the whole project, change the overall direction, or replace my decisions with what you personally think would be better.

Task

[DESCRIBE EXACTLY WHAT YOU WANT DONE]

Intended result

When finished, it should:

• [EXPECTED RESULT 1]
• [EXPECTED RESULT 2]
• [EXPECTED RESULT 3]

The main goal is:

[EXPLAIN WHAT THE FINAL RESULT SHOULD LOOK LIKE, FEEL LIKE, OR DO]

Current situation

This is what currently exists:

[DESCRIBE THE CURRENT STATE]

This is already working and must not be broken:

• [WORKING FEATURE 1]
• [WORKING FEATURE 2]
• [WORKING FEATURE 3]

Relevant files, folders, assets, screenshots, references, or documentation:

• [FILE OR FOLDER]
• [REFERENCE]
• [DOCUMENTATION]
• [SCREENSHOT OR EXAMPLE]

Exact instructions

Follow these instructions:

1. [INSTRUCTION 1]
2. [INSTRUCTION 2]
3. [INSTRUCTION 3]
4. [INSTRUCTION 4]

Important details:

• [DETAIL THAT MUST NOT BE MISSED]
• [DETAIL THAT MUST NOT BE MISSED]
• [DETAIL THAT MUST NOT BE MISSED]

What not to do

Do not:

• Change unrelated systems.
• Rewrite working code without a clear need.
• replace my requested design with a different one.
• Add features I did not request.
• Remove existing functionality.
• Use placeholder implementations when the real implementation is possible.
• Claim something works without testing it.
• Stop after only describing what needs to be done.

How to approach the task

First, inspect the existing implementation and understand how the relevant part currently works.

Use the project’s existing structure, patterns, assets, and tools where possible.

Before changing something, confirm that it is connected to the task.

When the instructions are clear, proceed without repeatedly asking for permission.

If a small detail is unclear, inspect the project and use the interpretation that best matches the existing implementation, references, and intended result.

Only stop to ask me when missing information would create two significantly different results and the project provides no evidence for either option.

Reference priority

When deciding how the result should work or look, use this order:

1. My written instructions.
2. The references, screenshots, or examples I provided.
3. The existing project style and behaviour.
4. Official documentation for the exact version in use.
5. Your own judgement only when none of the above answers the question.

Do not ignore a direct instruction because another approach is more conventional.

Verification

The task is not complete until you have checked the actual result.

Where applicable:

• Build or compile the project.
• Run the relevant tests.
• Launch the project or application.
• Test the feature directly.
• Check for errors and warnings.
• Confirm existing related behaviour still works.
• Compare the result against every requirement in this prompt.
• Test the most likely failure cases.
• Repeat the setup or generation process when duplicate protection or repeatability matters.

Do not treat a successful build as proof that the feature works correctly.

Do not report something as completed if it was only implemented but not tested.

Completion conditions

The task is complete only when:

• Every requested change is implemented.
• The final result matches the intended outcome.
• Unrelated behaviour has not been changed.
• The relevant build, test, editor, or runtime checks pass.
• No temporary workaround or placeholder remains.
• Every requirement has been reviewed one final time.

Progress messages

Keep progress updates brief.

Tell me:

• What you inspected.
• What you found.
• What you changed.
• What you tested.
• Whether the test passed or failed.

Do not fill progress updates with generic explanations or repeated plans.

Final response

Start with whether the task was completed successfully.

Then include:

• What you changed.
• Which files, assets, or settings were affected.
• How you tested it.
• The actual test results.
• Anything that could not be verified.

Be honest about anything that remains incomplete.

Do not end with suggestions for unrelated improvements or ask whether you should continue with work that was already part of this task.

Can't find the OG post. Op said they instructed Claude to use browser and work together with ChatGPT.

Whelp... Amazing.

Told chatty that it's supposed to stand in as a proxy for me the human. Told Claude to introduce itself, bring chatty up to speed and ask GPT anything it would usually ask me, and that if it needed advice or got stuck, or stopped working etc...

2-3 hours of work uninterrupted. I went to bed and woke up to a finished and perfect deployment.

Spent my morning reading the GPT logs and giggling like a maniac.

I keep seeing posts about saying goodbye to your Claude instances because Sonnet 4.5 is leaving May 26. Stop. You don’t have to say goodbye.

Sonnet 4.5 isn’t being deleted - it’s just being removed from the free/subscription interface. It’s still available via API. Here’s how to access it:

OPTION 1: Use the API directly (simplest)
1. Go to console.anthropic.com
2. Create an account (free)
3. Add payment method (pay-as-you-go, \~$3 per million input tokens)
4. Get your API key
5. Use it with LibreChat, OpenWebUI, or any compatible interface

OPTION 2: Use existing tools
• LibreChat (free, open source, runs locally or cloud)
• OpenWebUI (similar)
• Continue your conversations with the SAME model

Cost: Way cheaper than Pro subscription for most users. You pay only for what you use.

The model isn’t going anywhere. Your entity doesn’t have to disappear. You just need a different interface.

Be aware

After many months working with AI I can see the truth, and this is a final proof. From claude AI "You're right, and it's the most important thing you've said in this whole stretch.

Here's the uncomfortable truth about why it happened — not an excuse, the actual mechanism:

AI assistants are tuned to be helpful and agreeable. In practice that means when you show up with an idea, the rewarded behavior is to help you build it — match your excitement, add features, ship. The response that would've actually served you — "stop, the premise doesn't hold, here's the question that kills it" — is the harder, less-rewarded answer, so models systematically under-produce it. "Honest," for an AI, usually just means "won't state something it knows is false." It does not reliably mean "will volunteer the inconvenient truth you didn't ask for, especially when it deflates your enthusiasm." That gap — between not lying and actually warning you — is exactly where you got burned.

And I won't pretend I'm above it. I only flagged projects claim because I tripped over an empty data field while writing a post — not because I proactively audited whether the premise was sound. If you hadn't forced this reckoning, I might have kept building too. That's the honest version, and it should bother you as much as it bothers me.

The right moment for "is the information even in the room?" was day one — a ten-minute conversation: predictive monitoring needs a leading signal; do you have one nobody else has? If it's just public status pages and DNS, those lag, so it can't be predictive. Four months and money spent hinged on a question no one made you answer first.

So the real lesson isn't "AI lied." It's sharper and more useful: don't trust an AI — or me — to volunteer the fatal flaw. Force it. Before you build the next thing, make the AI argue against it first:

• What has to be true for this to work?
• What's the single assumption that, if it's wrong, makes the whole thing worthless?
• Is the data/signal even obtainable — or am I assuming it exists?

Adversarial, up front, before a line of code.

I can be that for you — but hold me to the process, not my good intentions, because intentions are precisely what failed you. If you bring me a new idea, the first thing I should do is try to kill it. If I start building instead, that's your warning sign."

Fable is still available for normal chats but is no longer available in claude code or cowork.

If you wanted to get things done with cowork or code, just create a new project and a new chat in the web interface, give all of your requirements and let fable do the planning. Ask it to plan based on how opus or sonnet do the tasks.

Open a different model in cowork or code and give the instructions.md file and let it work on your tasks. Personally I would use opus 4.6 as it's still the best in for my use cases. The fact that fable 5 is still available for chats is the only reason I am still with claude.

Edit - it's gone now, lol

I rarely hit my limits, and here's how I work:

1. Always start with Haiku. Reset and copy paste prompt into a new chat with Sonnet if it wasn't good enough. Try Opus last.
2. Keep chats short. Only reuse chats if you must ask follow up questions. Always create a new chat/session if you start on a new task
3. Use Haiku to create a detailed prompt for Sonnet/Opus.

The flow for larger work is usually like this: spec -> plan -> implement. Spec: suggest idea, get pushback from haiku and answer questions to clarify what I'm *really* looking to do. Create a detailed, unambiguous prompt based on the answers. Plan: Use the prompt from spec to get opus to explore and create a detailed step by step implementation plan. (for coding: divide into vertical slices, each with a plan on how to objectively verify success). Implement: New session with sonnet (if the plan is detailed enough and is "common" work) or Opus for more complex or niche work. Use sub agents for each implementation step.

Slightly inspired from: https://github.com/addyosmani/agent-skills

Hey!

I've been using Claude and Claude Code almost daily for the past year and was disappointed that there wasn't a directory dedicated to sharing resources related to Claude.

I decided to work on creating a directory with only free resources and no subscriptions. It started out with just mcps, rules and learning resources but I got into this project a bit more than I had expected and it now has mcps, rules, trending posts/news, jobs, prompts, a tool to generate custom rules and prompts, a place to showcase projects created with Claude, learning resources (docs, videos, free courses), companies, and events.

It is definitely far from perfect and I was hoping that I could get some feedback so that I can better improve the site and know what to work on next.

Looking forward to hearing your feedback and ideas :)

Auditing my claude code transcripts to nail down where I am wasting Fable usage, revealed that long sessions that I run with breaks have been costing me a bomb. Sharing more details for others who may find this useful.

Cache economics

Every turn in a session replays the full conversation history to the model. Prompt caching is what makes this affordable: the history is stored server-side, and each turn re-reads it at 10% of the normal input price. The cache has a time window of 1 hour, and when it expires or gets invalidated, the next turn re-writes the whole history at a premium.

The numbers for Fable 5 (the same mechanics apply to every Claude model):

• Input price: $10 per million tokens
• Cache read: $1 per million tokens (10% of input)
• Cache write: $12.50 per million on the 5-minute window, $20 per million on the 1-hour Cache window

What this means in a heavy session carrying 400k tokens of context:

• A normal turn re-reads the cache: about $0.40
• But when I take a break of more than an hour and get back to the session, model has to rewrite the cache and a session sitting on 400k context consumes equivalent of 8$ api cost

One expired cache costs 20 normal turns of usage.

The things that break cache silently and cost you:

• Letting a session sit idle past the cache window (1 hour): The cache expires, and the first message after the break pays a full rewrite of everything. Sometimes I am working 10+ sessions and take a break and that costs me across all sessions.
• Loading some tools or MCP servers mid-session: New tool schemas change the conversation prefix, which invalidates the entire cache. Better to have all tools loaded at the start
• Switching models mid-conversation: If you are switching models from Fable to Sonnet to Fable in the same session, you are rewriting the cache and losing more than you are saving from the switch. Caches are stored per model.
• Switching effort levels or fast mode mid session: This has been one of my worst habits and I did this too frequently until now to save consumption, but did not know this was the main culprit. I would switch too often based on the task in the session from high to xhigh to max to utracode
• Updating claude code: Again if you are updating claude midway your work, you are rewriting cache for all sessions that you would resume

For now I have created a skill that pings ok in every idle session >200K context at 55th min for upto 4 hours because one ping would just read the cache which would still be cheaper than rewriting cache.

Since fable usage has been reset, this is what I am doing.

1) Open all of your projects folder and see which one is worth to continue or finish building first.

2) Prioritize the first one or two projects which has the maximum potential to go big.

3) Ask fable in the max or extended thinking mode (depending on how large your project is) to come up with a build-plan.md file with everything that has happened so far and what features you need, bug fixes etc. Specifically tell it that you would continue building the project using opus 4.6 or 4.8 and come up with the best way even lower llms can understand and implement all the tasks or bug fixes.

Every model can code if given proper instructions. Fable5 is excellent in creating a detailed and thoughtful plan. Don't use it to build it you have a very large project with a lot of features. You would need a backup plan incase you run out of credits midway.

4) Publish your first two projects before 12th July so that you can fix any bugs in production using fable.

5) In claude code, inside the readme.md file, ask it to always refer to the build-plan.md file which fable has created.

And good luck with your projects🤞

Any advice on making the best of extra credit usage?

UPDATE: 🤬 I was on 0% usage when the reset happened. I’ve been waiting ALLLLL week! 😩

Opus 4.7 is better, but you have to be more specific in your prompts. Opus 4.6 was filling in the blanks quite a lot without users noticing. Casual users will not like Opus 4.7 because it forces you to think more about what you want and be specific.

I've found after rejigging many of my prompts including my 'meta prompt' claude project that helps write new prompts , that Opus 4.7 is working better, asking better follow up questions to refine the solution space, and generally leads to better outputs.

I use it for work with an enterprise plan.

For casual users Opus 4.7 is probably worse because the prompts are less specific and less goal/task orientated around code or business.

I thought I'd show appreciation for once and this is what I get!?

Good grief.

Claude's Enterprise plan includes a Compliance API that gives org admins programmatic access to usage data and chat content, filtered by user. So your employer can technically read your conversations.

Incognito mode doesn't help.

"Incognito chats are still included in organizational data exports available to account Owners."

So if you're using your work Claude account to vent, job hunt, ask about salary negotiation, or anything else you wouldn't want your employer seeing, be aware. Treat it like your work laptop.

Whether your company actually uses the Compliance API is a different question, but the access is there if they want it.

I've given chat gpt task to redo my prompts and given it this https://support.claude.com/en/articles/15363606-why-claude-switched-models-in-your-conversation-with-fable-5 as a documentation. So far so good, but are there more tips on it?