After spending hours attempting to integrate a local Ollama instance with Next AI Draw.io, it is glaringly evident that the advertised "multi-provider and local LLM support" is barely an afterthought, heavily decoupled from real-world usage.
While the demo website works smoothly thanks to massive cloud models (GLM, Doubao, Claude) sponsored on the backend, running actual local models on modern consumer hardware exposes major architectural and UX flaws:
-
Hardcoded and broken provider URL handling
The default Ollama provider template is broken out of the box. Setting a standard local endpoint results in routing failures (e.g. attempting to append endpoints incorrectly, resulting in .../v1/chat errors). The only way to get a handshake is by ditching the Ollama provider entirely, creating a generic "OpenAI" custom profile, and manually overriding routes. Why provide a dedicated Ollama UI preset if its path resolution is broken?
-
Forcing bloated mxGraph XML on local models
The application strictly demands raw mxGraph XML without providing any intermediate formats. Generating thousands of tokens of verbose XML with exact manual coordinates and inline styling is the worst possible task for local 7B–14B models. Generating a simple flow diagram takes several minutes on high-end GPUs (whereas ComfyUI generates complex diffusion batches in seconds). Why is there no option to generate via compact structures like CSV Import or Mermaid, letting the client-side engine handle placement?
-
Zero tolerance in response parsing
Local models inevitably output brief conversational pleasantries, chain-of-thought traces, or enclose responses in markdown code blocks (```xml). The response parser in this client exhibits zero resilience: the moment a single unexpected token appears before ``, the parser completely chokes, fails to mount the diagram to the canvas, and dumps raw text into the chat. A simple regex sanitizer or system prompt override option in the UI would resolve 90% of these failures.
-
Locked system prompts & "Walled Garden" UX
Users are completely locked out of customizing the system prompt or output contracts for custom providers. There is no way to inject strict output schema controls, disable chain-of-thought text, or tune temperature globally for local profiles.
Conclusion
Right now, the local AI integration feels like pure marketing fluff to collect stars. Unless you are feeding paid cloud APIs with massive context windows, running local models through this UI results in minutes of wasted GPU compute only to end up with disconnected boxes or raw chat dumps.
If you want this project to truly support local AI workflows, implement resilient stream cleaning, expose system prompts in custom provider configurations, and add support for lightweight formats like CSV import instead of relying solely on heavy XML generation.
After spending hours attempting to integrate a local Ollama instance with Next AI Draw.io, it is glaringly evident that the advertised "multi-provider and local LLM support" is barely an afterthought, heavily decoupled from real-world usage.
While the demo website works smoothly thanks to massive cloud models (GLM, Doubao, Claude) sponsored on the backend, running actual local models on modern consumer hardware exposes major architectural and UX flaws:
Hardcoded and broken provider URL handling
The default Ollama provider template is broken out of the box. Setting a standard local endpoint results in routing failures (e.g. attempting to append endpoints incorrectly, resulting in .../v1/chat errors). The only way to get a handshake is by ditching the Ollama provider entirely, creating a generic "OpenAI" custom profile, and manually overriding routes. Why provide a dedicated Ollama UI preset if its path resolution is broken?
Forcing bloated mxGraph XML on local models
The application strictly demands raw mxGraph XML without providing any intermediate formats. Generating thousands of tokens of verbose XML with exact manual coordinates and inline styling is the worst possible task for local 7B–14B models. Generating a simple flow diagram takes several minutes on high-end GPUs (whereas ComfyUI generates complex diffusion batches in seconds). Why is there no option to generate via compact structures like CSV Import or Mermaid, letting the client-side engine handle placement?
Zero tolerance in response parsing
Local models inevitably output brief conversational pleasantries, chain-of-thought traces, or enclose responses in markdown code blocks (```xml). The response parser in this client exhibits zero resilience: the moment a single unexpected token appears before ``, the parser completely chokes, fails to mount the diagram to the canvas, and dumps raw text into the chat. A simple regex sanitizer or system prompt override option in the UI would resolve 90% of these failures.
Locked system prompts & "Walled Garden" UX
Users are completely locked out of customizing the system prompt or output contracts for custom providers. There is no way to inject strict output schema controls, disable chain-of-thought text, or tune temperature globally for local profiles.
Conclusion
Right now, the local AI integration feels like pure marketing fluff to collect stars. Unless you are feeding paid cloud APIs with massive context windows, running local models through this UI results in minutes of wasted GPU compute only to end up with disconnected boxes or raw chat dumps.
If you want this project to truly support local AI workflows, implement resilient stream cleaning, expose system prompts in custom provider configurations, and add support for lightweight formats like CSV import instead of relying solely on heavy XML generation.