Titans: Learning to Memorize at Test Time is a Tkinter demo platform, not a Titans implementation

What the repository actually contains

The gap between the name and the code is the first thing to get straight. The description calls this a multi-agent demo platform for Titans, and the README opens by calling it an interactive demonstration platform for the architecture. Nothing in the file listing implements that architecture. There is no memory module, no surprise metric, no parameter update at inference. The Python tree is main.py plus an agents directory holding seven provider-specific files: openai_agent.py, anthropic_agent.py, mistral_agent.py, groq_agent.py, gemini_agent.py, cohere_agent.py and emergence_agent.py. The README's own project structure block confirms that shape, and it also lists Titans Paper.pdf at the repository root, which tells you the paper is shipped as a document rather than as code.

So the deliverable is a desktop application that asks seven hosted language models to discuss Titans concepts. Each agent is mapped to a role in the paper's vocabulary: Neural Memory Module on OpenAI, Memory as Context on Anthropic, Memory as Gate on Mistral, Memory as Layer on Groq, Experimental Validation on Gemini, Innovations on Cohere, Analysis on Emergence. The mapping is editorial. It is a way to divide a conversation across vendors, not a claim that Mistral implements gating or that Groq runs a per-layer memory stack. Anyone evaluating this for research purposes should read the agent table as a prompt-assignment scheme and nothing more.

Who this is for, and who it is not for

The audience is narrow and specific. If you have read the Titans paper and want a visual, interactive way to see several models reason about memory-as-context versus memory-as-gate versus memory-as-layer, this gives you that in one window. It is also a reasonable reference if you are building your own multi-provider desktop tool in Python and want to see how someone structured seven vendor integrations behind a single selector panel. The MIT licence makes that kind of reuse straightforward.

It is not for anyone who needs the architecture. If your goal is to train or evaluate a neural long-term memory module, this repository gives you no starting point: there is no model definition, no training loop, no dataset loader, and no evaluation script in the listed structure. It is also not a benchmarking tool, despite an agent being labelled Experimental Validation. That agent produces text from Gemini. It does not run ablations. The README describes the panel as benchmarking and ablation analysis, which is the agent's assigned topic, not a capability of the software.

A third group should stay away: anyone who wants a tool that works without network access. Every agent is a hosted API client. With no keys configured, the README says agents show a graceful unavailable status, which is a polite way of saying the application has nothing to run.

How the seven agents and the UI fit together

The architecture visible in the material is a fan-out pattern. main.py starts a Tkinter application. The UI holds an agent selector panel where you choose which agents participate in a run. Selected agents each call their own provider through a per-provider module in agents/, and the responses stream back into a live demonstration console. That console is described as showing real-time streamed output, so the provider clients are wired for streaming rather than single completions.

Alongside the console, the interface collects runtime telemetry: per-agent timing and token usage, displayed live. There is also a numeric-series chart that the README says is automatically extracted from agent output, with play and scrub interaction. That extraction step is the one piece of real parsing in the application, and it is worth understanding before you rely on the chart. The chart plots numbers that appear in model-generated prose. If an agent writes about a 2,000-token context window and a 0.85 gate value, those numbers can end up as a series. The chart is a visualisation of text, not of measured experiment output. The README does not document the extraction rules, so treat the plotted values as illustrative.

A collaborative insights view synthesises cross-agent analysis, and the split-pane layout remembers its position across sessions. The remembered layout is a small detail but a real one: it means the application writes some state to disk between runs, and it is the only persistence mentioned anywhere in the README.

Getting it running: commands and config keys

The README gives a four-step path. Clone the repository, install dependencies with pip install -r requirements.txt, copy .env.sample to .env, then launch with python main.py. The environment template lists seven keys: OPENAI_API_KEY, ANTHROPIC_API_KEY, MISTRAL_API_KEY, GROQ_API_KEY, GOOGLE_API_KEY, COHERE_API_KEY and EMERGENCE_API_KEY. The README states explicitly that you do not need all of them, and that the platform works with any subset, showing a graceful status for unavailable agents. That is the most useful design decision in the project for anyone evaluating it cheaply: you can run it with one key and still see the UI, the telemetry panel and the chart behaviour.

Windows users get two extra entry points. titans.bat is a launcher that the README says handles path setup automatically, and titans.exe is a pre-built executable described as requiring no Python. The troubleshooting table recommends titans.bat specifically when the app closes immediately on launch, because it lets you read the terminal error output. That row is a quiet admission that launching main.py directly can fail in ways the GUI does not surface. The same table notes that python main.py fails with a path error if you have not cd'd into the project folder first, and that google.generativeai deprecation warnings are non-fatal.

The Python requirement is 3.9 or higher, per the badge in the README header. There is no packaging metadata, no pyproject.toml or setup.py mentioned, and no test suite in the listed structure. Installation is the requirements file and nothing else.

The bundled executable is the weakest link

Shipping a titans.exe is convenient and it creates a maintenance problem the repository does not address. A pre-built Windows binary is a snapshot. Any change to an agent file, to the prompt scaffolding, or to the telemetry code lands in the Python sources and not in the executable until someone rebuilds and recommits it. The README gives no build instructions for the exe, no indication of which tool produces it, and no version marker tying it to a commit. The single release listed is dated the same day as the last push, which is consistent with a rebuild but does not prove one.

The practical consequence: if you run titans.exe and it behaves differently from python main.py on the same checkout, the binary is the stale artefact. There is no way to tell from the repository alone. If you plan to modify agents or prompts, use the Python path, because that is the only path the README documents as editable. The exe is for trying the UI, not for developing against it.

The second failure mode is environmental rather than structural. Every agent depends on a hosted provider, and provider SDKs move. The troubleshooting table already flags google.generativeai deprecation warnings as non-fatal, which means the Gemini integration is pinned to an interface Google has deprecated. That warning will keep working until it does not. When a provider retires an endpoint or an SDK method, the corresponding agent stops returning text, and there is no test in the repository to catch it before you do.

What the Titans paper describes, and what this code does with it

The README's science section is accurate as a summary of the paper. It names three integration strategies: Memory as Context, where memory tokens are prepended to the attention context window; Memory as Gate, where memory output multiplicatively gates the attention output; and Memory as Layer, where the memory module sits as a standalone layer in the stack. It describes the central idea as test-time learning of what to memorize, with the memory module updating its parameters during inference based on a surprise metric, retaining information that contradicts its current knowledge without additional training. That is a fair description of the paper's contribution.

The disconnect is that none of this is in the repository. The three strategies exist here as three agent roles, each producing prose. If you want to understand the difference between prepending memory tokens and multiplicatively gating attention, the application can give you seven model-generated explanations of it, which is genuinely useful for orientation and useless as a specification. The README does include the BibTeX entry for Behrouz, Zhong and Mirrokni, 2025, and ships the PDF, so the primary source is one directory away. That is the honest framing: this is a reading companion with a chat interface, and the paper is the artefact that matters.

Alternatives, and the difference that matters

If your goal is to run multiple LLM providers side by side in a desktop window, the closer comparison is a general chat client rather than a research tool. Open WebUI is the obvious one: it is a self-hosted web interface that connects to OpenAI-compatible endpoints and local runtimes through Ollama, keeps conversation history in a database, and supports multiple concurrent model conversations. The difference in approach is that Open WebUI is a general-purpose chat surface with persistent storage and user management, while this project is a single-purpose Tkinter window whose agent roles are hardcoded to Titans topics. Open WebUI gives you more models and more history; this gives you a fixed seven-way panel and a numeric chart extracted from the replies.

If your goal is the architecture itself, the alternative is not another demo. It is the paper plus a reference implementation. The README cites arXiv:2501.00663 and bundles the PDF, and that is the correct place to start, because nothing in this repository substitutes for it. A third path, if what you actually want is a multi-agent framework you can extend, is something like LangGraph or CrewAI, where agents are defined in code you control and orchestration is a first-class concept. This project's orchestration is a Tkinter event loop and seven provider modules. That is fine for a demo and thin for anything else.

One more comparison worth making explicit: the README's own framing invites you to treat the seven agents as seven perspectives on one problem. They are seven different models given seven different prompts. The variation you observe comes from both the model and the prompt, and the repository does not isolate which is doing the work. If you want a controlled comparison of providers, you would need to hold the prompt constant, and the README gives no indication that it does.

Licence, maintenance and what to verify before you commit

The licence is MIT, stated in the README and in the badge. That permits commercial use, modification and redistribution with attribution, and it is the most permissive common choice. Two things sit outside that grant and are worth noting without offering legal advice. The first is the bundled PDF of the arXiv paper: the repository's MIT licence covers the repository's own code, and the paper carries its own terms from its authors and arXiv. The second is the provider SDKs and their terms of service, which govern your API usage independently of this project's licence. If you plan to redistribute a modified build, check both.

On maintenance, the material supports a limited reading. The last push and the single release are both dated 2026-06-15, so the project was active as of that date, and the repository is not archived. There is no changelog, no CI configuration in the listed structure, and no test suite, which means every provider integration is verified by hand or not at all. The Gemini deprecation warning in the troubleshooting table is the concrete symptom of that: a known drift that has been documented as non-fatal rather than fixed.

What to verify first, in order. Confirm that agents/openai_agent.py and at least one other provider module contain the prompt scaffolding you expect, since that is where the Titans content actually originates. Confirm whether titans.exe matches the current sources, because a stale binary will misrepresent the project on first run. Then run with a single API key to see the telemetry and chart behaviour before spending on the rest. If your interest is the memory architecture rather than the interface, skip the install and read the PDF that ships in the repository root.

Editorial conclusion

Adopt this if you want a runnable, MIT-licensed desktop shell that fans one prompt out to seven LLM providers and streams the answers side by side, and if you are comfortable that the Titans content itself is whatever those models generate. Do not adopt it if you need a working neural long-term memory module, a benchmark harness, or anything you can cite as an implementation of arXiv:2501.00663. Before installing, open agents/openai_agent.py and one other provider file to confirm the prompt scaffolding is what you expect, and check whether titans.exe is rebuilt alongside main.py in the latest commit, because a stale bundled binary will not pick up agent changes.

Official sources

1. ai-in-pm/Titans---Learning-to-Memorize-at-Test-Time on GitHub
2. Issues
3. License: MIT
4. README
5. Releases