cognee-bindings-common
(portable op bodies + stable error codes), so their surfaces line up 1:1. Each
exposes the same flow: warm() → add() → cognify() → search().
Module-level helpers exist in each binding for logging/telemetry setup. The
serve() / disconnect() cloud helpers live in the closed companion packages,
not in the OSS bindings. The full per-language method list lives in each
binding’s README and its generated docs.
Configuration
All three delegate to the sameConfigManager in cognee-bindings-common; the
difference is purely ergonomic (design decision A3.1, intentional for 0.1.0):
The generic
set("llm_model", value) already reaches every key, so C and Python
deliberately ship only the generic + bulk setters; JS adds the granular setters
as thin (infallible) sugar over the same underlying fields. Type errors surface
with the stable CONFIG_TYPE_MISMATCH code (C: CG_ERR_CONFIG_TYPE_MISMATCH) at
the call site. The full set of settable keys is the canonical Settings field
names — see Configuration and
crates/lib/src/config.rs. Field names are
camelCase in JS, snake_case in Python/C (matching the struct).
Unification path (post-0.1.0)
If full parity is required, mirror the JS macro-driven approach: addset_llm_model(value) / cg_sdk_config_set_llm_model(handle, value) etc. as thin
set_str("llm_model", value) wrappers in each binding’s idiomatic case
(~0.5 d/binding, mechanical).