> ## Documentation Index > Fetch the complete documentation index at: https://docs.cognee.ai/llms.txt > Use this file to discover all available pages before exploring further. # Visualize Brains Summary > Return every dataset the caller may read, described from relational metadata. The cheap counterpart of `GET /visualize/brains`: the same datasets, but only what an overview shows — name, sources, size, colors — built from relational metadata and the per-cognify-run count cache instead of one bounded graph read per dataset. The cost is one count query per cognify run whose count is not cached yet, not a graph fetch per dataset on every call, so a cold cache pays once per run and every later call pays nothing. `/brains` stays the call to make when the node and link arrays themselves are needed. ## Response `{dataset_id: {"name", "source_names", "node_count", "node_set_colors"}}`: - **name** (str): the dataset's name - **source_names** (list[str]): its distinct node set names, sorted; empty when the data was ingested without node sets - **node_count** (int): nodes in the dataset's graph as of its latest cognify run — the whole graph, not only entity nodes, and 0 for a dataset that has never been cognified - **node_set_colors** (dict[str, str]): node set colors from the same rule `/brains` uses. Same rule and same node sets give the same colors, but the two endpoints can be looking at different node sets — `/brains` takes them from a bounded graph fetch (and so sees sets that exist only in the graph), this takes them from a full relational scan — and where the sets differ the colors do too ## Error Codes - **409 Conflict**: Payload could not be built (generic message; full detail is server-logged, not returned, to avoid leaking internals) ## Notes - Only datasets the caller has read permission on are included ## OpenAPI ````yaml /cognee_openapi_spec.json get /api/v1/visualize/brains-summary openapi: 3.1.0 info: title: Cognee API description: Cognee API with Bearer token and Cookie auth version: 1.0.0 servers: - url: https://api.cognee.ai description: Production server (full functionality) - url: http://localhost:8000 description: Local development server (requires local setup) security: - BearerAuth: [] - ApiKeyAuth: [] tags: - name: activity description: >- Activity endpoints for inspecting pipeline runs, traced spans, tenant users, agents, and dataset exports. - name: add description: Data ingestion endpoints for adding text, files, and structured data. - name: agent connections description: >- Endpoints for registering, unregistering, and inspecting agent connections to the instance. - name: agent management description: Endpoints for creating, listing, retrieving, and deleting agents. - name: auth description: >- Authentication endpoints for user registration, login, and token management. - name: checks description: >- Diagnostic endpoint for validating a Cognee Cloud API key supplied in the X-Api-Key header. - name: cognify description: >- Knowledge processing endpoints to transform raw data into knowledge graphs. - name: configuration description: >- Endpoints for storing, retrieving, and listing a user's saved configurations. - name: datasets description: Dataset management endpoints for listing, creating, and deleting datasets. - name: delete description: Data deletion endpoints (deprecated — use datasets endpoints instead). - name: forget description: Endpoint for removing data from the knowledge graph. - name: health description: Liveness, readiness, and component health checks. - name: improve description: Endpoint for enriching and improving an existing knowledge graph. - name: integrations description: >- Endpoints for connecting, provisioning, and disconnecting OAuth providers and plugins. - name: llm description: >- LLM-backed endpoints for inferring graph schemas and generating custom extraction prompts. - name: memify description: >- Endpoint for running enrichment pipelines over existing graphs or supplied data. - name: ontologies description: >- Endpoints for uploading, listing, and deleting ontology files used during cognify. - name: permissions description: Permission management for multi-user access control. - name: recall description: >- Endpoints for querying the knowledge graph and reviewing past recall history. - name: remember description: >- Endpoints for ingesting data into the knowledge graph and storing session memory entries. - name: responses description: Response generation endpoints using the knowledge graph. - name: schema description: >- Schema inspection endpoints for a dataset's derived schema inventory and the caller-wide memory provenance graph. - name: search description: Search endpoints for querying the knowledge graph. - name: sessions description: >- Endpoints for listing sessions and reporting usage, cost, and token statistics. - name: settings description: Configuration endpoints for managing Cognee settings. - name: skills description: >- Skill management endpoints for ingesting, listing, retrieving, and deleting dataset skills, plus read-only retrieval of improvement proposals. - name: slack description: >- Endpoints for listing workspace channels, setting channel allowlists, and linking Slack accounts. - name: sync description: Endpoints for syncing local data to Cognee Cloud and checking sync status. - name: update description: Endpoint for updating existing data in a dataset. - name: users description: User management endpoints. - name: validate description: >- Diagnostic endpoint for checking consistency between a dataset's graph and vector stores. - name: visualize description: Graph visualization endpoints. paths: /api/v1/visualize/brains-summary: get: tags: - visualize summary: Visualize Brains Summary description: >- Return every dataset the caller may read, described from relational metadata. The cheap counterpart of `GET /visualize/brains`: the same datasets, but only what an overview shows — name, sources, size, colors — built from relational metadata and the per-cognify-run count cache instead of one bounded graph read per dataset. The cost is one count query per cognify run whose count is not cached yet, not a graph fetch per dataset on every call, so a cold cache pays once per run and every later call pays nothing. `/brains` stays the call to make when the node and link arrays themselves are needed. ## Response `{dataset_id: {"name", "source_names", "node_count", "node_set_colors"}}`: - **name** (str): the dataset's name - **source_names** (list[str]): its distinct node set names, sorted; empty when the data was ingested without node sets - **node_count** (int): nodes in the dataset's graph as of its latest cognify run — the whole graph, not only entity nodes, and 0 for a dataset that has never been cognified - **node_set_colors** (dict[str, str]): node set colors from the same rule `/brains` uses. Same rule and same node sets give the same colors, but the two endpoints can be looking at different node sets — `/brains` takes them from a bounded graph fetch (and so sees sets that exist only in the graph), this takes them from a full relational scan — and where the sets differ the colors do too ## Error Codes - **409 Conflict**: Payload could not be built (generic message; full detail is server-logged, not returned, to avoid leaking internals) ## Notes - Only datasets the caller has read permission on are included operationId: visualize_brains_summary_api_v1_visualize_brains_summary_get responses: '200': description: Successful Response content: application/json: schema: {} security: - BearerAuth: [] - ApiKeyAuth: [] components: securitySchemes: BearerAuth: type: http scheme: bearer bearerFormat: JWT ApiKeyAuth: type: apiKey in: header name: X-Api-Key ````