alvis
fb93655636
Reverse the earlier 'default to LiteLLM' recommendation: per user intent, cognee runs its LLM on the Kimi subscription via cognee-llm (the reason the wrapper exists). Gate-5 latency is an accepted tradeoff; LiteLLM stays a documented fallback. Embeddings remain on LiteLLM nomic-embed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LeqyaxJF2nbRXJtae2kNB2
2.8 KiB
cognee-llm (:8011)
OpenAI-compatible wrapper around the Kimi Code CLI (@moonshot-ai/kimi-code, home
/root/.kimi-code), built for Cognee's batch/structured LLM calls. Opposite policy to
kimi-agent:
- Stateless one-shot — fresh temp dir under
/workspace/<uuid>per request,kimi -p <prompt> --output-format stream-json, no-r/-Sresume, dir removed after every call (success or failure). - Non-streaming — always returns a full
chat.completionbody, even if the caller setsstream: true. - No media, no MCP — text-only prompt built from
messages; no image persistence, no.mcp.json. - Structured/low-temperature intent via prompt, not a sampling param — the CLI has no raw temperature knob (it's an agent loop, not a completions API), so determinism/JSON-only output is enforced with an instruction preamble prepended to the caller's system prompt.
- Bounded concurrency —
MAX_CONCURRENCY = 3inserver.js, queued beyond that.
Endpoints: GET /v1/models (model id cognee-llm), POST /v1/chat/completions.
Own disposable in-container /workspace (no host bind mount — nothing here is meant to
survive a request, let alone a container restart) + own cognee-llm-home volume
(/root/.kimi-code), same Kimi subscription as kimi-agent/adolf-llm, separate volume so
each wrapper's CLI state stays isolated.
This IS Cognee's LLM backbone
By design, Cognee's LLM runs on the flat Kimi subscription through this wrapper — the whole
reason it exists — mirroring how adolf-llm backs the assistant. P4 wires cognee's
LLM_ENDPOINT → http://cognee-llm:8011, LLM_MODEL → openai/cognee-llm.
Accepted tradeoff (SPIKE-FINDINGS gate 5). The CLI's JSON output is clean/schema-conformant,
but it's slower than a raw API: ~5s fixed per-invocation floor + ~22-24s for a realistic
structured-extraction call, and every call is agentic. Cognify issues one call per
chunk/entity-extraction step, so large batches serialize into minutes. To protect the
single-seat subscription, MAX_CONCURRENCY = 3 bounds concurrent spawns.
Documented fallback (not the default): if cognify throughput ever becomes a real problem,
route cognee's LLM to a LiteLLM model instead (ARCHITECTURE.md §3.3) — see the commented block
in cognee/cognee.env. Embeddings already run on LiteLLM's nomic-embed regardless (embeddings
can't go through the agentic CLI).
Smoke test
cd /home/alvis/agap_git/openai
docker build -t cognee-llm:local ./cognee-llm
docker run --rm -d --name cognee-llm-smoke -p 18011:8011 cognee-llm:local
curl -s http://localhost:18011/v1/models
docker rm -f cognee-llm-smoke
A full /v1/chat/completions round-trip needs a kimi login-authed
/root/.kimi-code volume (shared Kimi subscription) — not present in a bare smoke container,
so that step is deferred to integration/P4 wiring.