Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Lens chat: allow an OpenAI-compatible endpoint (Ollama / llama.cpp / vLLM) instead of in-browser models

Abierto
#2,670 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
ollama

Línea de trabajo

Read the existing Lens local agent panel, the OpenAI-style chat call, daemon configuration and route handling, and the legacy llm/start.sh sidecar path. Trace how the UI sends chat requests and how daemon settings are stored before choosing an endpoint flow. Done means an opt-in endpoint setting supports a base URL, model, and optional API key, with the daemon forwarding chat requests and the panel exposing the choice.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

editor/integration enhancement ux/behavior
What problem does this solve?

CBM Lens's "Chat with your codebase locally" runs small ONNX models inside the browser (Qwen2.5-Coder 0.5B, Qwen3 0.6B, Qwen3.5 2B, ... fetched from Hugging Face, WebGPU with shader-f16). For people who self-host the MCP server, that leaves a gap:

  • Many of us already run a local model server (Ollama, llama.cpp llama-server, vLLM, LM Studio) with models far larger and better than a 0.5B-2B browser model. Lens cannot use them, so it asks to download its own copy (about 567 MB for the default) per browser, per device, and the cache is not shared.
  • When Lens is served from a headless box or container and opened from another machine or a phone, the browser model is the weakest possible setup: no WebGPU on many devices, and the model is downloaded again on each one.
  • The bundle already has the plumbing for an OpenAI-style chat call (POST {origin}/v1/chat/completions, with chat_template_kwargs and an optional model), but as far as I can tell it is the "legacy sidecar": fixed at 127.0.0.1:4141 in the viewer's browser, expecting a hand-started llama.cpp server (llm/start.sh), and documented as "not the active browser agent". There is no setting for pointing it somewhere else.

Context: I run codebase-memory-mcp v0.12.1 in a container on a home server (MCP over a stdio-to-HTTP bridge, Lens behind a reverse proxy on a private network). Anyone self-hosting the graph is likely to self-host models too.

Proposed solution

An optional, explicit "Model endpoint" setting for the Lens agent, off by default:

  • base URL (OpenAI-compatible, e.g. http://ollama:11434/v1), model name, optional API key;
  • stored in the daemon config (e.g. config set llm_endpoint ...) and shown in the existing "Local agent" panel as a second choice next to the in-browser models.

Preferably the daemon makes the request (the UI posts to a daemon route and the daemon forwards to the configured endpoint), not the browser. That avoids CORS, avoids mixed-content blocking when Lens is served over HTTPS, keeps any API key out of the browser, and works when the model server is reachable from the daemon but not from the viewer. The existing guarantees can stay as they are: nothing is sent unless the endpoint is configured and the agent is on, the "rewrite guard" still drops claims the source does not show, and the panel can state plainly when the endpoint is not loopback.

Alternatives considered
  • Keep the in-browser models and just use them. Works, but the 0.5B-2B models are modest, are downloaded per browser, and do not run well on phones or machines without WebGPU.
  • Use the legacy sidecar (127.0.0.1:4141). Only reaches the viewer's own loopback, so it does not work for a server-hosted Lens, and it is marked legacy.
  • Ask an MCP client (Claude Code etc.) instead of Lens chat. That is what I do for deep questions; this request is only about making Lens's built-in explanations usable with models people already host.

Happy to test a build against Ollama and llama.cpp.

Confirmations
  • I searched existing issues and this is not a duplicate. (Searched for Ollama, OpenAI-compatible, local model endpoint, Lens chat, llama.cpp sidecar, external model.)
Lenguaje dominante
C
Estrellas
45.8k
Forks
3.8k
Merge medio
3 d 11 h
PR fusionados (30 d)
201

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de DeusData/codebase-memory-mcp

Todos los issues de DeusData/codebase-memory-mcp

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.