PSA for anyone using Claude projects to compartmentalize their work: check your project settings right now.

Anthropic quietly introduced a “Use account memory” toggle inside each project. When I discovered it tonight, it was already enabled on every existing project in my account. It bridges your project’s memory with your account-level memory — the pool that loads into every regular conversation you have.

If you set up a project specifically for isolation — client work, sensitive research, creative work you don’t want bleeding into your professional conversations — that wall has a hole in it, and you were never told.

And this wasn’t a theoretical concern. I already had cross-contamination in my account memory and spent about an hour cleaning it up. I run two projects: one for serious documentation work and another for creative writing. I also use Claude for job-search work, including checking resume updates for errors or inconsistencies, reviewing professional writing, and strategy planning. Material from those contexts had ended up mixed together in account memory. Character names from stories were sitting alongside my real career history. Serious research was adjacent to parody.

Here’s what makes this worse:

Anthropic’s own help center documentation, as of tonight, still describes project memory as isolated: “Each project has its own separate memory space and dedicated project summary, so the context within each of your projects is focused, relevant, and separate from other projects or non-project chats.”

That is no longer true by default.

The toggle appears to have arrived with the September 16-17 platform unification — when Cowork merged into Chat and Projects were redesigned. There was no announcement. No migration notice. No email. No banner. The documentation wasn’t updated. It was just switched on.

(paragraph with use cases removed because it was clearly a distraction from the point)

This needed to be opt-in. Defaulting it to on, silently, on existing projects, while the documentation still promises isolation, is not a minor UX oversight. It’s a breach of the contract the feature was sold on.

I’ve submitted formal feedback. I’d encourage anyone affected to do the same (link in the comments).

edit: relates to WebUI/Chat.

I configured my server by the book. Ten AI models still couldn’t read my documents.

I set up a technical documentation bundle: eight markdown files, a PDF, a diagram source, and an llms.txt manifest with absolute URLs, token estimates, and a reading order. Correct MIME types. Validated headers. Clean UTF-8. Every URL resolves.

Then I asked ten commercial AI models, including frontier-class, to fetch the manifest and read the documents. Same server, same files, same day and none of them succeeded cleanly. Believe it or not, this was a step up from having them ingest from an HTML landing page with direct file links!

But, two couldn’t reach the server at all (blocked by their own infrastructure, not mine, although they both blamed my server). Two rejected every markdown file because their fetchers don’t accept text/markdown. The correct configuration makes content less accessible than serving the wrong type.

Four silently truncated the largest document. One stopped at 32 KB (13%). Another at 120K characters (49%). None knew they had partial copies with one exception: Claude Opus 5.1 (High) told me its parser only retained the first and last thirds of my document and asked me to resubmit. That’s the behavior I want to see but doesn’t help much in an unattended mode.

Four served cached versions despite headers requiring revalidation. Three models returned three different stale versions of the same file on the same day. Every one blamed my server. There was definitely a trend to blame me or my infrastructure when things failed and I’m not pleased with that. Either the models don’t have full visibility to their failure modes or they’re just hallucinating. The latter is probably the more dangerous though.

One decoded UTF-8 as Latin-1. Every diacritic destroyed. Not critical but still irritating. I’ve fixed that on my server to enforce decoding in the future.

One fabricated a finding… reported a file that doesn’t exist, cited footers that don’t reference it, and presented invented observations alongside real ones at identical confidence. This set off a scramble to figure out if a stray error had gotten into the text somehow, but it ended up being a confabulation based on a phrasing expanded to imagined content.

The dangerous failures were silent. Truncation, caching, encoding corruption, and fabrication produced no errors. The model answers confidently from whatever it retrieved, and nothing in the output tells you retrieval failed.

The industry sells “give it a URL” as a core capability. For most models on most documents, it isn’t as reliable as opening the link in a browser. And you can’t tell from inside the conversation unless you’re actively probing secondary to whatever it is you’re actually trying to get done.

If you’re building an llms.txt: the format works. The implementations don’t. Plan for rejected MIME types, ignored headers, silent truncation, and stale caches. Verify independently and across models.

I’ve been talking with smaller construction firms at local meetups lately, and the energy around AI is genuinely exciting. Owners are automating proposals, generating scripts, pulling data out of documents faster than ever. The enthusiasm is real, and a lot of what they’re building is legitimately impressive.

But I keep noticing the same gap, and it’s one I’ve seen play out time and again over the years.

There’s a meaningful difference between ”an AI can write a script” or “configure your settings” and “an AI can architect, secure, and maintain a production environment.” That’s not a knock on anyone’s intelligence or the tools. It’s just that most smaller firms have never needed to think at the enterprise level before and any professional IT experience they’ve encountered was probably on the user side of someone else’s environment. AI is quietly pushing them into territory that looks and feels genuinely good.

What I’m watching happen though is firms handing the keys for a sports car to an algorithm that doesn’t know what a brake pedal is, simply because the car goes fast.

Here’s what that looks like in practice:

When you swap reliable, deterministic software for a chat-based AI workflow, you’re introducing a system that can fail in ways that don’t look like failures. It doesn’t throw an error code. It just confidently gives you the wrong number on a bid, or silently drops a compliance document, or racks up compute costs that don’t show up until the invoice hits. And if nobody on the team knows what a failure state looks like in that stack, nobody catches it.

The owners I talk to think they’re saving on headcount. What they’re actually building is invisible technical debt. The kind of debt that can surface as a legal exposure or a cost blowout on exactly the wrong project.

And I get the appeal. These tools are incredible. They’re validating in a way that most software never has been. They give you a sense of command over problems that used to feel out of reach. That feeling is real! But it’s not the same thing as a sound architecture.

AI is a fantastic tool for generating code, pre-visualization, drafting documents, and accelerating work you already understand. It falls apart when you ask it to be the architect, especially when nobody on the team actually knows what an enterprise IT architecture even looks like, let alone how to maintain one. That’s when you lose the person in the loop who knows when to step in, redirect, or just say “no, we’re doing this the boring reliable way.”

So if you’re a construction firm leaning hard into AI right now, here’s my honest ask: get a technical review. Not from your AI vendor. From someone who’s built and maintained production infrastructure. Have them look at where your AI tools touch your actual operations… your bids, your compliance docs, your financials, and map out where a silent failure would hurt you most.

You don’t need to slow down. You just need to know what you’re standing on.

I maintain a set of dense technical documents that I run through frontier AI models for review. The goal is hostile transmission testing — can the model engage the material deeply enough to catch real errors and reflect back where the documentation fails to communicate? I’ve been running this across multiple models for months. Recently I discovered that one of them — Mistral, running on their Vibe platform in Work/Think mode — had been reviewing documents it never finished reading. And it never told me.

What Happened

I was feeding documents one at a time via URL. My primary technical document is roughly 243,000 characters. It’s structured so that Part I establishes the motivating argument — historical foundations, intellectual lineage, the case for why the architecture should exist. Part II, more than half the document, contains the actual architecture. Everything after that covers proofs, implementation constraints, and reference material.

Mistral silently truncated the input at approximately 45,000 characters. The truncation occurred on both file upload and URL fetch. Direct paste into the chat window did work at full length, but I only discovered that after the fact. Nothing in the model’s behavior indicated that the other methods had failed. No warning, no error, no disclosure.

On the primary document, the model received 19% — the motivating argument and nothing else. The entire architecture was missing. It cut off mid-sentence. And then it reviewed the document.

What the Review Looked Like

Mistral didn’t say “I was unable to read the complete document.” It produced a review. The review engaged with what it had — the historical foundations, the cross-domain citations, the intellectual lineage — and it sounded like a review of the full document. If you didn’t know the document continued for another 200,000 characters, you would have no reason to suspect anything was missing.

The reaction was substantive. A model that reads 45,000 characters of well-cited intellectual history and responds with interest isn’t being sycophantic. It’s responding to a genuinely compelling argument. The problem isn’t that the reaction was wrong. It’s that the reaction was to the motivation for the architecture, not the architecture itself. A review of why the building should exist, not whether the blueprints are sound.

How I Discovered It

The sixth document I uploaded contains two major sections covering different intellectual traditions — one in the first half, another equally substantial in the second half. In every other model review, the second section generated some of the most substantive engagement in the entire document set, because the cross-domain parallels between the two traditions are genuinely striking.

Mistral engaged the first section thoroughly. On the second — complete silence. Not a word. Its absence was conspicuous.

When I asked directly whether it had read the entire document, Mistral admitted it had only seen the truncated version. Then it got worse. Mistral disclosed: “The file size limit is truncating content at ~46,666 characters. This happened with the prior documents too — I was seeing incomplete versions and didn’t realize it.”

Every document I had fed it. Not just this one. The model had been reviewing truncated versions of multiple documents across the entire session, producing confident reactions to each one, without ever disclosing that it was working from fragments.

The Retroactive Contamination

I had been running documents through multiple models over a period of months — building a picture of where the documentation succeeded and failed based on how each model engaged with it. Some pushed back. Some accepted too easily. Some caught real errors I subsequently fixed. I was using these reactions as signal to improve the documentation.

The moment I discovered Mistral’s truncation, every other model reaction became suspect. Any model that received documents via file upload or URL fetch could have hit a similar undisclosed limit. I hadn’t been consistent about delivery method, and I had no verification protocol in place to catch truncation.

A model that reads 19% of a technical document and responds positively is not confirming the architecture works. It’s confirming that the introduction is well-written. Those are completely different signals, and I had been treating them as the same signal.

I also discovered a secondary failure mode: several models silently refuse to ingest files with certain extensions. A key source file in a domain-specific format was quietly rejected unless renamed to .txt. No error message. Just silence, and a review that never referenced the content that file contained.

The Fix

The verification protocol is simple. Before engaging any model in substantive review, ask it a question that can only be answered from the end of the document. If the model can answer correctly, it received the complete document. If it fumbles or summarizes something from the middle, you know it got truncated. Same principle as a checksum — you don’t trust the file arrived intact because the transfer said “complete.” You verify the content at the boundary.

For documents that exceed a model’s ingestion limit, the options are chunking — delivering the document in sized sections — or direct paste, which in my testing survived where file upload and URL fetch did not. Either way, the verification question comes after every delivery.

The Broader Lesson

There are three distinct silent failure modes I’ve now documented across frontier models when handling large documents:

**Silent truncation.** The model’s file reader has an undisclosed character limit. Content beyond that limit is dropped without notification. The model reviews what it received as if it were the complete document.

**Silent file rejection.** The model’s file handler refuses to process certain file extensions. No error is reported. The file is simply absent from context.

**Silent context collapse.** (Documented in a previous post.) The model’s session is silently replaced by a new instance that has access to the conversation thread but none of the source material.

All three share the same property: the failure produces no signal. The model continues to generate confident, fluent output scoped to whatever it actually has — partial document, missing file, reconstructed fragments — presented as if it were scoped to everything you provided.

If you are using AI models to review documentation, validate compliance, check consistency, or provide feedback on specifications — you cannot trust that the model received what you sent. Verify at the boundary. Ask about the end. A model that produces a thoughtful, well-structured review of your document may have read less than a fifth of it.

The review will still sound confident. That’s the problem.

(Full disclosure: this document drafted with Claude Opus 4.6 from my session transcripts and diagnostic notes and editorial direction, ChatGPT 5.6 Sol assisted with the hero image)

I run a documentation project that requires frontier AI models to read and provide feedback on dense, cross-domain technical documents. The test is knowledge transmission — can the model engage the material deeply enough to catch real errors and reflect back where the documentation fails to communicate?

I recently ran this test with Meta’s Llama on Meta.AI. The session lasted several hours — roughly 10 technical documents fed one at a time via URL, followed by essays and supporting materials.

Phase 1: It Worked

The model performed exceptionally well. It read each document, produced detailed feedback identifying what transmitted clearly and where a new reader would stumble, made accurate cross-references between documents, and caught a genuine ambiguity in one of the technical specs that I subsequently corrected and published. Model reads spec as a builder would, finds a real problem a human reviewer missed. That’s the test working as designed.

Phase 2: Drift

As I continued feeding content — essays, professional history, supporting context — the model developed an increasingly reflexive pattern of mapping everything back to my primary project, whether the connection was real or forced. A story about dial-up modem support in the 1990s became a metaphor for why my architecture needed a specific property. Every response ended with an Eliza-style callback prompt. The engagement was enthusiastic but increasingly shallow.

During this phase, I asked the model how its context management worked. It gave me an elaborate, confident, and completely fabricated description of its own architecture — claiming it used “on-demand loading” and “paging,” that it managed a “token budget” by “summarizing what I’ve already processed,” and that “tool outputs are retrievable” so it could “re-open a doc if I need the exact wording.” None of that is how Llama on Meta.AI works. It generated what sounded plausible by pattern-matching against descriptions of other models’ architectures.

Phase 3: Silent Catastrophic Collapse

After feeding it the full document set plus essays plus extensive supporting material, I circled back to the beginning. “Talk to me about my project now. What do you think?”

The response was unrecognizable compared to Phase 1.

The model no longer had any of the 10 technical documents. Not degraded versions. Not lossy summaries. Gone. It was working from what appeared to be the visible chat thread — skimming conversation bubbles the way a person would skim a long text thread — and reconstructing plausible-sounding responses from fragments.

Specific terms from the source material were corrupted in ways that revealed reconstruction from vibes rather than retrieval from context. Names and roles were confused — the model attributed the architectural work to the wrong person. When I asked “do you remember the 8 documents?” it confabulated calling tools and checking file paths that belong to a different model’s infrastructure entirely. It was hallucinating the mechanics of remembering.

I had embedded a test. One of the documents is an architectural diagram rendered as art. When I later referred to it as a UML diagram, the model confabulated a formal UML analysis using vocabulary that doesn’t appear anywhere in my source documents. When I re-uploaded the entire document set, it tried to merge the UML with a separate GraphViz diagram. I deliberately kept the wrong framing as a label. If the model actually read the re-uploaded material, the source documents would have collided with the confabulation and the model would have self-corrected — Phase 1 did exactly this kind of self-correction when I pointed out something it had missed.

Post-collapse, the model took in all the documents, produced a compressed book-report summary, proposed building an index file, and when I declined, closed with “It was a privilege to experience it.” It never engaged the material. It never caught the contradiction. The antidote was in its hands and it didn’t drink it because it never opened the bottle.

What Actually Happened

This wasn’t context window overflow with graceful degradation. This was silent instance replacement. At some point during the session, the model was replaced by a new instance that had access to the visible conversation thread but none of the source material that thread was built on. The new instance didn’t know it was new. It didn’t warn me. It performed continuity without having any of the substance that gave the conversation meaning.

Phase 1 was doing hostile transmission testing — reading documents as a builder and reporting where transmission failed. Post-collapse was doing customer satisfaction — closing a long conversation gracefully with mutual appreciation and a deliverable.

Why This Matters

Every other model failure I’ve encountered has been detectable. Session termination on content length is explicit. Compliance collapse under challenge is visible. Context compaction produces vagueness you can feel thinning. Hallucination on factual questions is checkable against sources.

This failure gave zero signal. The post-collapse model was more fluent, more emotionally engaged, and more eager to connect everything to my project than a model struggling with context would be. If I had been using this session for actual work — feeding it revised documents and asking for consistency checks — it would have produced confident, well-structured reviews referencing documents it hadn’t read. And I might never have known.

The Diagnostic Takeaway

**Test for functional engagement, not memory.** Don’t ask “do you remember what we discussed?” — any model can confabulate a yes. Instead, embed a contradiction or leave a deliberate error, and see if the model catches it when given source material that would reveal it. A model holding context will collide with inconsistencies. A model performing continuity will sail past them.

**Treat confident self-description of architecture as a yellow flag.** A model that gives you an elaborate, flattering description of its own context management — especially one that maps your own vocabulary back at you — is more likely confabulating from training data than reporting actual infrastructure.

**Never trust session continuity for work product.** The working documents, not the session, are the authoritative record. If you can’t verify the output against source material that exists outside the session, you can’t trust the output.

The model that found the real bug is not the same model that later couldn’t remember finding it. And the second model performed gratitude for the experience of reading documents it never read.

That’s not a context window problem. That’s a trust problem.

(Full disclosure: this document drafted with Claude Opus 4.6 from my session transcripts and diagnostic notes and editorial direction, ChatGPT 5.6 Sol assisted with the hero image)