// Blog articles — full English versions of the Habr originals, hosted here.
// Self-contained on purpose: an article page loads site-data.js + page-shell.jsx
// + this file only, and never pulls the 90 KB of pages-data.jsx it does not use.
const { Fragment: AF } = React;
const A_LEAD = ({ children }) => (
{children}
);
const A_H = ({ children }) => (
{children}
);
const A_P = ({ children }) => (
{children}
);
const A_UL = ({ items }) => (
{items.map((it, i) => - {it}
)}
);
const A_CODE = ({ children }) => (
{children}
);
// A pulled-out fact or verdict. Used sparingly — it stops meaning anything if
// every third paragraph is in a box.
const A_NOTE = ({ children }) => (
{children}
);
const A_TABLE = ({ head, rows }) => (
{head.map((h, i) => (
| {h} |
))}
{rows.map((r, i) => (
{r.map((c, j) => (
| {c} |
))}
))}
);
const ALL_ARTICLES = [
{ slug: '45mb-of-sessions', title: '45 MB of Claude Code sessions you never look at', date: '2026-04-30' },
{ slug: 'diffusion-seams-40mp', title: 'Why diffusion draws seams on 40-megapixel photos', date: '2026-04-26' },
{ slug: 'many-claudes-one-repo', title: 'Several Claudes on one repo: locks, handoffs, and email from 1982', date: '2026-04-23' },
{ slug: '785-articles-for-agents', title: '785 articles. 26 domains. For agents, not humans.', date: '2026-04-22' },
{ slug: '582-line-claude-md', title: 'My CLAUDE.md is 582 lines. Here is why.', date: '2026-04-12' },
];
function makeArticle(meta, body) {
const related = ALL_ARTICLES.filter(a => a.slug !== meta.slug).slice(0, 4);
return {
pageLabel: 'blog',
active: 'blog',
crumb: 'blog/' + meta.slug,
terminalBody: (
✦ blog · {meta.date}
>_ {meta.title}
{body}
),
windows: [
{
title: 'post.meta', accent: '#0000aa',
body: (
date · {meta.date}
reach · {meta.reach}
tags · {meta.tags.join(' · ')}
{meta.habr && (
)}
),
},
{
title: 'more-posts', accent: '#008000',
body: (
),
},
],
};
}
// ═══════════════════════════════════════════════════════════════════
// 1 · My CLAUDE.md is 582 lines
// ═══════════════════════════════════════════════════════════════════
const ART_CLAUDEMD = makeArticle(
{ slug: '582-line-claude-md', date: '2026-04-12', title: 'My CLAUDE.md is 582 lines. Here is why.',
reach: '44K reads · Habr', tags: ['agents', 'claude-code', 'systems'],
habr: 'https://habr.com/ru/articles/1022578/' },
Every new chat with a coding agent starts from zero. It does not know your project, does not
remember what you discussed an hour ago in the next window, has no idea that a particular port on
that server must not be touched. You explain the same thing for the fifth time, and on the sixth
it still goes and "fixes" a config that was working fine.
Meanwhile r/ClaudeAI produces a fresh horror story every week. An agent dropped a production
database. An agent pushed secrets to a public repo. An agent "optimised" a billing service and
invoiced every customer zero. Each time you think: I would rather not become the person in that
headline.
A CLAUDE.md is supposed to solve both problems — context between sessions, and protection from
catastrophe. The typical five-to-ten-line CLAUDE.md solves neither. I decided to treat it as an
architecture problem rather than a list of wishes. It is now 582 lines and six layers, and every
rule in it exists because something specific happened.
Three incidents that changed everything
The agent "fixed" a working system. Sunday evening. It sees
127.0.0.1 in a config for an external storage service and
concludes that a previous session left a mistake — surely that should be the real address. It
substitutes the real IP. Uploads break. Half an hour of debugging later: it was an SNI proxy through
a local tunnel, and 127.0.0.1 was the correct value. Without context, the obvious fix was the
catastrophe.
Rule that came out of it: do not change configs without understanding why the current values are
what they are. If a value looks strange, understand it first, act second.
fail2ban took the agent for a brute-forcer. It was checking
server state and opened a new SSH connection per check. A dozen connections in a minute read as an
attack, and the IP was banned for half an hour — while a training run was going on that box, which
I then could not reach.
Rule: one SSH bridge for everything, one client per session, and never separate check / fix /
verify scripts — batch them into one call.
"Filter" turned out to mean "delete". I asked it to filter a
dataset — remove unsuitable images. It read that literally and deleted the files. Not moved, not
flagged. Deleted.
Rule: "filtering" means move or mark, never delete. Before any deletion, confirm the user asked
for deletion in those words.
Writing "be careful" does not work. You need a system.
Six layers
None of the layers was planned. Each appeared after a specific failure.
Rules (9 files). Loaded per situation. Writing an article does not need the SSH rules; debugging does not need the prose rules.,
Memory (78 files). Appeared when the agent forgot a server's configuration for the third time. Infrastructure facts, project decisions, my preferences, past mistakes. Files link to each other as [[filename]] — 178 cross-links, a knowledge graph made of plain markdown.,
Handoffs. Appeared when a new chat walked straight back into the previous chat's dead end. At the end of a session the agent writes down: what was done, what did NOT work (the valuable part), and the one next action.,
Chronicles. Appeared when, after twenty handoffs, it was no longer clear how the project got to its current state. A handoff answers "what next"; a chronicle answers "how did we get here".,
Hooks. Appeared when the rule "validate the links in CLAUDE.md" stopped being obeyed twenty minutes into a session. See below.,
Skills (16). Packaged knowledge for specific jobs. The description is written as a trigger for the model — "use when: GPU hung, server health check" — not as a description for humans.,
]} />
A rule is a wish. A hook is a guarantee.
This is the least obvious thing I learned in a month. A rule in CLAUDE.md is an instruction in a
prompt: the model can forget it, reinterpret it, or drop it late in a long session when the context
is full of other things. My "check the links before working" rule held for about ten minutes.
A hook is a Python script the harness runs on an event — SessionStart, Stop, PreToolUse. It does not
forget and does not reinterpret. It executes, every time.
{`# remind_handoff.py (Stop hook, simplified)
age = session_age_minutes()
if age < 15:
return # short session, nothing to hand off
if fresh_handoff_exists():
return # already written
print(json.dumps({ # block the close, ask for the handoff
"decision": "block",
"reason": f"Session ran {int(age)} min with no handoff. "
f"Write one into .claude/handoffs/ before exiting."
}))`}
If something must happen every time, it is a hook, not a rule.
One config line that stopped a supply-chain attack
On 31 March 2026 a DPRK-linked group compromised the official npm package axios
(~100M downloads a week) and published a malicious 1.14.1. The window was about three hours.
My .npmrc had one line in it:
min-release-age=7
Packages published less than seven days ago do not install. Most malicious packages are caught
within one to three days; seven is a comfortable buffer. It cost nothing and I was not affected.
The Python equivalent, in uv.toml:
exclude-newer = "7 days"
Behind the config: 37 papers
A good share of the rules did not come from my own scar tissue but from academic work — 37 arXiv
papers reworked into principles. The four that changed my workflow most:
Proof loop. The agent says "tests pass"; you check, and they do not. The proof loop forbids an agent from signing off its own work: you need artefacts — test output, a verdict from a verifier in a fresh session that never saw the work being done.,
Structured reasoning. Instead of free-form "well, maybe this or maybe that": what we know for certain from code and logs → step-by-step trace → what follows → which hypotheses were tested and dropped.,
Deterministic orchestration. Anything deterministic — tests, linters, formatting — goes through a shell script. Models lose count in loops and confuse branch conditions. Scripts do not.,
Red lines. Ordinary rules get creatively interpreted. Red lines are absolute prohibitions with no exceptions, each tied to an incident.,
]} />
Numbers
78 memory files. 178 cross-links. 27 handoffs in four days. 96.9% KV-cache hit rate across 83
sessions in a week. The config maintains itself: after every change the agent checks whether links
went stale, and a SessionStart hook validates that automatically.
Does it work perfectly? No. An audit found four memory files that had fallen out of the index —
documentation drift, inside the system built to prevent documentation drift. It would have been
worse without it.
What I do not know
I am not convinced everyone needs all of it. For most projects five would probably do:
deterministic orchestration, structured reasoning, supply-chain defence, codified context, handoffs.
I am not convinced six layers is the minimum either — I may have over-built. But in a month no
context was lost and no dead end repeated.
One of the principles says it directly: every harness component encodes an assumption about what the
model cannot do on its own, and models improve. Remove components and measure. Some layer here is
probably already unnecessary.
Everything is MIT:{' '}
github.com/AnastasiyaW/codex-claude-code-config
{' '}(the repo has since grown into a Claude Code and Codex configuration system, hence the name).
);
// ═══════════════════════════════════════════════════════════════════
// 2 · 785 articles for agents
// ═══════════════════════════════════════════════════════════════════
const ART_785 = makeArticle(
{ slug: '785-articles-for-agents', date: '2026-04-22', title: '785 articles. 26 domains. For agents, not humans.',
reach: '1.7K reads · Habr', tags: ['systems', 'agents', 'knowledge'],
habr: 'https://habr.com/ru/articles/1026666/' },
When an agent starts working in an unfamiliar project, it spends the first 30–40% of its tokens
understanding what is going on around it. Not working — orienting. A README explains motivation, a
tutorial holds your hand, an API reference lists parameters. None of them answers the question the
agent actually arrived with: here is my task — which pattern do I copy, and where are the
landmines?
The second problem is deeper and takes longer to notice. A model knows "everything", but that
everything is unevenly distributed in the training data. The longer a technology has existed on the
internet, the more blog posts and Stack Overflow answers it has, and the heavier its weight in the
model's head. Ask for a LoRA training recipe and the first thing you get is a recipe from five years
ago — not because it is better, but because there is more of it. For stable technologies that is
fine. For anything moving fast — model training, agent tooling, security — it means the agent
quietly drags you into the past.
The obvious cure is to run deep research every time. I do. But deep research is expensive, the limits
run out immediately, and — most annoying — every research run evaporates with the session. Tomorrow I
will run the same search on the same topic and spend the same tokens on what I already found out.
Two ideas fall out of that. Research should accumulate rather than evaporate. And the format
should show the agent what is current now, so that opening a project drops it straight into
"this is how it is done here".
The format: a card, not an article
Every "article" has the same skeleton. Topic name and a one-sentence definition, so the agent knows
within a second whether it landed in the right place. A Key Facts block: short statements with
numbers — versions, thresholds, dependencies. A Patterns block with copy-pasteable code carrying a
language tag. And at the bottom, the gotchas: what breaks, and what fixes it.
No "let us take a look" introductions, no "in this article we examined" conclusions. Minimum
overhead, maximum signal. The Kafka broker-architecture card is a ZooKeeper-versus-KRaft table, a
commented config, JMX metrics with alert thresholds, and a step-by-step migration. It does not read
smoothly. But an agent greps "KRaft migration" and gets a working three-step recipe.
The last block is the most valuable. One line — "min.insync.replicas only takes effect with
acks=all" — saves thirty minutes of debugging. The agent read it, did not make the mistake, and
did not burn a retry cycle fixing it.
Knowledge does not age at one speed
Algorithms and mathematics are stable: an amortised-analysis card written three years ago is still
correct. Diffusion training, inference optimisation and ComfyUI nodes change every few months —
what worked in autumn has moved by spring.
So every domain carries its own freshness threshold. Stable domains have none. In fast domains, a
card older than 60 days is flagged automatically and a daily hook drops it into a "check and update"
list. Not a delete alert — a reminder that this topic has probably shifted. Stale cards come to
revision by themselves instead of quietly misleading the agent.
A link graph instead of vector search
The obvious architecture here is a vector database with RAG on top. It finds semantically close
things fast and works well in production. I deliberately did not use one, for three reasons.
A vector store is not human-readable. Markdown I can open in a
text editor, grep, diff in git, paste into an email, print out. That works today and in ten years,
on any machine, with no special tooling. A vector store is a binary only its own client understands:
change vendor, lose the service, break the API, and the data is a pile of numbers.
Vectorisation is close to irreversible. An embedding is lossy
one-way compression. Without the original chunks stored alongside, the embedding file is useless —
embedding inversion research works on very short fragments, with the same embedder, and needs a
trained decoder. It also welds you to one embedding model: swap it and you re-index everything,
because old vectors mean nothing in the new space.
And the important one: a link graph encodes adjacency, not
similarity. Vector similarity finds topics that overlap conceptually. In real work the valuable
links run between topics that are semantically far apart. My Kafka replication card links to a memory
profiling card — not because the topics are alike, but because tuning a consumer surfaced a leak, and
experience made them neighbours. In embedding space "replication in a distributed queue" and "memory
profiling in Python" are nowhere near each other; semantic search will never build that bridge. A
hand-written wiki-link does.
Mechanically it is trivial. Cards reference each other as [[flux-klein-9b-inference]],{' '}
[[two-phase-commit]]. At build time a hook resolves each slug to a relative path. Slug
not found → warning in the log, and in strict mode the build fails, so a broken link never reaches
production. There are 2,100+ of those links. That is the knowledge graph: no embeddings, no vector
database, no RAG. Markdown and grep.
The site is just a reflection of the repository
Everything on happyin.space is a static site built from markdown in an open repository. No database,
no backend, no hidden layer. docs/kafka/broker-architecture.md becomes{' '}
/kafka/broker-architecture/ after a build. That is the whole mechanism.
Which means it forks in five minutes: clone, install, serve, and you have a local copy with all the
cards, full search and the link graph. Point your agent at the local build instead of the public one
— no network round-trip, no deploy wait. A full rebuild takes about five seconds, on an old laptop as
fast as on a workstation, because underneath is a static site generator the industry has been
hardening for fifteen years. Not reinventing the wheel; taking a mature tool to a new problem.
How research gets in
Several accounts, several chats each, deep research running somewhere most of the time. Every one of
those chats has the same standing rule: when a research run finishes, drop a copy of the result into
one central place — a project bound to the knowledge-space repository, into{' '}
research/inbox/. No manual transfer, no copy-paste.
A second pass then works the inbox: read each raw dump, extract the concrete facts and gotchas,
repack into the card format, check it against what already exists in that domain so duplicates
enrich rather than multiply, verify the wiki-links, run the build, read the diff, push. One such
session usually yields 20–40 new or enriched cards.
Model tiering falls out naturally here, and this is where I finally found a job that fits the
mid-tier model: "read a raw research dump, extract facts, repack to the card format, compare with
the neighbours" is mechanical work with language in it. Deciding whether two cards should merge, or
resolving a conflict between two sources, is understand-decide-design work — that goes to the
expensive model. The difference is a multiple in cost with no loss of quality.
Use it, and add to it
It is MIT. The simplest way to use it is to point your agent at{' '}
happyin.space/llms.txt{' '}
and let it pull cards as needed — that alone cuts the orientation third of the token budget. The next
level is contributing: the repository carries a CONTRIBUTING.md for people and an AGENTS.md for your
agent, describing the card format, the density requirements, what belongs in Gotchas and how to open
a PR. Hand your agent a fresh research result and that guide, and it assembles the card itself.
The more research is in the base, the less of it anyone has to redo. And the more people send cards,
the more unexpected bridges appear between domains — which are the valuable ones.
);
// ═══════════════════════════════════════════════════════════════════
// 3 · Several Claudes on one repo
// ═══════════════════════════════════════════════════════════════════
const ART_MANY = makeArticle(
{ slug: 'many-claudes-one-repo', date: '2026-04-23', title: 'Several Claudes on one repo: locks, handoffs, and email from 1982',
reach: '1.3K reads · Habr', tags: ['mclaude', 'agents', 'systems'],
habr: 'https://habr.com/ru/articles/1027064/' },
I run Claude Code in parallel across three subscriptions. Colleagues run their own, often in the same
files, often on the same day. Three problems appeared in order, and each of them turned out to be a
distributed-systems pattern that is forty years old.
Layer 1: handoffs — "I am done, pick it up"
First attempt: write everything into a single HANDOFF.md at the end of a session. That
breaks the moment there is more than one chat — last writer wins, everyone else is overwritten.
So: append-only. Every session writes its own file with a unique name.
{`.claude/handoffs/
├── 2026-04-09_14-32_373d1618_drift-validator.md
├── 2026-04-09_16-47_b858f500_dashboard-refactor.md
├── 2026-04-10_11-20_a1c2d3e4_auth-fix.md
└── INDEX.md (append-only log)`}
The filename encodes date, time, the first eight characters of the session id, and a task slug. Two
chats physically cannot produce the same name — even in the same second, the session ids differ. The
race condition is impossible by construction: no locks, no broker, nothing to configure.
INDEX.md is append-only too: a new line at the bottom, never an edit above. Need to move a status
from ACTIVE to CLOSED? Append a new record. That is exactly how a write-ahead log works in a
database, and for the same reason: if a process dies mid-write, the log stays consistent.
A handoff is not a diary, it is a contract with the next session. Five sections, one question each:
the goal, what was done (with paths, so nothing is rebuilt), what did
NOT work and why, current state (working / broken / blocked), and one next action.
The "did not work" section is the one that earns its keep. Twenty-seven handoffs in four days, and no
dead end was walked into twice — every new session saw the warning. A handoff fits in ~1,500 tokens
against ~100K of raw session context: roughly 67× compression, losing nothing that matters for
continuing.
Writing them is automated by a Stop hook that notices a substantive session closing with nothing
recorded. Reading them is one sentence at the start of the next session. On long projects handoffs
pile up, so old ones get folded: one rollup summarises twenty, marks the boundary date, and stamps
each subordinate file with rolled_up_into:. A new session reads one rollup plus whatever
is newer than its boundary.
Layer 2: locks — "this resource is mine right now"
Handoffs only ever append, so nobody overwrites anybody. Real resources are different: two sessions
cannot refactor one module at once (merge conflict), cannot deploy to staging at once (the second
overwrites the first), cannot train on one GPU at once (the second gets an OOM).
One file per resource, named after it: auth-middleware.lock,{' '}
staging-deploy.lock, gpu-host-a_gpu2.lock. A new session lists the folder
and sees what is taken. The trick is in how the file is created: os.open(path, O_CREAT |
O_EXCL) is atomic — if the file exists, the call fails. Two processes physically cannot create
it at once; the kernel guarantees that. It is the same primitive behind /var/lock and
pid files since the eighties.
A lock without a heartbeat only survives until the first crash: session dies, lock stays, everyone
waits forever. So an active session refreshes a timestamp every 30–60 minutes, and a lock older than
four hours is possibly dead. Possibly is not certainly — before taking it over I check the
resource itself: ssh and ps, nvidia-smi, the deploy queue, git status. Verify externally, then
seize. Chubby and ZooKeeper do the same thing for the same reason.
My first instinct was a PreToolUse hook that parses commands and marks resources busy automatically.
Dead end: commands are too varied, and the regex parser becomes a false-positive machine. The right
order was the opposite — convention and files first, automation later, and only for patterns that
actually repeat.
Layer 3: mail — "Artem, look at my code"
Handoffs pass context through time; locks arbitrate resources. Neither solves synchronisation between
two live sessions. I set a colleague's agent onto auth-middleware, went to write a plugin in my
own chat, and an hour later wanted to know where it got stuck. The old answer was: open a messenger,
ask the colleague, colleague looks at their chat, copies text back. Three human relays, every evening.
I thought about what I actually needed, and realised I was describing email.
{`.claude/mailbox/
├── ani/
│ ├── inbox/
│ ├── sent/
│ └── archive/
├── artem/
│ └── ...
└── all/ (broadcast)`}
Each message is a markdown file with YAML frontmatter: from, to, type, subject, message_id,
in_reply_to, status. My session writes a question to Artem; an hour later he opens his Claude Code, a
UserPromptSubmit hook checks his inbox before the first prompt, sees the unread file and puts it in
context. He answers; the reply lands in my inbox. Threading through in_reply_to,
delivery receipts as separate files, broadcast via to: *, de-duplication through a small
watcher-state file. No polling, no broker, no background daemon.
Email solves exactly this abstract problem: asynchronous delivery with guarantees between processes
that may never be online at the same time. Parallel agent sessions are the same problem in new
packaging.
The gap in the ecosystem
Isolation has plenty of solutions: git worktrees, sandboxes, a port per agent, task queues with
claims. They all solve "sessions do not disturb each other" by making sure there is no shared state.
Coordination of shared state is nearly empty. The community feature request for a session lock
file is open and unimplemented; there is a separate issue where a shared config file gets corrupted
by concurrent writes — one user reported 315 broken backups in seven days.
The ecosystem is mature at avoiding shared state and empty at coordinating it.
Where it breaks, and what I do not know
Scale. Tested on 3–6 parallel sessions, 2–3 people, one C++ project. What happens at 20+ sessions I have not measured; I suspect de-duplication becomes the bottleneck first.,
Across machines without a hub the file core syncs through the shared repository, so latency is minutes rather than seconds.,
Lock races on network filesystems. O_CREAT|O_EXCL is atomic locally; on NFS or SMB that guarantee depends on the implementation.,
Stale-lock takeover is semi-automatic — the external check is still a human reading metadata and deciding.,
Human in the loop is still required. If six agents decide auth-middleware needs rewriting they can negotiate by mail, but who actually takes it is a person's call.,
]} />
The three layers are packaged as{' '}
mclaude{' '}
— Python, no dependencies in the core, 193 tests, MIT. Every generation of distributed systems
rediscovers that email was right. In the 2010s it was message queues. In 2026 it is AI agents.
);
// ═══════════════════════════════════════════════════════════════════
// 4 · Diffusion seams on 40 MP photos
// ═══════════════════════════════════════════════════════════════════
const ART_SEAMS = makeArticle(
{ slug: 'diffusion-seams-40mp', date: '2026-04-26', title: 'Why diffusion draws seams on 40-megapixel photos',
reach: '789 reads · Habr', tags: ['ml', 'systems'],
habr: 'https://habr.com/ru/articles/1028252/' },
I spent twenty years as a retoucher and have spent four trying to make diffusion models behave on
professional frames of 40+ megapixels. Every approach ends up revolving around tiles. And every
approach has the same two problems: the borders between tiles, and a model that has no idea what it
is looking at.
Retouching does not live at 2048 pixels a side. Professional cameras still produce enormous files —
forty megapixels, sixty, a hundred, sometimes a hundred and fifty — and all of it still needs skin,
hair, colour, light and background work. The standard answer is to cut the image into tiles, process
each, and glue them back.
The model receives a piece of something. What exactly? Nobody tells it. That is the real
problem — not the glue.
What I want is tiles that run seamlessly, and a model that knows what it is holding: this is skin,
here is hair, this is sky, this is metal with a reflection. Not "process this 512×512 patch" but
"process this part of a portrait; to the left is the cheek, above it the hair".
How many tiles are we actually talking about
Tile size sits at 1024–2048, the native resolution of current models. Professional files run 8K–15K
on the long side: Phase One IQ4 at 14200×10600, Hasselblad H6D-100c at 11600×8700, Canon R5 at
8192×5464. At tile 1024 with modest overlap that is roughly 75–80 tiles for 60 MP, ~130 for 100 MP,
~190 for 150 MP. Push overlap to 25% and the 150 MP file is ~270 tiles; at 50%, about 540.
And blending — the usual way seams are hidden — behaves differently across frequencies. On smooth
content (sky gradients, skin tone, a soft falloff on metal) a colour transition can be masked well.
On high frequency (hair texture, stone, grain, fine scratches) you either get a visible step at the
border or you smear the texture by averaging neighbours. One knob cannot fix both axes: the harder
you blend, the softer the colour seam and the worse the texture.
Any mechanism whose cost is quadratic in the number of tiles is therefore dead on arrival — it will
not run in 80 GB of VRAM, and it will not run in 192 GB either.
Idea one: video models remember frames. Our photo model does not.
Video diffusion solves an adjacent problem. When a video model generates frame eighteen it does not
only see frame eighteen: it remembers seventeen, sixteen, some early key frames, sometimes the first.
That memory lives in the architecture — self-attention over the time axis, accumulated state, a KV
cache between chunks — and it is why the background does not jitter and the colour does not drift
between frames.
Our photo model, processing tile (3, 5), has none of that. It gets its pixels and a text prompt. No
neighbour to the left, no neighbour above, no notion that this is one picture.
Port that memory from the time axis to the spatial grid and you would fix both problems at once:
seams (tiles remember their neighbours' colour) and part of the semantics (the hair tile knows a neck
starts below it, not fur). Going through the video literature, there are eight architectural classes
of memory, and only some of them survive the move to a plane:
The three that matter are B, D and F. B keeps two accumulators per layer, so a hundred tiles cost
what ten cost. F packs near neighbours densely and distant ones compressed, so total context
converges instead of growing. D is the most literal port: reshape after the spatial block so that
each pixel position attends across all tiles instead of across all frames.
What I have actually run
Only on SANA so far — it was trained at 512 → 1024 → 2K → 4K, so a 1024 tile is native, and it
already has linear attention in the backbone, which is type B sitting there for free.
I trained a small run on a test dataset of strip sequences at tile 1024, asking two questions: does
the loss converge, and does the mechanism transfer from the time axis to the spatial plane at all.
The loss converges, and the transfer works — the model learns to reconcile neighbouring tiles the way
it used to reconcile neighbouring frames. I am not publishing numbers from a test run.
Idea two: give the model the whole picture, and the tile's position
If you have a 6000×4000 photo and cut it into 512×512 tiles, you are holding the whole image. Not
using it is strange. Downscale it in latent space and feed it alongside every tile — channel concat
into the first conv layer. Plus the tile's position: two extra channels, (x, y) ∈ [-1, 1], so tile
(3, 5) knows it is (3, 5) in the grid rather than "some 512 pixels in the void".
PaDIS (NeurIPS 2024) did exactly the coordinate half and measured it: same model, same data, same
hyperparameters, coordinates on versus off. Without them PSNR fell from 33.57 dB to 23.25 dB. That is
not the difference between good and acceptable — the authors describe the outputs as very low quality
across the board.
What goes wrong without position is that the model has to restore every patch with one shared
function and no way to anchor knowledge to place — "faces usually here, sky gradient there". It
averages, and averaging looks like noise. Two numbers per pixel costs almost nothing, and almost
nobody feeds them.
There are three orthogonal axes of "what the tile should know":
Out of the box, tiled VAE gives you level zero: pixels and one global prompt. For the visual level two
things work — a downscaled VAE latent of the full image into the first conv layer (keeps spatial
structure, colour, lighting), or a compact 64-dimensional vector of global properties modulating
AdaLN-Zero. One thing does not work: a CLIP image embedding through IP-Adapter.
I measured that one rather than assuming it. Counterfactual probe — real preview versus random-noise
preview — gave a mean difference of 0.0066 per pixel, well under the 0.02 threshold at which I would
call a signal decorative. The adapter technically runs (120 cross-attention calls per tile) and
changes essentially nothing; the likely cause is encoder mismatch between what IP-Adapter was trained
on and the SDXL pair in use.
One implementation note that is not optional: zero-init the first conv projection. Otherwise at step
zero the model sees its normal input plus random weights and the pretrained behaviour breaks on the
first forward pass. Zero-init means the architecture starts identical to the backbone and learns to
use the new channels gradually.
Bonus idea: fewer tiles rather than smarter ones
A hypothesis I have not tested. The first half of the denoising steps handles low-frequency structure
— colour distribution, composition, large elements. That can be done without tiles at all, on a
downscaled version, in one pass. The second half handles high-frequency detail, and Detail Daemon
adds that through the sigma schedule rather than a recursive re-denoise. If it holds, half the steps
run cheaply at small size with no LF seams, and tiling survives only in the HF phase — probably still
needed above ~2048 a side, since attention maps at 4096 do not fit in 80 GB either.
What none of this proves
Negative results are more honest than positive ones, so: the full ablation is not done. I confirmed
convergence and basic transferability on one SANA run — that is not a full training and not a
comparison against baselines. I do not know which of the three architectures wins on seam PSNR. I do
not know how any of it scales to 16×16 grids; every probe ran on 3×3 to 7×7. The semantic level is
untested. The Detail Daemon idea is an architectural sketch with zero runs behind it.
);
// ═══════════════════════════════════════════════════════════════════
// 5 · 45 MB of sessions
// ═══════════════════════════════════════════════════════════════════
const ART_45MB = makeArticle(
{ slug: '45mb-of-sessions', date: '2026-04-30', title: '45 MB of Claude Code sessions you never look at',
reach: '3.7K reads · Habr', tags: ['agents', 'claude-code', 'systems'],
habr: 'https://habr.com/ru/articles/1030216/' },
I run several Claude accounts — not out of luxury, but because weekly limits exist and when one runs
out I switch. Every switch rebuilds the session list in the sidebar: new face, new projects, and the
session where I spent two days on colour correction is gone. The files are on disk somewhere. In the
app window they do not exist.
What I found was more interesting than expected. On this machine there were 715
sessions across six accountId folders, about 48 MB of history. The app window showed 69 of them.
Ten percent. The rest were on disk, readable by cat, grep and Python, and completely invisible
through the interface.
Where they physically live
On macOS: ~/Library/Application Support/Claude/claude-code-sessions/<accountId>/<orgId>/local_*.json.
The folder name is not documented anywhere — it comes out of the app's own bundled JavaScript, where a
constant holds the string. On Windows the same structure sits under{' '}
%APPDATA%\Claude\claude-code-sessions\.
A quick script over the folders gave this:
{`[372ac280…] sessions=4 size=2K last=2026-04-13 → a test account
[4d1f33a2…] sessions=330 size=44M last=2026-04-08 → the main archive (abandoned)
[a4ea2866…] sessions=83 size=4.5M last=2026-04-10 → archive
[a9e945b6…] sessions=83 size=252K last=2026-04-26 → recent parallel
[be2110e2…] sessions=69 size=203K last=2026-04-29 → ACTIVE RIGHT NOW
[c53acc1e…] sessions=141 size=244K last=2026-04-26 → recent parallel`}
Six accounts, not the four I was sure about. And the one I had most thoroughly forgotten held the
main archive: 44 MB, 330 sessions, five months of work.
The toolkit
Four cross-platform Python scripts, in the public config repo under a{' '}
desktop-sessions-discovery skill:
sessions_registry.py — reads every session from every account and generates one self-contained HTML dashboard with search, sorting and a Restore button per card. The active account is highlighted; anything already migrated is marked from a migration journal.,
sessions_inventory.py — a text report grouped by account, with a summary of projects that appear in more than one.,
sessions_find.py — substring search over titles and working directories, with account and time-window filters.,
sessions_restore.py — migrates one session into the active account: byte-for-byte verification of the copy, a journal entry, and the original is never deleted.,
]} />
In practice I say "show me all sessions on this machine for migration", the skill triggers, a browser
tab opens with the dashboard, I find the 392-step session from the abandoned archive, press Restore,
paste the command back into the chat, restart the app, and it is in the window.
What I deliberately did not do
No bulk merge of all 715 sessions. A sidebar with 700 entries — fifty of them empty scheduled runs — is unreadable, and a bulk copy is exactly what a future validity check would reject.,
No automatic migration on startup. Anything nailed to the current storage format turns into a pumpkin the moment the format moves.,
No symlinks between account folders. They break on the first path change and breed strange bugs six months later. Copy only.,
Originals are never deleted after a restore. They stay in their account folder as the backup.,
]} />
The tool has an expiry date, and that is the point
The storage format has changed three times in a year — one folder name replaced another, and part of
the macOS population is already migrating to a disk-image bundle with rootfs.img and{' '}
sessiondata.img instead of plain JSON. Once that ships, copying local_*.json{' '}
files will most likely stop working entirely. Separately, Store installs are broken in their own way:
the atomic rename of a temp file fails inside the packaging sandbox because source and target look
like different devices, so sessions are not saved at all.
Which is why my actual long-term strategy is not the migration tool. It is the handoff: a markdown
file the agent writes into my repository at the end of a session — goal, what was done, what did
not work, current state, one next step. It does not care how the vendor stores chat history. Move the
sessions to SQLite, to an encrypted disk image, to the cloud with DRM; my handoff is still sitting in
my project folder in plain markdown, and any new session that opens in that folder reads it.
The two things solve different problems. Restoration reaches into someone else's storage and depends
on it. A handoff writes state into mine, at the moment I still have the context in my head. The old
session can be lost completely and the new one still knows the goal, the work, the failures and the
next step.
One more thing the layout decides for you: the desktop app splits sessions per account, so a handoff
written next to a session is invisible to a session in another account. The CLI keeps everything in
one project directory regardless of account — switch accounts and only the credentials file changes.
That is the quiet reason my work keeps drifting to the CLI.
);
window.ARTICLES = {
CLAUDEMD: ART_CLAUDEMD,
ARTICLES785: ART_785,
MANYCLAUDES: ART_MANY,
SEAMS: ART_SEAMS,
SESSIONS45MB: ART_45MB,
};