idea(neocore): preserve the daemon, virtual-model routing and flat-agent direction #148

Now, I am adding I assume that this is prox, sorry, provider agnostic. It doesn't give a shit if I add a new provider, take away a provider from my connected NeoPy instance. but I'm gonna have NeoProxy soon. And NeoProxy is gonna be like the sort of core of like, how inference is served. Right, even in the harness, like even in NeoPy, I will have NeoProxy as a provider within NeoPy, right? And that will likely be the only provider that I expose to things like you know, OMP deck, now called NeoDeck, or this T3 code fork, now called NeoCode. It's only going to be this one singular provider, and this one provider is gonna have routes, basically like this multi-stage system. So, well, it's called virtual models, to be specific. You can create a virtual model with any name, just like you, you can create a role with any name. You can assign it to, say, I don't know GPT fucking 6.1 soul which the other day they had an, an outage or something, I don't recall, but they were at, oh yeah, they were at capacity, that was it. So they're at capacity sometimes. Or you're at capacity sometimes. Maybe you're a fucking account is at 91%, which mine is, but I don't care because I have a reset. but imagine you don't. Great, you can pool accounts. That's something that's already a thing in Neopai. Neopai's credential vault can already do this. You can already log in with more than one account. How it actually distributes that, I'm not really sure. I'm not really sure what it does if you have more than one codec subscription and one of them's like nearly out, if it just, I don't know, drains them sequentially, but that's gonna be handled by the proxy layer. so certain functionality is gonna have to be cut out of NeoPy, and this is where we all need to coordinate together, right? Because changing one thing here changes how, changes the implications over there, right? It changes the implications for the GUI. this is why I have been getting to OMP deck last like I haven't gotten to that yet and I haven't gotten to this yet either, because if I, I need to get the core correct and I need to get it like in a sort of state where anything I add to the core is not a foundational change in either the deck or the, or, or NeoCode. neither of the two graphical front ends, right? And you might be wondering, why NeoDeck? Why, what, what's with NeoDeck? Okay, let me explain. Think of NeoCode as a... Think of it as a VS Code, right? It's not VS Code, obviously, but think of it as a VS Code. Think of NeoDeck as a... I suppose like a GitHub. Thing is that analogy, no, that analogy kind of falls flat on its face. GitHub doesn't have an editor. Well, it does, but it's shit. There are several components that are worth naming abstractly, and perhaps I should talk to a agent dedicated for this, like a fable agent or a opus, or a council, actually, really, a council would be nice. but think of it like this. We have the local component. Let's start with, like, what we have concretely. We have credential stores. This, we, we have a core, and these, this core is a credential store, a vault. This can connect to all different providers and send inference to all of these different providers. Great. Now, how do we build something around that? Well, we build an API, an engine, that can communicate over our PC, or over whatever. It can be our own protocol. I don't know if our PC is, like, limiting in some way for you, but it can do things that no other, yeah, it, it, yeah, I don't know if our PC's sufficient, is it? It's just fucking JSON, isn't it? And for the things I'm imagining, it's like we'd want our own protocol, sort of. I mean, like UDP Would be kind of necessary for some of the things I have in mind.