Kurt

AI hacker • builder • automations

[Kurt @0xkurt]

ANDREJ KARPATHY EXPLAINED WHY CLAUDE KEEPS FORGETTING YOUR PROJECT. IN ONE LINE.

On Dwarkesh's podcast he said what's in the weights is "only a hazy recollection of what happened in training time."

But "anything that you give it as a context at test time is directly in the working memory."

so stop hoping the model remembers. hand it the memory.

his LLM Wiki pattern does exactly that. one folder, Claude Code, no database:

→ raw/ — drop your sources: notes, docs, transcripts
→ wiki/ — Claude writes the pages and links them
→ CLAUDE.md — the rules for how the wiki gets built

then three moves:
→ ingest: "process the new file in raw/"
→ query: ask, and the answer comes from your wiki
→ lint: "health-check the wiki" — contradictions, stale claims, orphan pages

that last one is the step most setups skip.

full build in the guide below. bookmark it before your next fresh session.

[mojesko @mojeskoqq]

https://t.co/YBUeYgXyjc

[Kurt @0xkurt]

YOUR CLAUDE FORGETS YOU EVERY NIGHT. ONE MEMORY PLUGIN ALREADY HAS 116K STARS.

7 open-source memory setups for your agent, ready to clone tonight:

1. claude-mem · 116K stars
a second agent takes notes while yours works. the next session starts with a short index of what matters
https://t.co/qX0O7HAery

2. graphiti · 32.7K stars
a knowledge graph that tracks how facts change over time, and where each one came from
https://t.co/WJWOdglhcM

3. beads · 28.7K stars
Steve Yegge's fix for messy markdown plans. a dependency graph, so your agent always knows the next unblocked task
https://t.co/ocSp7Kfg9n

4. LifeOS · 19.8K stars
Daniel Miessler's open-source life operating system, built with Claude. current state → ideal state
https://t.co/95v9B2GJ3u

5. basic memory · 4.5K stars
everything lives as markdown files you and your AI both read and write. Claude, Codex, Cursor over MCP
https://t.co/brxQmN1dPX

6. my claude code setup · 2.7K stars
starter settings + a CLAUDE.md memory bank, with three ready templates
https://t.co/t61tzyc3a3

7. claudesidian · 2.6K stars
Obsidian vault + Claude Code starter kit. one /init-bootstrap writes your personal CLAUDE.md
https://t.co/3GVnmnC3od

don't want another install? Bober's guide below does it with plain folders and one CLAUDE.md.

save this before your next fresh session.

[Bober_smart @Bober_smart]

https://t.co/WRvaPXgqIa

[Kurt @0xkurt]

CLOSING CLAUDE SHOULDN’T MEAN WRITING THE SAME BUG REPORT TWICE.

You open a fresh chat and there you are again. “The header’s fixed. The row count is still wrong. Hang on, let me find the test.”

So for the clip I put three lines in projects/handoff.md:

→ done: the header no longer counts as data
→ open: a trailing newline makes 2 records look like 3
→ next: run node --test export.test.cjs

CLAUDE.md tells the new session where to look. Before it touches the code, I’d ask “Where did we stop?” If it can name the extra row and the command that reproduces it, we can get straight to the bug.

Bober’s guide has the full folder setup. I’d start with the one file you’ll be glad to open tomorrow.

[Bober_smart @Bober_smart]

https://t.co/WRvaPXgqIa

[Kurt @0xkurt]

5 PUBLIC REPOS I’D OPEN BEFORE WRITING ANOTHER CLAUDE.md FROM SCRATCH.

Most of my setup would come down to five things I want Claude to carry between sessions. The handoff, the spec, the proof, the notes, and the routine I keep repeating.

1. Matt Pocock’s handoff skill
Turn the conversation into a handoff another session can pick up. I’d save the current state and next step in projects/handoff.md.
https://t.co/LWUSnthsTX

2. Addy Osmani’s spec skill
Write the scope and acceptance checks before coding. I’d keep those in projects/spec.md so the next session knows what “done” means.
https://t.co/k6WjIJ9608

3. Superpowers verification
Run the check before claiming it passed. Save the command and result in notes/verification.md.
https://t.co/9g6Pbc7lCe

4. Kepano’s Obsidian skills
If you already use Obsidian, borrow the conventions for note properties and links. Put them to work in notes/.
https://t.co/EIQqoMarLB

5. Anthropic’s skill examples
Give a repeated routine its own SKILL.md. The examples show how to describe when it applies and what it should do.
https://t.co/Zgee9UohnO

Bober’s guide ties these together. Keep CLAUDE.md short and use it to tell Claude which file to open. When a decision changes, save what changed and why in decisions.md.

Try this before your next session. Write a three-line handoff with what works, what’s open, and the next step. Add “Read projects/handoff.md when resuming work” to CLAUDE.md. Open a fresh session and ask where to pick up.

[Bober_smart @Bober_smart]

https://t.co/WRvaPXgqIa

[Kurt @0xkurt]

ASK CLAUDE WHY YOU KILLED A FEATURE. MAKE IT SHOW THE FILE.

“Why did we drop guest checkout?” is a simple question until the answer is buried in a chat from three weeks ago.

I built a small demo around that problem. The decision log has the reason. Guest orders couldn’t be linked to verified accounts. The answer comes back with the file and heading. Then I ask who approved it. There’s no approver in the record, so the demo shows “Not recorded.”

You can set up the same workflow in Claude Code with a folder of Markdown. Paste this into Claude Code in an empty project folder ↓

“Show me a plan for a local project memory. Create notes/ for facts, people/ for contacts, and projects/ for status and next steps. Add a root decisions.md with a reusable entry for date, decision, reason, and approver if known. Add a short CLAUDE.md that tells you where to look.

When I ask about a decision, open the matching entry and cite the file and heading. If a field is missing, say it wasn’t recorded. Keep the sample entries clearly marked as examples.”

Then write down one real decision. Open a fresh session and ask why you made it. Follow the citation and check whether the entry supports the answer.

The globe in the video shows the lookup on sample files. Bober’s guide below walks through the folder setup in more detail.

[Bober_smart @Bober_smart]

https://t.co/WRvaPXgqIa

[Kurt @0xkurt]

STOP RE-EXPLAINING THE SAME PROJECT EVERY TIME YOU OPEN CLAUDE.

“Why did we stop sending daily emails?” should be a question about your project. Somehow it turns into a hunt through old chats, meeting notes and a doc nobody remembers naming.

Bober’s folder setup gives Claude Code somewhere to look. Start with three folders and two files in your project.

→ CLAUDE.md tells Claude where to look for each kind of question.
→ notes/ holds facts and research, one topic per file.
→ people/ holds the context you need before the next conversation.
→ projects/ holds what’s in flight, where you stopped, and what comes next.
→ decisions.md records what you chose, when you chose it, and why.

I made a small demo with a newsletter project. The question about switching to weekly emails leads straight to decisions.md. The entry says readers asked for fewer updates. The project page says what ships next. The decision log tells you why you’re doing it that way.

The demo reads sample Markdown in the browser. To try the folder setup in Claude Code, write down one real decision today. Put the path to that file in CLAUDE.md and tell Claude to cite the file and heading it used. In your next session, ask why you made the decision. Open the cited entry and check the answer against it.

Bober’s guide below has the folder layout and the map you can adapt. Start with the project you’re already tired of explaining.

[Bober_smart @Bober_smart]

https://t.co/WRvaPXgqIa

[Kurt @0xkurt]

ONE CHECK FAILED. WHY DID YOUR AGENT REDO THE WHOLE DAMN JOB?

Say you asked an agent to clean up customer records and export them. The data is clean, the duplicates are gone, and the CSV is missing one required column. Send the export back with the exact error. Keep the work that already passed.

That’s what caught my eye in Hoodie’s clip. You can see the work split into branches, each with its own check. Independent tasks can run side by side. When one fails, you fix that piece and recheck the outputs that depend on it.

Here’s where I’d put Jev. Code can check whether a column exists. But say the agent rewrites a customer email and the requirement is “keep the original delivery promise.” Give Jev the original, the rewrite, and three choices:

→ ACCEPT if the promise stayed intact
→ REWORK if the draft changed it
→ REVIEW if the evidence is unclear

The workflow decides what happens next. A rewrite gets checked again. A task that keeps failing lands in your queue with the reason it got stuck. You can pick it up from there without rereading the entire run.
If you want to try this on a task you already delegate, give your agent one instruction before it starts:

Write down what would make each part fail. If a check fails, show me the evidence and retry the part that caused it. Recheck anything that used its output.

The Jev article below gets into how to handle the judgment calls between those steps.

[kiosa @thegreatest_sv]

https://t.co/KVN1FmmPmy

[Kurt @0xkurt]

I WANT TO OPEN MY LAPTOP AND FIND THE BORING WORK ALREADY DONE.

You know that first part of the morning where you’re technically working, but mostly catching up? Opening tabs. Checking updates. Reading the same announcement in three places. Figuring out who needs a reply. Somehow the day has started and your actual project is still untouched.

That’s the part I want an AI team to take off my plate:
→ a morning brief with the useful updates and their sources
→ customer replies drafted and waiting for approval
→ a project update pulled from what actually changed
→ a short review queue for anything that doesn’t add up

One worker gathers the inputs. Another prepares the draft. A checker looks for problems before it reaches my desk. Jev can handle the small calls between them: is this a duplicate, where should it go next, is there enough information, or does a person need to look? The next worker gets the result of the previous step, so it doesn’t start blind.

Watch the meeting request in the demo. The requested time is 10:00. The draft says 11:00. That task gets held for review while the other work continues. The repeated update gets skipped. By the end, three drafts are waiting on the desk and the time conflict is still clearly marked.

That’s a morning I’d like to walk into. Open the brief, check the reply, fix the one thing that needs me. I want to spend my attention on those decisions instead of collecting all the pieces myself. And I want the unfinished work visible, without opening every draft to discover what went wrong.

The video is an original workflow mockup with sample jobs. The duplicate and time checks run locally; there are no live model calls or connected accounts. Sending and publishing stay behind approval.

I put a starter prompt in the first reply. Give it your own source files and try one morning brief manually. Check what it missed before adding schedules or more workers.

The Jev article below explains how to add the decision layer between those jobs.

[kiosa @thegreatest_sv]

https://t.co/KVN1FmmPmy

[Kurt @0xkurt]

YOUR AI AGENT CAN CITE A REAL SOURCE AND STILL MAKE THE CLAIM UP.

A real link. A real quote. A conclusion the source never supported. That can look perfectly convincing inside a finished research report.

TypeSafe has a Jev walkthrough that checks exactly this. Eight citations against one source document, with four deliberately bad examples mixed in. The published run flagged all four: a missing quote, a contradicted claim and two unsupported citations sent for human review.

The useful part is how the check works:
→ code checks whether the exact quote appears in the supplied source
→ Jev reads the surrounding section alongside the claim
→ it picks: SUPPORTS / CONTRADICTS / SAYS NOTHING
→ your code decides what to accept, reject or send to review

The quote can exist word for word and still fail the second check. That’s why attaching a URL to every paragraph is only the start.

Give a research worker a small output contract: claim, source, exact quote and section. Keep the check beside that record. An unresolved claim stays unresolved instead of quietly becoming a fact in your notes.

This was a small, controlled example. A model verdict can still be wrong, and checking a claim against a source doesn’t establish that the source itself is reliable.

That’s the Jev workflow worth trying: a writer produces a draft, a separate check challenges its evidence, and the report keeps the gaps visible.

Official walkthrough in the first reply.

[kiosa @thegreatest_sv]

https://t.co/KVN1FmmPmy

[Kurt @0xkurt]

STOP BURNING OPUS ON EVERY TURN. PUT IT ON CALL.

Opening files. Chasing call sites. Reading search results. A coding session can fill up with that stuff before the actual fix even starts.

Claude Code lets you run Sonnet as the main model and bring in Opus for a second opinion. Start here:

claude --model sonnet --advisor opus

Then give the routine repo work its own workers:
→ Sonnet owns the implementation and applies the changes.
→ Haiku maps the relevant files, traces callers and does a first-pass review in separate subagent contexts.
→ Opus is available as an advisor when the approach or a stubborn failure needs another look.

The flag enables the advisor. The Haiku workers need their own configuration. Paste this into that session:

“Propose three project subagents in .claude/agents, all using model: haiku and tools: Read, Glob, Grep:
1. mapper: find the files relevant to the current task.
2. tracer: follow callers and dependencies; return file paths and line references.
3. reviewer: review the supplied patch and test output; flag bugs and missing cases. Do not run commands or edit files.
Keep implementation and test execution in the main Sonnet session. Delegate narrow research tasks and ask workers for concise findings, not whole file dumps. Escalate uncertain findings back to the main session. Ask the advisor about an unresolved approach or recurring failure. Show me the proposed agent files before writing them.”

Now a messy search can stay in a worker’s context. The main session gets the findings and keeps working on the fix.

One catch: advisor calls read the full conversation and consume usage. Claude chooses when to call; you can request a consultation, but this isn’t a fixed three-checkpoint scheduler. Measure the setup on your own tasks. It can cost more than Sonnet alone.

Save the command and prompt together. Official setup docs in the first reply.

[NO1ennn @N01ennn]

https://t.co/6ygvfjDT0L

[Kurt @0xkurt]

@andreysuperior Would love to see the forensic breakdown—especially how the files were traced back to the flashlight app

[Kurt @0xkurt]

@Yoda0x “One job, not ‘help me’” is the best advice here. Clear roles make the whole setup easier to manage

[Kurt @0xkurt]

@kinderlayer Love this test. The linkage tells you more than the render ever will

[Kurt @0xkurt]

AI GENERATED A CPU DESIGN IN 5 HOURS. THE CHIP BUILT FROM IT RAN LINUX.

That’s the result reported by the researchers behind QiMeng-CPU-v1. I went looking for the source because “AI designs a chip” is a hell of a claim. Their 2023 paper describes a RISC-V processor generated from examples of how its inputs and outputs should behave.

The system uses those observations to build the circuit logic. The team reports generating the CPU design in five hours, then fabricating a chip that successfully ran Linux. They compare its performance with an Intel 80486SX.

The sequence matters:
→ examples of the required behavior go in
→ the system generates the circuit design
→ the design gets manufactured
→ software runs on the resulting chip

Those five hours cover design generation. Manufacturing takes its own time, and the performance comparison is with an older processor. Keep that scale in mind before picturing a replacement for today’s laptop CPU.

The broader QiMeng project goes after the software side too: OS configuration, compilers and optimized libraries. The 2025 overview says integrating all the components remains future work. That makes the next question worth watching: how much of the stack can be designed together, then checked together?

A generated chip design is impressive. Getting software to run on the physical chip gives you something much harder to fake.

Paper and project below ↓

[Codio @0xCodio]

https://t.co/L1qqCuhjV5

[Kurt @0xkurt]

YOUR SSD MIGHT BE FULL OF AI MODELS YOU DON’T EVEN USE.

A model you tried for one afternoon. Another Python environment. Package caches from projects you finished months ago. Then Windows tells you the drive is full.

I found Jharu: a free, open-source cleaner built around exactly this kind of developer clutter. Mac and Windows. The project’s own demo is worth a look:

→ scan the developer caches and see their sizes
→ open the ML models view and inspect individual downloads
→ review the usage flags before removing a model
→ check Python environments for duplicated packages
→ open the disk map and drill into the big folders

Hugging Face. Ollama. pip. npm. conda. Docker. The stuff that quietly accumulates while you’re building other things.

What caught my eye: the app explains the category and labels what needs review. Its docs also say unreadable folders are flagged rather than silently treated as empty. That’s useful when you’re trying to work out where the space actually went.

Cleanup goes to Trash or the Recycle Bin according to the project. Review the selection first; removing a model or environment can mean downloading or rebuilding it later. Moving files to Trash alone also doesn’t mean the space is already free.

Source: https://t.co/a0yRuHX81L

[Movez @0xMovez]

https://t.co/LCLhoxByi3

[Kurt @0xkurt]

@yurshevv The install order is a great touch. Much easier to try a clear setup than figure out where to start with 40 repos

[Kurt @0xkurt]

@Mavern_0x @makeugc She took “I’m on my way” to a whole new level

[Kurt @0xkurt]

@semichenkko “Wrap the slime around the pot” is such a good example of useful feedback

[Kurt @0xkurt]

HOLY SH*T. YOUR NEXT MOTION STUDIO STARTS WITH 7 GITHUB REPOS.

An animated product demo. A 3D character. A narrated explainer. Here’s a tool for each part of the job:

01 Remotion → build and render videos with code.
https://t.co/hXFuSEVhYV

02 Motion Canvas → animate diagrams and graphics in TypeScript, with a live preview.
https://t.co/rwbVVgIttA

03 Blender → model the scene, rig the character, animate it and render the shot.
https://t.co/aO9AqZOiCS

04 Natron → combine the layers, track elements and build the final composite.
https://t.co/KCjXj9qbCA

05 ComfyUI → build reusable node workflows for generating visual assets with the models you choose.
https://t.co/2iieil2dgz

06 Kokoro → turn the script into a voiceover.
https://t.co/BdHBaIqW2k

07 FFmpeg → mix the audio, resize the video and encode the delivery file.
https://t.co/en8fJ2Rb8r

Give your coding agent the brief. Have it help with scene code, timing and scripts. Pick the tools you need, render a first pass, then watch it and fix what feels off.

brief → assets → animation → composite → voice → export

Start with one 10-second scene. Get it looking good, then turn it into something you can reuse for the next video.

Check Remotion’s licensing terms and the models you load into ComfyUI before commercial work.

Save the list. The motion-design article below is the next read.

[eigen @e1genqq]

https://t.co/0eGSO29Jv0

[Kurt @0xkurt]

@Firrti Did you find full-resolution photos or mostly compressed thumbnails? And were they only visible in the unencrypted backup on the Mac, or also directly on the phone?