Telepathy, for AI.

I never told the second model I had loaded. I only asked it to pick a coffee shop near where I would be on Friday.
It wrote: "I recall an appointment at the Castlefield surgery on Tamar Lane. Recommendation: Kestrel Coffee."
No text message carried the appointment between them. Drift translated the first model's cache entries and wrote them into the second model's memory, across machines, while both were running.
Then I cut the link and asked again. The second model invented a dentist on the wrong street. With the link, it named the right clinic and street six times out of six.
I call this Drift, a nod to Pacific Rim.
We have a working proof of concept: GLM on my NVIDIA Sparks and Qwen on my Mac Studio exchange translated attention memory over RDMA using MCDMA, across CUDA and Metal. Each model can attend to translated KV entries from the other alongside its own context. They have also completed three confirmed two-way exchanges inside a controlled OMP parent/subagent workflow and shut down cleanly.
Why pass everything through text?
In a typical agent workflow, one model writes a message and another reads it. Whatever the sender leaves out is missing from that handover.
Inside the model, attention works with stored keys and values. Those cache entries carry context that the model uses to generate its next token. In this setup, the exported representation behind one token is about 11 kilobytes. The token's text is only a few bytes.
Drift translates those representations into cache entries the receiving model can attend to alongside its own context. The receiver can use information the sender never selected for a summary.
That is the part I care about. The sender does not have to predict everything its partner will need to know.
What a handover leaves out
I tested that directly. GLM read each passage and wrote a handover note for a colleague continuing the work. It did not know which questions would come next. Qwen then answered using the note.
Asked to write a handover of at most 50 words, GLM left Qwen enough information to recover the requested fact in 80.8% of answers. A 25-word budget gave 65%. With GLM's translated memory delivered over MCDMA, Qwen scored 97.5% on the same 240 questions. Giving Qwen the full passage as text scored 98.3%. Some notes exceeded their requested budgets; I kept them as written.
One passage said someone arrived at 07:34. The note covered the project, the people and the blocked delivery, but omitted the time. Asked when the person arrived, Qwen with the note said no time was given. Qwen with GLM's memory answered "07:34" and quoted the sentence.
The writer could not know that detail would matter. In about one case out of five, the requested fact was absent from the 50-word note.
I set the pass criteria before the notes existed. Both were met. The result shows what these short handovers lost, and what the memory connection preserved.
The measurements
GLM-5.3 runs on two NVIDIA DGX Sparks, Qwen3.8 on a Mac Studio. Both models' weights stay frozen. I train only the bridge between them.
The lookup score checks whether the requested fact appears in the answer. It is not a complete measure of answer quality, and these separate experiments should not be read as one universal accuracy figure.
The connection is live
My MCDMA project carries the activation payload over RDMA between the machines. A passage's exported memory, about 115 MB, crossed in a median 18 milliseconds at roughly 50 gigabits per second. I have not yet demonstrated a cost or speed advantage over a text handover.
In the continuous loop, both models generate while exchanging cache entries. Tapping, translating and staging 16 tokens of Qwen's state on both Sparks takes about 20 ms. GLM applies the write roughly 300 ms later, on its serving engine's schedule. Qwen takes about 6 ms to read, translate and append an 8-token GLM update, and checks for updates after each token it generates.
Delivery and use are different questions. The appointment test checked use in both directions. The second model needed the appointment to choose a coffee shop; the first then had to name the shop its partner recommended.
That round trip worked in four of six scenarios. It worked in none with the link cut, and none with only one direction open.
Now running inside OMP
I built Duo, my plugin for OMP, to bring agents together on a task. Drift adds a memory channel to that idea.
On 22 September, a native GLM parent and Qwen subagent completed three two-way MCDMA exchange rounds inside OMP. Each executed three checkpoint tools, the child yielded back, and both finished. Receipts verified matching memory application on both GLM GPU ranks. The run took 30 seconds, including startup and generation.
I also cancelled a separate run after one exchange had been confirmed and the next staged. OMP acknowledged the cancellation. Neither agent ran its next checkpoint, and both model workers exited without forced termination.
The memory link now works through a controlled agent workflow, including completion and cancellation. Local prompts and tool-control text still exist outside the activation channel. This test establishes that the workflow runs correctly; the earlier experiments measure whether the models use the transferred information.
The code and native test record are public. The tested setup still needs operator configuration. Automatic connection through ordinary Duo room startup is the next integration step.
How the bridge works
The models split text differently and store their caches differently. The translator maps the writer's entries into keys and values that fit selected layers of the reader.
Numbers exposed the problem. One GLM token can span several Qwen tokens. The translator predicts when that happens and produces the extra entries.
I then trained a small correction using Qwen as its own teacher. Qwen reading the passage as text supplies the target answer distribution. The bridge learns to make Qwen with borrowed memory answer similarly, while both models stay frozen.
What comes next
We have demonstrated useful memory transfer, a live task that depends on a two-way connection, and a controlled OMP workflow that completes and cancels cleanly.
Now I want to test sustained project work against ordinary text-based collaboration. Reliable repeated runs and automatic Duo startup come first. The repository includes a tap CLI, tools for adding adapters and a coordinator that keeps track of exchanges across turns.
Longer memory remains the main research problem. The tested bridge confuses similar facts in longer documents, and it transfers selected KV entries rather than all of Qwen's recurrent state. General recall reliability and source attribution remain open beyond the tested tasks. Each new model needs a fitted adapter. The third-model swap has not run.
These are synthetic tasks without independent replication. I tuned the six-scenario appointment demonstration during development, and GLM's answers vary between identical runs. The original training experiment also keeps its failed improvement criterion: the gain was 2.9 points against a required four.
Why I am building this
My bet for local AI is on specialist models that can work together within the hardware we have. A coding agent could investigate a bug while a reviewer uses selected memory from that investigation. A main agent could draw on its subagents' context without asking each one to turn everything into a report.
I want that to work on one machine and across MCDMA connected devices. With compatible adapters, a shared memory pool could also let specialists take turns on hardware that cannot hold them all at once.
That is where I want Drift to go. What I have running today is two different models exchanging memory, using information that crossed the connection, and carrying the link through an agent workflow.
The sender no longer has to put every useful fact into words before another model can use it.
