-
Notifications
You must be signed in to change notification settings - Fork 0
3.1 market positioning
The project occupies the middleware layer between raw model runners and production applications. In 2025–2026, the AI vision landscape has polarized into two extremes:
- Model Runners (Ollama, vLLM, LM Studio) — excellent at loading and inferencing models, but provide no multi-user API gateway, no preprocessing, no job queuing, and no production-grade error handling.
- Cloud Vision APIs (GPT-4o, Azure Computer Vision, Google Cloud Vision) — powerful and convenient, but offer no control over preprocessing, create vendor lock-in, and raise data sovereignty concerns.
@CKIR.IO/VISIONS bridges this gap. It is a dedicated backend microservice that consumes models through Ollama and exposes them via production-ready HTTP APIs (REST + MCP), with image preprocessing, asynchronous queuing, and real-time streaming.
Neither Ollama, Open WebUI, nor cloud APIs provide configurable image preprocessing. They accept raw uploaded images directly. @CKIR.IO/VISIONS generates multiple variants (original, grayscale, denoised, sharpened, CLAHE) using Sharp, and appends semantic descriptions so the model understands what each variant represents. For OCR and document analysis workflows, this produces measurably better accuracy on low-quality inputs.
MCP is now an open standard under the Linux Foundation (2025). Claude, ChatGPT, VS Code, Cursor, and Zed all support it natively. By exposing visions.analyze as an MCP tool, this project plugs directly into the fastest-growing AI agent interoperability ecosystem — a significant competitive moat that most self-hosted vision tools lack.
The included Vue 3 dashboard is not a consumer product. It is a developer testing and integration environment — a live API client, event inspector, and preprocessing sandbox for engineers building on top of the microservice. This is a deliberate choice: it positions the server as infrastructure, not an application.
AI tooling is overwhelmingly Python-based (Open WebUI, vLLM, TGI). A NestJS + Fastify backend provides:
- Dependency injection and modular testability
- Strict TypeScript contracts across the API boundary
- Native async/await performance without GIL constraints
- Horizontal scaling patterns familiar to enterprise Node.js teams
| Capability | Value |
|---|---|
| Multi-variant preprocessing | Improves OCR and detail extraction accuracy by optimizing image input before inference. |
| Async queue + streaming | BullMQ handles backpressure and retries; Socket.IO streams tokens as they generate. Essential for production workloads where models can take 10–60 seconds. |
| Dual protocol support | REST for traditional integrations; MCP for AI agents. Both share the same preprocessing and queue backend. |
| Privacy-first self-hosting | No data leaves the infrastructure. Critical for healthcare, finance, and government sectors. |
| Job cancellation | Atomic cancellation of queued or active jobs via request ID — unavailable in most raw model runners. |
| Queue resilience | Exponential backoff, 15 retry attempts, Redis persistence, and UnrecoverableError for deterministic failures. |
| Limitation | Impact | Mitigation |
|---|---|---|
| Ollama ecosystem lock-in | The entire inference path depends on Ollama's API stability and model format support. | Ollama is the dominant self-hosted runner (170k+ stars) and actively maintained. The abstraction layer could be extended to vLLM if needed. |
| Infrastructure complexity | Requires Node.js, Redis/KeyDB, and Ollama to run. Not a single-binary deployment. | Docker Compose and monorepo structure reduce setup friction for developers. |
| No cloud API fallback | If Ollama is unavailable, there is no automatic fallback to OpenAI or Gemini. | Could be added via a provider abstraction layer, but is not currently implemented. |
| Developer-only UI | The dashboard is an engineering tool, not an end-user application. Teams must build their own frontend or integrate via API. | This is intentional (infrastructure positioning), but increases time-to-value for non-technical users. |
| Smaller community than Python alternatives | Fewer contributors, plugins, and Stack Overflow answers compared to Open WebUI or Gradio ecosystems. | Strong documentation (.wiki/) and NestJS modularity lower the barrier to contribution. |
| Tool | Type | Preprocessing | MCP | Queue | Self-Hosted | Your Advantage |
|---|---|---|---|---|---|---|
| Ollama | Model runner | ❌ No | ❌ No | ❌ No | ✅ Yes | You add API gateway, preprocessing, and queuing on top. |
| Open WebUI | Chat UI/backend | ❌ No | ❌ No | ✅ Yes | You are backend-only, not a monolithic chat app. You have preprocessing and MCP. | |
| LocalAI | OpenAI-compatible API | ❌ No | ❌ No | ❌ No | ✅ Yes | You specialize in vision with preprocessing and streaming; LocalAI is general-purpose. |
| vLLM / TGI | Python inference server | ❌ No | ❌ No | ✅ Yes | You are higher-level (preprocess → queue → stream) vs. raw inference optimization. |
| Service | Type | Preprocessing Control | Privacy | Cost Model |
|---|---|---|---|---|
| GPT-4o | Cloud API | ❌ None | ❌ External | Per-token usage |
| Google Cloud Vision | Cloud API | ❌ None | ❌ External | Per-feature call |
| Azure Computer Vision | Cloud API | ❌ None | Per-call or reserved capacity |
Your positioning: You compete not on model quality (cloud APIs win there) but on data sovereignty, preprocessing control, MCP agent interoperability, and cost predictability for high-volume batch workloads.
In 2025–2026, the industry is converging on agentic AI and standardized tool protocols. @CKIR.IO/VISIONS is positioned exactly where those trends intersect:
- Self-hosted infrastructure for data-sensitive workflows
- MCP protocol for AI agent integration
- Preprocessing pipeline for accuracy-demanding tasks
- Async + streaming architecture for production reliability
It does not attempt to be a general AI chat interface or a model training platform. It is a specialized vision analysis gateway — and in that niche, it has no direct open-source equivalent.
- 1-server — Server architecture and request lifecycle
- 1.2-mcp — MCP protocol implementation details
- 1.5-image-preprocessing — Preprocessing pipeline architecture
- 2-dashboard — Dashboard purpose and scope
- 3-ai-assisted-development — Development methodology and code ownership