Use the cognee CLI
cognee-cli ships with the package (entry point in cognee/cli/_cognee.py;
each command lives in cognee/cli/commands/). Every command has
--help for its flags, but only a few (demo, memify, eval, serve,
push, upgrade, downgrade, stamp, and search with one CODE example)
include usage examples — for the memory commands use the examples
in this file. Needs LLM_API_KEY configured, same as the SDK.
Core flow
The memory commands are the primary surface as of cognee 1.x:
cognee-cli remember "Your text here" # also accepts file paths / URLs
cognee-cli remember ./docs --dataset-name my_project
cognee-cli recall "Your question" # query the graph
cognee-cli recall "keyword" --query-type CHUNKS
cognee-cli forget --all # wipe local state
remember is ingest + graph build in one step (add + cognify under the
hood); --background/-b runs the cognify stage in the background, and
--dry-run estimates LLM tokens/cost without ingesting. recall takes
--datasets/-d, --top-k/-k (default 10), and --session-id/-s.
forget targets --dataset, --dataset-id, --data-id (needs a dataset), or
--everything/--all — one unified command replacing the older delete and
empty-dataset paths. --memory-only (with a dataset) drops the graph and
vectors but keeps the raw files, so the data can be rebuilt.
forget --all does not ask for confirmation. It deletes every dataset
immediately, even on a non-interactive stdin. The legacy delete --all
prompts Delete ALL data from cognee? [y/N] first, so switching to forget
silently drops that safety net — script it with care.
--query-type accepts 10 of the SDK's 20 SearchType values — the list in
cognee/cli/config.py:SEARCH_TYPE_CHOICES: HYBRID_COMPLETION, GRAPH_COMPLETION,
RAG_COMPLETION, CHUNKS, CHUNKS_LEXICAL, SUMMARIES, CODE, CYPHER, GRAPH_REPORT,
SKILLS. The rest (TEMPORAL, TRIPLET_COMPLETION, GRAPH_COMPLETION_COT,
AGENTIC_COMPLETION, NATURAL_LANGUAGE, …) are SDK-only, e.g.
cognee.recall(q, query_type=SearchType.TEMPORAL).
When --query-type is omitted the CLI uses HYBRID_COMPLETION
(DEFAULT_SEARCH_TYPE), whereas the SDK's cognee.recall() auto-routes
between search types. --top-k defaults to 10 on the CLI and 15 in the SDK.
Session memory and enrichment
Session entries are currently written from the SDK — cognee.remember(..., session_id="chat_1") — not the CLI (cognee-cli remember has no session
flag). The CLI side of session memory is reading and bridging:
cognee-cli recall "question" -s chat_1 # session cache first: without -d/-t
# this searches the session directly
cognee-cli sessions get # retrieve session Q&A history
cognee-cli improve -d my_project -s chat_1 # bridge session content into the graph
cognee-cli improve -d my_project # enrich/index the graph (no session)
cognee-cli feedback ... # attach feedback to results
improve also takes --node-name, --feedback-alpha (learning rate in
(0, 1]; default IMPROVE_FEEDBACK_ALPHA, 0.1), --build-global-context-index,
--build-truth-subspace (both opt-in stages; the truth subspace needs
-s), and --background/-b. It prints one line per stage — name, status
(completed / already_completed / skipped / errored) and the skip
reason (e.g. no_session_ids, lock_held, triplet_embedding_disabled).
remember/improve build their graphs through cognify(), so cognify-level
settings (e.g. CONTRADICTION_DETECTION=true) apply to them too.
Legacy / lower-level commands
add, cognify, search, memify, and delete still ship and are what the
memory commands call underneath. Use them only to drive a single stage in
isolation; prefer remember/recall/forget/improve otherwise.
cognee-cli add "text" && cognee-cli cognify # what `remember` does in one step
cognee-cli search "question" # `recall` minus routing/scope/session sources
cognee-cli memify -d my_project # custom extraction/enrichment tasks
cognee-cli delete --all # superseded by `forget --all`
Management
cognee-cli datasets list # dataset operations
cognee-cli config get [key] [--show-secrets] # view one/all settings (API keys masked by default)
cognee-cli config set <key> <value> # set + persist to ./.env in the cwd
cognee-cli config unset <key> # reset a key to its default (also persisted)
cognee-cli -ui # launch API server + UI (see cognee-server skill)
cognee-cli serve --url http://localhost:8000 # connect CLI/SDK to a running instance
Database migrations
cognee has two migration chains: the relational schema (Alembic, in
cognee/alembic/) and the graph/vector data chain (slugs registered in
cognee/modules/migrations/registry.py). Both run automatically — at API
server startup and on the first write (remember, add, cognify,
improve, …) in an SDK/CLI process — unless ENABLE_AUTO_MIGRATIONS=false.
So you rarely need these commands; they are for inspecting state, disabled
auto-migration, and rollbacks. There is no migrate command.
cognee-cli current # stamped revision per database (per dataset
# with access control on)
cognee-cli history # the data-migration chain, newest first
cognee-cli upgrade # relational to head, then data chain to head
cognee-cli upgrade <slug> # data chain up to and including <slug>
cognee-cli upgrade --alembic <rev> # pin the relational (Alembic) target
cognee-cli downgrade <slug|base> # REWRITES DATA; revision is required,
# prompts unless --force; --dataset <uuid>
# (repeatable) limits it
cognee-cli stamp <head|base|slug> # set the stored revision WITHOUT running
# anything; prompts unless --force;
# --dataset <uuid> (repeatable) limits it
The positional revision is always a data-chain slug; the relational
target goes through --alembic. downgrade leaves the relational schema
alone unless you pass --alembic. upgrade runs even when
ENABLE_AUTO_MIGRATIONS=false. --alembic-path (or COGNEE_ALEMBIC_PATH)
points at a custom Alembic scripts directory.
Gotchas
- The CLI initializes cognee lazily; the first command in a fresh environment
is slow (DB + model setup), later ones are fast.
remember (and add) without --dataset-name targets the default dataset
main_dataset; recall/search operate across your accessible datasets
unless a dataset is given.forget refuses to run bare — pass --dataset, --dataset-id, --data-id
(with a dataset), or --everything/--all.- Session commands (
recall -s, sessions get, improve -s) require
CACHING=true (the default) — with it off, session reads return nothing and
SDK session writes raise. To cut read latency and token cost while keeping
session memory, cognee-cli config set AUTO_FEEDBACK false — by default
cognee makes one structured-output LLM call per answered query to self-tune
its memory.
memify requires one of the arguments -d/--dataset-name --dataset-idconfig set/config unset write to the .env file in whatever directory
you run the command from (creating it if missing). config reset (reset
all keys) is still not implemented.- Which
.env actually wins is not always the cwd one. At import, cognee
calls dotenv.load_dotenv(override=True), which resolves relative to the
cognee package location, not your working directory. In a source/editable
checkout (uv pip install -e .) a .env at the repo root therefore shadows
the .env in the directory you ran from — and because override=True, it
also beats variables you exported. Symptom: config set appears to do
nothing, or the CLI connects to a backend you thought you had overridden.
To test against different settings, move the repo .env aside, or set
values programmatically after import (cognee.config.set_*). (Under
python -c the cwd .env does win, because dotenv falls back to the cwd
when __main__ has no __file__ — which is why the same command can
behave differently as a script vs. -c.)
anthropics/skills180k
