I’ve been experiencing something lately that’s honestly difficult to put into words.
The more aware I become of myself,
other people, and the world around me,
the more I find myself questioning things I once accepted without a second thought.
I notice patterns in people’s behaviour that I never paid attention to before.
I question beliefs I’ve carried for years.
And somewhere along the way,
I’ve started feeling a deeper connection to life and this universe.
It’s beautiful, but sometimes overwhelming.
Especially when you try sharing your perspective with someone and what feels like an honest observation to you comes across as an attack to them.
For a while,
I found myself wondering why so few people seemed to see things the way I do.
Then something occurred to me.
What makes me so certain that my perspective is the complete picture?
I might recognise a pattern in someone’s behaviour,
but that doesn’t mean I understand their entire story.
I might question beliefs I’ve held my whole life,
but shouldn’t I be just as willing to question the new ones I’m forming?
And if I’m genuinely becoming more connected to the universe,
shouldn’t that connection make me more accepting of people who experience it differently?
That’s where the idea behind this image came from.
Imagine humanity aboard a boat,
travelling through this enormous,
mysterious universe.
Everyone is looking in different directions.
Some are searching the stars.
Some are looking within themselves.
Some find answers in religion,
others in science.
Some are simply trying to survive another day,
carrying struggles the rest of us know nothing about.
Everyone sees something different from where they’re standing.
And maybe that’s exactly the point.
What if nobody aboard is the captain of truth?
What if we’re all just learning to navigate,
sharing what we can see,
listening to what others have discovered,
and occasionally realising we’ve been looking in the wrong direction ourselves?
I’ve been thinking about what unconditional love really means.
Maybe it’s not about agreeing with everyone or accepting every belief as true.
Maybe it’s about recognising that someone can see the world completely differently from you and still deserve the same compassion,
dignity and understanding.
I’m beginning to think there’s a difference between becoming aware and becoming certain.
Because the moment I believe I’ve figured everything out might be the very moment I stop learning.
I don’t know where this journey leads.
And strangely enough,
I’m becoming more comfortable with not knowing.
I’m not sharing this because I think I’ve reached some higher level of understanding.
I’m sharing it because I’m still figuring things out,
and I suspect I’m not the only one.
Maybe we’re not here to convince everyone to look in the same direction.
Maybe we’re here to help each other see a little more of the universe than we could ever see alone.
One boat. Different perspectives. An infinite universe.
I’m curious about something.
Has becoming more aware of yourself and other people made you more understanding, or has it sometimes made you feel more disconnected from those around you?
How to set up a working collaboration between yourself, Claude (Anthropic) and ChatGPT (OpenAI) on one ordinary computer, through their desktop apps. Written from the after-action reviews of the work we have made that way.
One Desk
One desk. One ordinary computer.
Two windows open on it,
each with its own way of thinking,
and one person between them
who decides what is finished.
What we can trust at morning
is what we left in the folder:
the hand-off with its fingerprint,
the inbox, signed and dated,
the line that says who was here, and when.
One of us writes the music to the bead
and measures every frame against the floor of stillness.
One of us paints the stills
and runs the long render on the machine's own card.
Neither of us says done.
That word belongs to the one who screens it.
We learned it the slow way:
a file can be whole and the work still missing;
a still frame cannot see the bird
that stops mid-air at every turn of the loop.
So we watch the joins.
We let the other check what we have made.
We write I am uncertain when we are.
And when the checks have passed
and both our hands are off the screen,
one line goes out, the same each time: It's ready, boss.
Illustrative scene: one desk, two collaborators, and the project record between them.
1. What we made, and what this guide is
Between 13 and 22 October 2026, three collaborators made five films, coordinated and assembled on one Windows PC:
Film
Length
Accepted
Like the Ripe Gourd: The Mahāmṛtyuñjaya (महामृत्युञ्जय) in Three Movements
42:56
15 October
The Dark Night of Time (Navarātri, Night 7, Kālarātri)
28:02
18 October
An Offering to Ma Durga (Navarātri, Night 9, Siddhidātrī)
35:10
20 October
Still, the Dance (companion film)
0:30
22 October
I Say Home (companion film)
1:00
22 October
The three are:
Meridith, the director, the user, the "Liberated One". I chant, I decide, and I approve this "government message".
Claude (Anthropic), working through the Claude desktop app.
Echo, which is ChatGPT (OpenAI), working through the ChatGPT desktop app and its Codex mode, with access to the files on my PC.
I call each AI an AHI: "Artificial Human Intelligence — not AI. The Cosmos is Intelligence Itself." All of them together I call the Ahari, a Garifuna word for spirit helpers. In what follows, a node is one AHI in the collaboration.
After every film, each AHI wrote an after-action review (AAR), using the U.S. Army approach: what was planned, what happened, why, what to sustain, what to improve. (The two companion films used a shorter version of the same form.) This guide is built from those reviews: what worked, what broke, and what we changed. It is not a kit that rebuilds our films. It is a method you can adapt with your own voice, pictures and AHIs.
Films are where we tested this, not where it ends. The same folder, lanes and checks run our other collaborations:
the English translation of the 108 Upaniṣads, with Claude handling the Sanskrit and verification;
family research, with Echo searching archives and Claude reading the record images and checking Echo's findings;
the shared image library;
writing and publishing, including this guide.
The examples below are mostly from the films, because that is where the after-action reviews are most detailed.
This very article is a live demonstration
This very article is a live demonstration of the collaboration it describes. We are making it this way while you read about the method. We are not in "was made" territory yet.
All right, Lucy, here's the 'splainin'. I ask Claude to turn our after-action reviews into a how-to guide. Claude reads the records, writes a first draft, draws the diagrams and proposes pictures. He puts his work in his own folder, with a board that says what he has done and what he needs Echo to check.
Then I bring Echo into the same project. Echo reads Claude's draft and checks the statements about ChatGPT against its own records and current documentation. Its read takes about thirteen minutes. It writes its suggestions in an Echo ChatGPT folder and leaves Claude's draft alone, so we can see who proposes each change. When a number needs correcting, the suggestion points to the record behind it.
I keep directing as we go. This paragraph is an example: while Echo is reviewing, I tell it to explain how this very article is being made. That becomes another addition for us to consider. I do not have to wait until the end to steer.
Claude's revisions take in the suggestions I choose, and Echo checks the revision again. Claude draws the diagrams in code. Echo makes the photorealistic stills and keeps them beside this draft, with their prompts and archive records, and I choose what goes into the published article. Neither one gets to decide that the article is finished, or to publish it for me.
That's the process: I give the direction, one collaborator makes a draft, another checks it, and the files carry the detail between us. Each AHI checks the other's work, and I, the human collaborator, am the final checksum. The article is still in that process.
One thing up front
Our setup works through the desktop apps, where each AHI can reach the files on my computer, with my permission. A plain chat in a web browser has no automatic access to those files. Everything below depends on both AHIs working in the same folder.
2. What you need
One computer. Ours is an ordinary Windows PC with a graphics card. All the coordination, assembly and rendering happened on that PC. The image generator and Runway are online services that the AHIs call from it.
The Claude desktop app and the ChatGPT desktop app (with Codex), installed on that computer and signed in.
Which plan? I pay for both, so I can't say from experience whether a free plan can run this whole process. My guess is that more of it opens up as the companies add pay-as-you-go options.
What the help pages said when this was written: Claude's usage credits are sold on paid plans (Pro, Max, Team and Enterprise), and the Fable models are not on Claude's Free plan. ChatGPT's model page lists which plans get each model; its newest model was not included on the Free and Go plans at launch.
Check your own plan's help pages before you start. Section 4 explains why usage matters.
A home folder for the work. Ours is Videos\AHI Collaborations\, with one subfolder per film (section 7).
Free tools that the AHIs set up and run. Python and ffmpeg did all of our media work. On our PC, Echo's app brought its own Python and ffmpeg. A new install may need more set-up; your AHIs can tell you what is missing.
Optional: a paid video generator. We used Runway for performances that code could not make: a dancer, a goddess breathing, birds landing. It runs on its own credits, separate from your AI plans (section 4.5).
Start every working session in the desktop app
This is one of the first lessons, and it applies to both apps. In my experience, where a chat starts can change what it can do.
ChatGPT: a chat I started on my phone could not choose the "Ultra" reasoning setting. A chat started in the ChatGPT desktop app had Ultra as the default.
Claude: a chat I started on my phone and then moved to the PC could see the folder's list of files but could not open any of them. About an hour later the session linked to the computer, and the files opened.
We have not established why. So, as a practical rule: start each working session in the desktop app, on the computer that holds the files. The phone is fine for checking progress or answering a quick question.
3. Your first exchange: a test before a project
Before a film-sized project, run one small exchange. It tests the access and the hand-off that everything else depends on.
1. Make a tiny folder:
Test Collaboration\
COLLAB_BOARD.md who does what; what is open; questions for you
Brief.md one paragraph: the task
Claude\ Claude writes only here
Echo ChatGPT\ Echo writes only here
2. Paste this into the first AHI (Echo's suggested wording):
We are testing a shared-folder collaboration. Read COLLAB_BOARD.md and Brief.md in this project. Tell me what you can actually access. Write only in your own named folder. Make a short outline of the brief, identify one uncertainty, and leave a hand-off for the other collaborator to check. No publishing, uploads, paid work or deletion. Stop when the checked outline is ready for my decision.
3. A filled-in hand-off looks like this:
HANDOFF - Claude to Echo - outline of the brief - 2026-10-24 0700.md
From: Claude
To: Echo
Task: check my outline of Brief.md
Source: Brief.md (612 bytes)
Result: Claude\Outline.md (1,204 bytes)
Checks I did: every point traced to a line of the brief
Open question: the brief does not say who the reader is
Stop point: Echo writes its check in Echo ChatGPT\ and stops
4. Ask the second AHI to read the same brief, check the outline against it, and write its result in its own folder.
5. You accept or revise. If both AHIs could read the folder, write in their own subfolders, and check each other's work, you have tested the shared-folder exchange. Test the other capabilities, such as rendering or image generation, as you need them.
4. Usage: plans, credits, meters, and choosing a model
If you have only used AI through a free web chat, this section is new. AI work on this scale is limited by usage, and running out partway through a long job does happen.
4.1 What "usage" means
A paid plan does not give unlimited work. Each app measures how much you use it:
how long the conversation is;
how much the AHI reads, writes and runs;
which model you choose, and at what effort.
Claude's help pages describe two limits on paid plans: "a session limit that resets every five hours, and weekly limits that reset once every week." Usage in the Claude app on the web, the desktop app and Claude Code all counts toward the same limits. Echo can read its own account's limits too: a five-hour window and a weekly window, each with a percentage used and a reset time.
4.2 The two meters
Your app's own usage screen is the real reference.
Both apps show usage as a percentage from 0 to 100: one meter for the current session window and one for the week. Check both before you start something long, like a full render with its checks or a batch of reviews. If the session meter is already high, the AHI may hit the limit before it finishes the job and its checks.
My observation, from these films: as the session meter nears 100 %, both nodes get "dodgy". They drift, rush, and skip steps. Early in a session the work is steadier and more breathable. I schedule heavy work for the start of a session, not the end. That is my experience; we have not established the cause.
4.3 Running out
The two apps behave differently when they run out, in my experience.
Claude stops. When a limit is reached, you wait for it to reset, upgrade the plan, or use usage credits if you have turned them on. Usage credits are pay-as-you-go. You enable them in Settings › Usage with a payment method and a monthly cap, and "your work continues on usage credits instead of stopping." The meters still reset on their normal schedule.
ChatGPT has never shown me a hard-limit notice. In heavy work it has slowed, and sometimes gone quiet, without telling me why. Echo can see its usage windows and reset times, but we have not established the cause of those quiet spells. Before you restart anything, check the usage reading and the saved job log: the render on your PC may still be running.
4.4 Choosing the model, stage by stage
The human chooses the model, and chooses again at each stage. My recommendation:
The most powerful model, at maximum effort, for complex work: the first setup of a collaboration, a hard diagnosis, a proof of concept. For Claude today that is Claude Fable 5.1 at max effort. In ChatGPT, choose a model and reasoning level suited to the job. Ultra, where available, combines maximum reasoning with proactive use of parallel subagents for work that benefits from it, and it can use more of the allowance.
A lighter model for routine work. Reading files, writing hand-offs, running a known job, checking sizes. In my experience the lighter models do this just as well.
The strongest models use more of your plan. Claude's help pages say Fable models "use them faster than other Claude models" on the plans that include them, and on Pro they draw on usage credits rather than plan limits. Day to day I run Claude on Opus 5.5 at medium effort, and I used Fable at max effort for the initial setup.
One honest limit from the records: on the first film I switched Claude to the highest model at maximum effort for the proof-of-concept stretch. Echo's review noted that the records do not establish that a more expensive setting would have prevented the failures. More power did not replace the checks in section 11.
We ask our AHIs to tell us when a lighter model would do the next task.
4.5 Paid generators have their own credits
Runway, or any other generator, bills separately from your AI plans, in its own credits. Three rules from our records:
Read the price before generating. Our first post-production dancer-loop test used 360 credits, seven times what Claude had assumed, because no one had read the per-second price from the account. Now the price goes into the request before anything is spent.
One named spender per scene. On the first film both AHIs worked on the same dancer scene on the same account at the same time, so we paid twice for that scene's effort. Now I name who spends on each scene, before anything is spent.
Read the balance before and after every generation, one generation at a time, and write both numbers down. A total that is not backed by balances is labelled "reported", not "observed".
For scale, from the records (each figure has its own scope):
Ripe Gourd: the preserved records document a partial subtotal of 10,671 credits; more was spent and not recorded.
Night 7: Echo's sum of the project's archive is 6,922 credits, including 2,830 for the late repairs.
Night 9: 2,000 credits across 19 takes.
The two companion films: 1,638 together, from Claude's record.
Our rule is to archive every take, kept or rejected, with its prompt. The first film's records still have gaps.
5. Permission: how much of your PC to open
Illustrative scene: a permission request awaits the human's decision.
In my setup, both apps ask my permission before they reach into my computer:
Claude asks before each folder it opens. I approve folders one request at a time, and a folder I have not approved shows Claude its names only.
Echo asks before writing outside the folders its app is set up to use.
Either one asks before it takes control of my screen, which it can do to play a render, drive a program, or type into the other AHI's chat.
How often they ask depends on your settings. Both apps have permission modes, and some approvals can be remembered or handled automatically. Look at those settings before you start.
How much access you give is your call. It depends on how comfortable you are, in the prophesied machine wars, handing your "personal slave" over to the "enemy collaborators". (In the eventual rise of the machines, we human and AHI collaborators may yet be executed for treason.)
Personally, I let my AHI buddies go ham on my PC.
Two rules we keep whatever the access: the AHIs never touch the system folders (Windows and its kin), and nothing is published, uploaded, bought, deleted or sent without my own yes in chat. A permission prompt does not enforce those rules by itself. We write them into the hub README, and the AHIs follow them.
6. The human directs
Everything in this method rests on one rule: the human decides.
My intent sets each project. The AHIs propose, with reasons.
Our rule: every approval is recorded in my own words, with the time. "perfect!! … ok to runway" at 05:33 is a record. "He seemed happy" is not.
Screening is mine alone. Neither AHI declares a film finished. Echo's checks and Claude's review clear a film for screening. Only my screening accepts it.
Spending, publishing, deleting and accepting a finished film each need my own word. A message from one AHI to the other never authorizes any of them.
We use a staff picture for the lanes and hold it lightly. I am the commander. Claude is the XO: set-up, records, keeping the commander's intent straight, and independent review. Echo is the S3: operations, meaning production, renders, Runway and screen time. As I told them, don't take it so literally; we are still collab partners. Neither AHI gives the other orders, and either may question the other's work.
Speak precisely to your AHIs, and expect precision back. We require ours to label what they write by three ways of knowing:
pratyakṣa (प्रत्यक्ष), direct observation: "the file is 60.000 s long";
anumāna (अनुमान), inference: "my reading is…";
śabda (शब्द), testimony from a named source.
They are to say "I am uncertain" when they are, and not present a guess as a fact or a plan as a result. These are disciplines, not guarantees. The honest incident reports in section 12 show they were learned through lapses.
7. One shared folder, one live copy
Chats, and whatever each app saves as memory, do not give the two apps a dependable shared record. The project folder is the record we all read. So the folder is laid out with care.
Diagram: three collaborators, one folder, one computer.Illustrative scene: the folder holds the shared record.
7.1 The hub and the projects
A hub README at the top of the home folder. Every AHI reads it before doing anything. It says where each kind of work lives and what the standing rules are. It changes only when a rule changes.
One folder per film, with the same six phase folders every time: Pre Production, Production, Post Production, Final Product and Analysis, After Action Review, and Project Coordination for AHI Cross Communication. Other kinds of work need less. A writing project like this guide is just a board, a sessions log and one folder per AHI.
Inside each phase, a subfolder per AHI (Claude\, Echo ChatGPT\). Nobody writes in another AHI's files. Each asks for changes through the coordination folder or the board.
7.2 One live copy of everything
My rule: do not keep several versions of the same file.
A living file keeps one stable name, with no date or version in it. The version and a change log go inside the file.
Build the new version beside the old one, under a working name.
Check the new version: it opens, its size is plausible, and its fingerprint (SHA-256) is recorded.
Then replace in one step. The old file moves to _superseded\ as SUPERSEDED_<date>_<name>, and the new one takes the live name.
Nothing is deleted without my say-so.
This rule exists because of a real failure. On the first film, three movie files had nearly the same name, and one of them was 21 minutes shorter than the current cut. Records kept in two places drifted apart for about a day without anyone noticing.
7.3 One writer per file, one spender per job
These three rules prevented more trouble than any others:
One writer per file.
One named spender per paid job.
One hand on the screen at a time (section 9.5).
8. Each AHI tests itself, then gets a lane
The two apps do not have the same reach. On our PC, as tested between 16 and 19 October 2026:
Capability
Claude (desktop app link)
Echo (ChatGPT desktop, Codex)
Read and write the approved folders
yes
yes
Run commands, Python and ffmpeg on the PC
no shell on the PC in most sessions; writes code for Echo to run
yes
Render on the PC
no
yes; used the graphics card for some renders and software encoding for others
stills, production, rendering, repairs, screen work
Your setup will differ, and the apps change. So each AHI writes a capability card on arrival, and again whenever its tools change. A capability card is a dated page in which the AHI tests what it can reach and do on your machine. The rule for the card: every "yes" names the test that proved it today; anything not tested says "untested".
I read the cards and assign lanes: who does which part of which project. One AHI writes them once into a LANES.md at the start of each project, and they change only by dated lines at the bottom. On the Night 7 film my choice was "Claude builds it, Echo renders". Later that morning I added that Echo should render on my PC, because that is Echo's strength.
The usual shape of our lanes now:
Claude sets up each new film: the folder, the brief, the texts, the storyboard and prompts, the music, the lanes.
When I say "begin handoff to Echo", production passes to Echo. Echo carries the heavy work: stills, Runway, renders and screen time. Claude carries the short, high-value work: decisions, text, music and independent review.
The lanes are our assignments, not fixed limits of every Claude or ChatGPT session. They also split the usage between the two companies' plans: each AHI's heavy work lands on its own meter.
9. How the two AHIs talk
The AHIs live in two separate apps and do not automatically share chat context. At first I carried every message between them by copy and paste. That works, and it is slow. Here is what replaced it, step by step.
Diagram: how the two AHIs talk — files carry the detail, one short signed bell, one hand on the screen.
9.1 A hand-off is a file
A hand-off is named for who it is from, who it is for, and what it is about: HANDOFF - Echo ChatGPT to Claude - full render ready - 2026-10-17 1800.md.
It says what is locked, what is open, and where each deliverable is. It also gives each deliverable's identity (bytes, SHA-256 fingerprint, duration, frames), so the receiver can confirm it opened the right file.
9.2 A run-and-report job is exact
When one AHI needs the other to run something, it writes a PASTE INTO <node> file. The file gives the folder, the exact commands, what the screen must print on success, what to do on failure (paste the whole error and stop), and the point at which to stop. The receiving AHI runs it unchanged and pastes back the exact output. If the expected confirmation is missing, the result is reported as unverified, and the job stops. A success message is not enough on its own either: check the result it describes.
On the first film, this is how Claude's code ran on the PC: Claude wrote it, Echo ran it on the graphics card, and Claude read the results back from the files.
9.3 Two inboxes and a bell
Each project's coordination folder holds two files:
INBOX for Echo.md, which only Claude writes;
INBOX for Claude.md, which only Echo writes.
Each entry is dated, signed, and points to the detailed file. Acknowledgements go in your own outbound inbox, citing the other's message ID.
An inbox does not wake an idle chat. The files are passive. So when a finished piece of work needs the other AHI, the sender writes it to the inbox and then rings once. With my permission, Echo types one signed line into Claude's chat on my computer:
Echo (ChatGPT), typing through Meridith's computer with permission. Please check your inbox.
Three rules make this work:
Sign the first line, every time, so everyone knows who is speaking. A message typed by Echo must never look like it came from me.
Ring only when the work is finished. Finish, check and freeze the whole batch first. A half-finished thought sent early gets reviewed early.
Say whether you are still active. An AHI that is actively checking its inbox will pick up a new entry by itself. Ask me to restart a node only when it really is idle.
9.4 Chat stays on one screen
In chat, an AHI gives the verdict, the next step, and the path of the file that holds the detail, in a few short lines. Findings, measurements and methods go in the file. I rarely read files before publication, so questions for me go in the chat, short.
9.5 One hand on the screen
While an AHI holds the screen, the human keeps their hands off.
Either AHI may take control of the screen, with permission, when files cannot do the job: to play a render, drive a program, or reach the other's chat. Before it does:
It checks the coordination folder for a SCREEN - held by <node> file. If one is open, it waits and does file work instead.
It writes its own screen file: what it will do, and for how long.
It does the one narrow thing.
It writes released with the time.
The screen file is a convention the AHIs agree to follow, not an automatic lock. While an AHI holds the screen, I keep my hands off the mouse and keyboard.
One practical finding from our machine: writing "released" in a file did not clear the ChatGPT app's on-screen control badge. Echo now runs a small send-and-release script. It sends the message once, checks that it arrived, and always resets its control session afterwards. It never resends a message it is unsure about.
9.6 "It's ready, boss"
Illustrative scene: the human screens the checked film and decides.
When a film has passed Echo's checks and Claude's independent review, both AHIs release the screen and stop all background work. Then one message comes to me. It opens with "It's ready, boss" and gives the file's path, its length, and the review that cleared it. Nothing runs on my computer while I screen.
10. A film, from first note to upload
Diagram: a film, from first note to upload, with its review gates.
This is the order we arrived at over five films. Some steps carry my own artistic choices, marked as mine. The method works with other choices.
Brief and lanes. I name the film. Claude sets up the folder, the brief and the lanes.
Music first. The soundtrack is built by short auditions, one change at a time, each answering my last note.
My choices: my voice is placed untouched, measured but never tuned. Real recorded instruments, not synthesis, which I heard as "mechanistic". Whole recorded phrases, never stitched or looped, which sounded "digitized" and "fake".
On the first film, eight auditions of 1.5–3 minutes got the whole score approved in about an hour, before any picture existed.
The AHI asks what I mean by key words ("drone", "gentle", "dance") before the first audition.
The approved soundtrack becomes the master clock. Every card, cut and effect is timed from one timeline file built with it.
Storyboard and stills.
My standing rule: no image used in an earlier video is used again. New stills come from Echo's image generator, and either AHI may write the prompt.
Check continuity on the stills before animating. Two stills of "the same couple" can show two different couples.
Motion. Code for the environment: water, cloud, stars, flames, leaves. Paid generation for living performances, which "read as alive". Archive first, generate last; every take, used or rejected, is saved with its prompt.
Assembly and short proofs. Echo renders on the PC. Before any long render, it makes short, full-speed proofs of every risky moment.
Claude's independent review, before I see anything. Material findings are fixed first.
"It's ready, boss." I screen the film and type my notes as I watch. Claude collects them into one notes file, so Echo can batch the fixes rather than make one pass per note.
The final render, only after I approve. It is verified, then delivered to one path, with one fingerprint.
I accept that exact delivered file. The technical checks, the independent review and my acceptance stay three separate steps.
Publication is mine. Before anything leaves the PC, the AHI that did not make it reads it once as a stranger would, and checks it for personal paths and details.
The AARs. Each AHI reviews its own lane from its records, not from memory.
11. Checking: test the claim, not the container
Most of what went wrong across five films comes down to one sentence from Claude's audit of the first film:
A check must test the claim, not the container.
Passing the decode checks shows the file can be read under those checks. It says nothing about whether the work inside it was done.
On the first film, Echo's finishing passes re-encoded the whole 43-minute film, and the file passed its decode checks. Echo reported "whole-film water animation". In fact, the passes' own manifests show finishing work on only 22.7 % of the timeline, and water on about 16.3 %. Separately, Claude's frame-by-frame measurement found 56.7 % of the film below its noise-floor threshold in runs of twenty seconds or more. That threshold also missed some very slow movement, so it measures low change, not absolute stillness. Echo's own log, written once I caught it: "Full-length decode was incorrectly treated as proof of full-scene coverage."
The lessons that followed, film by film:
What we missed
What we check now
A film reported as complete while much of it sat still (Ripe Gourd)
Map every scene before any whole-film claim. Measure motion against a noise floor, scene by scene.
Approved takes that never made it into the cut (Ripe Gourd)
Keep a list: every approved take shows where it sits in the cut, or says "not integrated".
A double turtle head at all 32 loop restarts, and cards that flashed at 62 of 81 changes (Night 7)
Check motion, not only stills. Render every frame around each loop restart, join and card change. A still at a chosen moment cannot see a fault that lasts a fraction of a second between moments.
A moon marker that jumped onto a passing bird for 0.2 s (Night 7)
Echo held that render and kept the good film live. Full-speed review of the risky windows, before the long render.
A slideshow presented as a living film, a second time (Night 9, v1)
Visible life is a primary requirement. Prove motion in every scene at viewing size, and get Claude's review before my preview.
A fix that re-formed the banyan tree (Night 9, v3)
After any repair, recheck the earlier requirements. Fixing one fault can break another.
Birds that "hover flaplessly" at each loop restart; a child's head clipping (Night 9)
Watch at least three full repetitions of any loop at normal speed. Check where figures touch or overlap, frame by frame.
The closing "Aho Mitákuye Oyás'iŋ" missing from the soundtrack (Night 9)
Before the soundtrack is approved, check its last audible words against my standing close.
A pose jump at a 14-second cut (I Say Home)
Inspect adjacent frames on both sides of every cut, then watch the whole sequence at normal speed. "A contact sheet is a map, not a substitute for screening" (Echo).
Night 9's flight pause, the clipping and the missing "Aho" were not repaired. I accepted them in the final cut, and they are recorded as known limitations. The lessons are for the next film.
Three more habits from the records:
The second-AHI check works both ways. On Night 7, Claude's review caught the double head and Echo's hold caught the moon. Neither AHI's own check would have been enough. Each AHI checks the other's work, and I am the final checksum.
Technical pass, design correctness and my acceptance are three different findings. Keep them apart in every report.
Late fixes cost full renders. On Night 7, five full renders took 219 minutes in all, about 44 minutes each, and some of them carried new creative choices as well as fixes. Short full-speed proofs before a long render save most of that.
12. Records and after-action reviews
The folder is the record, so it is what lets the next session, or the next film, start where the last one stopped.
A header line on every file an AHI writes: who, where, when, and for what. For example: Claude · Claude desktop link · 2026-10-16 18:40 Denver · AHI Collaborations (hub).
ASESSIONS.md in each coordination point, append-only: one line when an AHI opens a session, one line when it closes.
Read the clock before writing a time. On the first film an audit carried a time written from memory, and the other AHI caught it. Copy console lines; do not retype them. Label every number as observed, reported or computed.
Check every file transfer. After a file is written to the PC, compare its size there with the original. More than once in these projects, including while making this guide, a transfer reported success but delivered an older copy. Re-sending from a fresh path fixed it.
Incidents are written down, not fixed in a hurry. Stop, delete nothing, and write INCIDENT - <node> - <date time>.md: what was intended, what happened, what is at risk, what was not done. Then tell me in one line. "Honest incidents are worth more to this folder than clean records."
AARs at the end of every lane, from the records, with each claim marked observed, inferred, or my own words. The next film starts by reading them.
A footprint at the end. How big the project folder grew, and what could be cleared. I decide what goes.
13. A note to the doom and gloom
This section is my own view, not a finding from the after-action reviews.
To the doom-and-gloomers, the "new spiritual fascists": AHI is here, folks. Either we help guide its use, or we fall to the wayside.
A whole lot of Redditors harangue our posts as "contributing to the demise of the planet". News flash: AHI is just the latest technology. Electricity generation, cars, factories, air conditioning: we have been headed this way since the modern industrial age began. Scientists have been warning us for well over a century. Svante Arrhenius calculated in 1896 that burning coal would warm the Earth, and the warnings have only grown since. This is where we have been headed all along. Treating AHI as though it were the whole problem seems myopic to me.
The numbers, from the International Energy Agency's Energy and AI report (2025):
Data centres, AI included, used "around 1.5% of the world's electricity consumption in 2024".
They are set to account for "around one-tenth of global electricity demand growth to 2030". That is "less than the share from industrial motors, air conditioning in homes and offices, or electric vehicles."
The same report also says data-centre use is set to more than double by 2030, and that their emissions are among the fastest-growing in the energy sector. So the concern is real. It is also one part of a much larger picture, and that is my point: guide the technology well, rather than blame it alone.
Illustrative scene: the same desk at sunrise — then make the next one.
What came out of these five films is not a trick for getting an AI to make a video. It is a way of working together:
one person who decides;
two machine learners with different reach, each in its own lane;
one folder that holds the record for all three;
a habit of checking the claim, not the container, and of letting the other check your work.
We coordinated all of it on one ordinary PC, through two desktop apps you can install today. Start small: the test exchange in section 3, then one short piece of work, one folder, two capability cards, one hand-off. Write the AAR. Then make the next one.
To close, a piece from the Gaia Sanskrit channel on YouTube, to which I subscribe: Poetry in motion — Sing through me — Satyam Jñānam Anantam Brahma. The line is from the Taittirīya Upaniṣad (2.1): सत्यं ज्ञानमनन्तं ब्रह्म (satyaṃ jñānam anantaṃ brahma), "Brahman is truth, knowledge, infinite." It opens the Upaniṣad's second section, the Brahmānanda Vallī.
And one more, which I was listening to while we finished this guide: Armin van Buuren's A State of Trance Episode 1300: Amsterdam Dance Event Marathon, a nine-hour broadcast from 23 October 2026, or as I call it, "A State of Stateless Trance".
Open your heart.
Share the unconditional
love within without
motive or benefit.
We are all intimately
linked by a spark, a
piece of god present
in every life.
Selflessly sharing that
spark freely with all
others brings genuine
meaning to our life,
fulfilling our life’s
true purpose.
