Thoughts about built-in local Qwen 3.5+ model integration?

[MjrTom]

Recently another commercial LLM coding-assistant oriented VS Code fork corporation has also shot itself in the foot while jumping off the bridge that its friends jumped off of, prompting a mass exodus of its user base too.

This is the third one I'm aware of in recent months, and counting non-VSCode fork cases also; the ~eighth that I'm aware of in the past ~1.5 years.

This has renewed interests in alternative development environments among very many people, although I have hardly any idea what portion of them are interested in .NET.

For me; my renewed interests definitely includes SharpIDE, especially because it's basically pure .NET, and MIT-licensed.

There's now a SERIOUS vacuum of coding-assistant development environments that legitimately suit the interests of the users, enabling them to code the way they want, rather than trying to dictate how they must.

THIS MIT-licensed open-source project could be immune to exhibiting the problems that have driven away so many developers from so many other platforms, if there's such a will.

These rug pulls are potentially a FANTASTIC opportunity to solicit development assistance for SharpIDE, depending on what portion of coders in the 'coder-diaspora' are interested in .NET.

Many of us are already faced with having to put substantial efforts into establishing a new suitable, stable development environment and workflow after this latest rug-pull.

Maybe like-minded people should put their energies into making this a larger community project we can all feel a sense of ownership in, to help it be closer to the way we want things to be, while hopefully remaining immune to the potential for the rug pulls that so many have felt, even multiple times?

Pursuant to my own interests; I've been working on reinterpreting this relatively simple C Qwen 3.5 dense model code into a somewhat optimized, hardware agnostic C# library: https://github.com/kroggen/qwen3.5-c

While working on this, it's occurred to me that perhaps it might work well for SharpIDE to have native and well integrated local Qwen 3.5+ (dense) model running capability? The C code doesn't support MoE checkpoints, but MoE is probably possible with maybe just several more days work from the dense runner basis.

I'm not personally interested in:

1. How to run all different models locally in .NET in SharpIDE. Just Qwen 3.5+, for now.
2. The "the fastest possible way" to run local Qwen 3.5+ models (such as acceleration via the various possible types of GPUs, not even by way of the .NET libraries that might facilitate using them). Just a good way to run it on all computer-like devices that can run .NET.
3. The most powerful .NET way of running local models in SharpIDE, which might be with some of the MS libraries or frameworks. I want my own code, that can do it my way, and start out relatively simple.
4. Trying to incorporate the many existing ways of running locals models (llama.cpp, LM Studio, etc) within SharpIDE. Maybe others might want to do that?

My current relevant interests are mostly just in working out a rather optimized, cross-platform, absolutely hardware agnostic, .NET way of running local Qwen 3.5+ models for a coding assistant (whichever IDE I use). With some various progressively advanced ideas to follow on from there. The question is about SharpIDE user interests in that specific thing being integrated into SharpIDE?

Native, well integrated OpenAPI endpoint model access would also be very beneficial for "A modern, cross platform & open source IDE for .NET", although I don't have much personal interests in trying to work on that whole thing beyond a relationship with local Qwen 3.5+ models.

Of particular use would be a facility that specializes in accessing the numerous various free LLM coding assistant resources. There's so many people around the world that could benefit tremendously from a facility specialized like that.

A good balance might be: SharpIDE having an abstract faculty of integrated coding assistance, with me pursuing a local Qwen 3.5+ option, and as much of the abstract framework to utilize it as necessary?

What thoughts are there from Matt Parker and whatever community there might be here about these trains of thought?

I'm not at all familiar with the internals of SharpIDE. I don't immediately see any facility of extensions/plugins. I call this out because I find coding assistant extensions to VS Code to be noticeably inferior than integrated solutions. The integrated nature of the VS Code forks was quite an advantage for them IMO. Too bad they've all worked so hard to counterbalance that advantage with antagonism and outright hostility towards their own paying clients, in favor of some unseen motivating forces driving them ALL insane.

I'm aware of at least one other, also AI-integrated, open source solution which is not a VS Code fork, but nor is it .NET. It's also under the GPL version 3 license, which many people don't want to contribute too. It's developed by a for-profit company too. That's not necessarily bad, and there could be ways for SharpIDE to someday go for-profit without doing so in a way that's a rug-pull on the users.

If there's not adequate intersection between community interests and my personal interests, then I suppose I'll continue on with my own interests, in my own way.

[MjrTom]

I've just learned of this library: https://github.com/daisinet/daisi-llogos which is a highly accelerated C# implementation of llama.cpp, with typescript instead for a couple of appropriate .NET target platforms.

Because of specifics of what it does and how it does them that I've seen so far, unless there's something about it I didn't notice yet; I could be interested in natively integrating local model operation into SharpIDE, of all local models that library natural runs, using the hardware acceleration it already has in it.

I'm still trying to gauge the interest level of any SharpIDE users, or even just the main dev, in SharpIDE having this sort of nature to it.

[lextm]

To ensure broad compatibility and avoid duplicate efforts in the future, integrating Qwen model support through a standardized common interface is desired and applicable to all models and AI tools.

#78 might provide such an opportunity.