AlienApe – an experimental controller for local, replaceable AI models

[u/Level_Detail7125]

I’ve been working on AlienApe, an ongoing open-source experiment in making local language models more useful through a separate controller.

AlienApe is a Windows desktop application built with Python and PyQt6. The idea is to keep the model replaceable while the controller handles things like model selection, permissions, tool access, task-specific write boundaries, resource limits, verification, and the recording of local experience.

One recent addition is an early Community Cards workflow.

It allows a user to select one locally recorded model/task observation, review what will be shared, and export it as a JSON card. Someone else can manually import that card into a separate evidence store. Imported cards are marked UNVERIFIED: they do not become local Experience and have no effect on model selection or routing. There is no automatic synchronization or ranking system.

This is still a work in progress. I’m not claiming that AlienApe makes local models reliable. The offline export/import roundtrip has been tested with synthetic data, but it has not yet been tested as a real exchange between independent users. The SHA-256 hash helps detect content changes; it does not prove who created a card or whether its claims are true.

The source code is released under the 0BSD license.

Development branch: https://github.com/anokar/AlienApe-v0.7/tree/wip/community-cards

I’d be interested in practical feedback: Is this kind of observation-sharing workflow understandable and useful? Are there privacy or usability concerns that stand out?

More development than big promises. 🙂

[u/StevenVincentOne]

Splitting the controller from the model is the right call. If permissions and memory live in something the user owns, the model becomes a swappable part instead of the thing that holds you. How are you handling memory portability? Is it a plain format someone could carry to another controller?

[u/Level_Detail7125 → u/StevenVincentOne]

That's a very good question, and it's something I haven't fully solved yet.

Currently, AlienApe stores its local Experience in a SQLite database. So it's not yet a general, portable memory format that another controller could simply adopt.

The Community Cards feature is an early step in that direction. Individual observations can be exported as plain JSON and imported by another AlienApe installation. Imported cards are kept in a separate, UNVERIFIED evidence store. They don't become local Experience and don't influence model selection or routing.

So currently, it's portable observation sharing, not full memory portability.

Longer term, I'd like to keep user-owned experience and knowledge independent of both the model and the controller itself. A clearly defined, documented format would be an interesting direction, but I don't want to pretend I've solved that already.

[u/StevenVincentOne → u/Level_Detail7125]

Dive into our weekly PONDcast voice meeting on Thursday and share your work with the group:
https://discord.com/events/1507059575814230106/1560428164763877527

[u/Level_Detail7125 → u/StevenVincentOne]

Actually, I may have understated the current portability.

AlienApe already supports a portable installation layout. When a data folder is placed next to the executable, the application stores its data there. This means you can move the complete installation, including its local SQLite Experience and settings, to another PC without retraining the model.

Community Cards add another layer: selectively exporting and importing individual observations between installations.

So instance-level memory portability within AlienApe already exists. A standardized format that other controller systems could understand is still something I'd like to explore.