>This project leverages the Gemini APIs to provide AI capabilities. For details on the terms of service governing the Gemini API, please refer to the terms for the access mechanism you are using:
Click Gemini API, scroll
>When you use Unpaid Services, including, for example, Google AI Studio and the unpaid quota on Gemini API, Google uses the content you submit to the Services and any generated responses to provide, improve, and develop Google products and services and machine learning technologies, including Google's enterprise features, products, and services, consistent with our Privacy Policy.
>To help with quality and improve our products, human reviewers may read, annotate, and process your API input and output. Google takes steps to protect your privacy as part of this process. This includes disconnecting this data from your Google Account, API key, and Cloud project before reviewers see or annotate it. Do not submit sensitive, confidential, or personal information to the Unpaid Services.
From that document I read that it in fact does, but it doesn't release memory if app started consuming less. It does memory balooning though, so the VM only consumes as much RAM as the maximum amount requested by the app
It's a bit more complicated. For the purposes of the GDPR legal obligations within the EU (where we might assume relevant protections are in place) might be considered differently than eg legal obligations towards the Chinese communist party, or the NSA.
To clarify even further how this might translate into real-world advantage: I’m not trying to displace databases or reinvent grep, I’m aiming at use cases where agents need durable, fast-access memory that doesn’t disappear when a container shuts down.
Imagine an agent running inside a microVM or container. It doesn’t call Pinecone or Redis—it mounts VexFS. When it stores an embedding, it’s not going into a remote vector store, it’s being written alongside the file it came from, locally and semantically indexed. The agent can reboot, restart, or crash and still recall the same memory—because it lives inside the OS, not in RAM or ephemeral middleware.
This also means the agent can snapshot its cognitive state—“what I knew before I re-planned,” or “the thoughts I embedded before the prompt changed.” These aren’t just filesystem snapshots, they’re points in vector space tied to contextual memory. You could even branch them, like cognitive git commits.
Even search becomes something different. Instead of listing paths or grep results, you’re getting the files most semantically relevant to a query—right at the kernel level, with mmap access or zero-copy responses.
Most importantly, all of this runs without needing an external stack. No HTTP, no gRPC, no network calls. Just a vector-native FS the agent can think through.
Still early, very early. Still rough. But if we’re going to build systems where agents operate autonomously, they’ll need more than tokens—they’ll need memory. And I think that needs to live closer to the metal.
VexFS is part of a broader idea:
building infrastructure not for humans — but for agents.
Traditional filesystems, databases, and tools are all designed with human developers in mind:
- POSIX APIs
- Bash shells
- REST endpoints
Metadata we interpret visually
But intelligent agents don’t think like us. They need:
- Low-latency, associative memory
- Contextual retrieval, not paths and filenames
- Snapshotting of cognitive state, not just byte blocks
Direct memory-mapped embeddings, not serialized APIs
So why give them human abstractions?
VexFS is an experiment in flipping that.
It’s not optimized for you — it’s optimized for the agents you’re about to spawn.
Maybe we need:
- Filesystems that index vectors, not filenames
- Kernel modules that serve memory, not storage
- Logs that store intent, not just stdout
It's not about making AI fit Unix.
It’s about asking:
"What would Unix look like if it evolved under the pressure of AI, not sysadmins?"
That’s what I’m trying to find out.
Would love feedback on what other parts of the stack should be rethought for agents first. VFS? IPC? Memory management?
IMO, it's not about ethics, it's about legal risks. What if you want to fine tune a model on output related to your usage? Then my understanding is that all these derivatives need to be under the same license. What if G will change their prohibited use policy (the first line there is that they could update it from time to time)? There's really crazy stuff in terms of use of some services, what if G adds something in the same tune there which basically makes your application impossible.
It's not about ethical or not, it's about risk to your startup. Ethics are super subjective (and often change based on politics). Apache means you own your own model, period.
> Ethics are super subjective (and often change based on politics).
That's obviously not true. Ethics often have some nuance and some subjectiveness, but it's not something entirely subjective up to "politics".
Saying this makes it sound like you work at a startup for an AI powered armed drone, and your view of it is 'eh, ethics is subjective, this is fine' when asked how do you feel about responsibility and AI killing people.
> Ethics often have some nuance and some subjectiveness, but it's not something entirely subjective up to "politics".
Ethics are entirely subjective, as is inherently true of anything that supports "should" statements, because to justify any should statement, you need another "should" statement, you can never rest should entirely on "is" (you can, potentially, reset any entire system of "should" one root "should" axiom, though in practice most systems have more than one root axiom.)
And the process of coming to social consensus on a system of ethics is precisely politics.
You can dislike that this is true, but it is true.
> Saying this makes it sound like you work at a startup for an AI powered armed drone, and your view of it is 'eh, ethics is subjective, this is fine' when asked how do you feel about responsibility and AI killing people.
Understanding that ethics is subjective does not mean that one does not have a strong ethical framework that they adhere to. It just means that one understands the fundamental nature of ethics and the kind of propositions that ethical propositions inherently are.
Understanding that ethics are subjective does not, in other words, imply the belief that all beliefs about ethics (or, a fortiori, matters that are inherently subjective more generally) are of equal moral/ethical merit.
> Saying this makes it sound like you work at a startup for an AI powered armed drone, and your view of it is 'eh, ethics is subjective, this is fine' when asked how do you feel about responsibility and AI killing people.
Is it always wrong to kill people? If you say yes, then you are also saying it's wrong to defend yourself from people who are trying to kill you.
This is what I mean by subjective.
And then since Google is beholden to US laws, if the US government suddenly decides that helping Ukraine to defend itself is wrong, but you personally believe defending Ukraine is right, suddenly you have a problem...
If anyone at Google cares, I’d pay for Gemini Pro (not this new $200+ ridiculousness) if they didn’t train on my chats in that case. I actually would like to subscribe..
And lots of other features don't work, particularly external integrations. Gemini on Android refuses to do basic things like set a timer unless chat history is enabled. It is the one key feature I really want to pay extra to get, and that preference goes x2 when the AI provider is Google.
May I ask you to give examples of insights from topology which improved existing models, or at least improved our understanding of them? arxiv papers are preferred.
reply