cachly AI Brain
Persistent AI memory for Claude Code, Cursor, Copilot, Windsurf, Cline & Zed.
Community: Submitted by a user or imported; check the owner before granting accessOnlineNo sign-inGlobalFreeCan modify data
What it can do
- List Instances: List all your cachly cache instances with their status and connection details. Read-only. Returns an array of instance objects — each with id, name, tier, status, region, RAM, and redi
- Create Instance: Create a new managed Valkey/Redis cache instance on cachly.dev. Free tier provisions in ~30 seconds. Paid tiers return a Stripe checkout URL. Available tiers: free (25 MB), dev (200 M
- Get Instance: Get full metadata for a specific cache instance: name, tier, status (provisioning / running / paused), region, RAM limit, Redis connection string, created_at, and expiry. Read-only. Retu
What data it sees
Do you need an account
No: the server works without sign-in
Persistent AI memory for Claude Code, Cursor, Copilot, Windsurf, Cline & Zed.
Your AI remembers every lesson, fix, and architecture decision — across sessions, IDEs, and model upgrades. Quality-aware recall beats raw BM25 keyword search by +33% Precision@1 on our published benchmark.
Features causal root-cause analysis (causal_trace), failure prediction (brain_predict), git-ambient learning (brain_from_git), shared Team Brain, and Memory Crystals. BM25+ search in 11 languages. 122 tools. Free tier. GDPR, EU-hosted on German servers.
Zero-config: sign in once at cachly.dev/setup-ai — your Brain instance is provisioned automatically. No credit card required.
Server tool list (60)
Raw names from tools/list. Only developers need these.
| list_instances | List all your cachly cache instances with their status and connection details. Read-only. Returns an array of instance objects — each with id, name, tier, status, region, RAM, and redis:// connection string. Returns an empty array if no instances exist. No pagination: all instances are returned in one call (typical accounts have < 20). Use this first to discover instance UUIDs required by get_instance, cache_get, cache_set, and all other cache tools. Use get_instance to retrieve full metadata for a single instance. |
| create_instance | Create a new managed Valkey/Redis cache instance on cachly.dev. Free tier provisions in ~30 seconds. Paid tiers return a Stripe checkout URL. Available tiers: free (25 MB), dev (200 MB, €19/mo), pro (900 MB, €49/mo), speed (900 MB Dragonfly + Semantic Cache, €79/mo), business (7 GB, €199/mo). |
| get_instance | Get full metadata for a specific cache instance: name, tier, status (provisioning / running / paused), region, RAM limit, Redis connection string, created_at, and expiry. Read-only. Returns an error if the instance_id is not found or belongs to another account. Call list_instances first to discover valid UUIDs. Use get_connection_string instead if you only need the redis:// URL for your app config. |
| get_connection_string | Get the Redis/Valkey connection string (redis:// URL) for a running instance. Use this to configure your application or set environment variables. |
| delete_instance | Permanently delete a cache instance. Deprovisions the Kubernetes workload and removes all data. This action is irreversible. |
| cache_get | Get a value from a running cache instance by key. Returns the stored value (string or deserialized JSON object) or null if the key does not exist or has expired. Read-only — no side effects. Use cache_mget when you need multiple keys in one round-trip. Use cache_exists to check existence without retrieving the value. Use semantic_search when you need fuzzy/vector search across stored values. |
| cache_set | Set a key-value pair in a running cache instance. Overwrites any existing value at the key — not idempotent for new data. Returns "OK" on success; returns an error if the instance_id is invalid or the instance is paused. Value can be a string or a JSON-serialized object. Optionally set a TTL in seconds (omit for no expiry). Use cache_mset instead for setting multiple keys in a single pipeline round-trip. Use cache_stream_set instead for caching LLM token streams (ordered string chunks). |
| cache_delete | Permanently delete one or more keys from a running cache instance (uses Redis DEL). This operation is destructive and irreversible — deleted keys cannot be recovered. Deleting a non-existent key is safe and returns 0 for that key (no error). Returns the count of keys that were actually deleted (existing keys only). Use this to explicitly remove stale entries; prefer cache_set with a short TTL for auto-expiring data. Do NOT use this to clear an entire instance — use the dashboard or delete_instance for that. |
| cache_exists | Check whether one or more keys exist in a running cache instance (uses Redis EXISTS). Read-only — no side effects. Returns the count of keys that currently exist (integer 0 to N). If none of the keys exist, returns 0. If all exist, returns the total key count passed in. Duplicate keys in the input array are each counted separately (Redis behavior). Use this to check presence before a cache_get to avoid null handling, or to verify a cache warm-up completed. Use cache_get instead if you also need the value; use cache_ttl if you need expiry info. |
| cache_ttl | Get the remaining time-to-live (TTL) of a key in seconds. Returns -1 if the key exists but has no expiry, -2 if the key does not exist. Read-only — no side effects. Use cache_set with a ttl parameter to set or update the expiry. |
| cache_keys | List keys in a cache instance matching an optional glob pattern (e.g. "user:*", "session:*"). Uses SCAN to avoid blocking the server. Returns at most `count` keys. |
| cache_stats | Get real-time stats for a cache instance: memory usage, hit/miss rate, commands/sec, connected clients, keyspace info, and uptime. Read-only — no side effects. The instance_id identifies the target instance (obtain from list_instances). Use this for monitoring, capacity planning, or debugging performance issues — not for reading cached values (use cache_get for that). Use cache_exists or cache_ttl if you only need key-level information. |
| semantic_search | Find cached entries that are semantically similar to a natural-language query. Read-only — no side effects. Returns an array of objects, each with: key, value, similarity_score (0–1), and namespace. Returns an empty array if no entries meet the similarity threshold. Requires OPENAI_API_KEY (or compatible provider) and the Speed/Business tier with CACHLY_VECTOR_URL. Embeddings are computed server-side and never leave Germany (pgvector HNSW index). Example: "find all cached responses about password reset" or "what did we answer about pricing?". Use cache_get for exact key lookup; use smart_recall for brain lessons. |
| detect_namespace | Classify a prompt into one of 5 semantic namespaces using text heuristics. Overhead: <0.1 ms, no embedding required. Useful to understand which namespace cachly will use for a given prompt. Returns one of: cachly:sem:code, cachly:sem:translation, cachly:sem:summary, cachly:sem:qa, cachly:sem:creative. |
| cache_warmup | Pre-warm the semantic cache with a list of prompt/value pairs. For each entry: computes an embedding, checks if a similar entry already exists (similarity ≥ 0.98), and writes new entries to Valkey + pgvector index. Use this to seed FAQ responses, product descriptions, or known-good LLM answers before the first real user traffic. Requires OPENAI_API_KEY. |
| index_project | Index local source files into the cachly semantic cache so AI assistants can use semantic_search to find relevant files instead of re-reading the whole codebase every time. Walks a directory recursively, reads each matching file, and stores a summary + path as a semantic cache entry (prompt = file path + content excerpt, value = relative path). Requires an embedding provider (OPENAI_API_KEY or CACHLY_EMBED_PROVIDER + key). Run once, then re-run after major refactors. TTL=86400 (24h) keeps entries fresh. |
| cache_mset | Set multiple key-value pairs in a single pipeline round-trip. Supports per-key TTL – unlike native MSET. Uses one TCP round-trip for N keys via Redis pipeline. Each item overwrites any existing value for that key. On partial failure the successfully pipelined keys are committed; a per-key error list is returned for any that failed. Returns a summary: { set: N, errors: [...] }. Use cache_set for a single key; use cache_stream_set for large streaming payloads. |
| cache_mget | Retrieve multiple keys in one round-trip using native Redis MGET. Returns values in the same order as the keys array; missing keys are null. |
| cache_lock_acquire | Acquire a distributed lock using Redis SET NX PX (Redlock-lite). Returns a fencing token on success. The lock auto-expires after ttl_ms to prevent deadlocks. Use cache_lock_release to free the lock early. |
| cache_lock_release | Release a previously acquired distributed lock. Uses a Lua script for atomic release – only deletes the key if the fencing token matches. |
| get_api_status | Full diagnostic for your cachly Brain — call this FIRST whenever anything is not working. Returns: API reachability, JWT validity + expiry, your user ID, all Brain instances with live status (🟢 running / 🟡 provisioning / 🔴 stopped), Redis ping on the active connection, and actionable fix steps for every issue found. Workflow: run get_api_status → read the issue it flags → fix it → retry your tool. |
| remember_context | Save context information to the cache so you can recall it later without re-computing. Perfect for caching: codebase overviews, file summaries, project structure, frequently-accessed data, or "thinking" results like dependency analysis. The AI assistant can use this to avoid re-reading the entire codebase every time. Overwrites any existing value stored under the same key. Returns { key, stored_at, ttl } confirming the saved context. Example: remember_context("project overview", "This is a Next.js app with...") then later: recall_context("project overview"). Use recall_context to retrieve; use list_remembered to see all stored keys. |
| recall_context | Retrieve previously saved context from the cache. Returns the saved content or null if not found. Use this at the START of any task to check if you already have relevant context cached, before doing expensive operations like reading many files. Supports glob patterns: "file:*" matches all file summaries, "arch*" matches architecture-related keys. |
| list_remembered | List all cached context entries for this project. Shows what knowledge the AI assistant has already cached, so you can decide whether to recall existing context or refresh it. Returns: key, category, size, TTL remaining, and a content preview. |
| forget_context | Delete one or more cached context entries. Use when context is stale or you want to force a fresh analysis. Supports glob patterns: "file:*" deletes all file summaries. |
| learn_from_attempts | Store a lesson learned from a failed or successful attempt. Call this AFTER completing any non-trivial task (deploy, debug, fix, architecture decision). The lesson will be recalled automatically in future sessions via recall_best_solution. Fields: topic (short slug like "deploy:web"), outcome ("success"|"failure"), what_worked (what solved it), what_failed (what did NOT work), context (extra details). Supports structured metadata: severity, file_paths (files involved), commands (working commands), tags. Deduplication: if a lesson for this topic already exists, it is updated with full audit trail. Contradiction detection: warns if new outcome conflicts with existing lesson outcome. Confidence: lesson starts at 1.0, decays after 5d (→0.7) and 10d (→0.5) without recall. Example: learn_from_attempts(topic="deploy:api", outcome="success", what_worked="nohup docker compose up -d --build", what_failed="docker compose up hangs on SSH timeout", severity="critical", commands=["nohup docker compose up -d --build"]) |
| recall_best_solution | Recall the best known solution for a topic from past lessons. Call this BEFORE attempting any task that might have been done before. Returns the most recent successful lesson for the topic, with confidence indicator. ⚠️ badge = lesson is >5d old (verify before applying). 🔴 = >10d old (likely stale!). Recalling a lesson resets its confidence clock to 1.0 (marks as recently verified). Example: recall_best_solution(topic="deploy:web") → returns the working deploy command. |
| smart_recall | Semantically search cached context using natural language. Instead of exact key matching, finds context by meaning. Example: smart_recall("how does authentication work") → returns cached auth architecture summary. Falls back to remember_context keys if no semantic match is found. |
| session_start | Single-call session briefing. Call this at the START of every session INSTEAD of multiple separate smart_recall/recall_best_solution calls. Returns: last session summary, recent lessons sorted by recency, relevant lessons for your focus area, open failures (topics with only failure outcomes), brain health stats, team telepathy (what teammates learned this week), predictive pre-warnings (if your focus area has known failure patterns), and memory crystals (compressed wisdom from old sessions). Also saves a session start marker so session_end can compute duration. |
| session_start_summary | Focused session briefing for large brains. Returns only the top-N most relevant lessons for the given focus topic, scored by relevance, recall count, severity, recency, and outcome. Ideal when session_start returns too many lessons to fit in context (1000+ lesson brains). Use session_start for the full briefing including handoffs, streak, roadmap, and team telepathy. |
| session_end | Save a session summary when you finish working. Records what was accomplished, files changed, and lesson count. The next session_start will show this summary as "Last session". Call this when ending a work session, before going idle, or before summarizing. Ambient Learning: if workspace_path is provided, reads git log since session start and auto-learns from commits. |
| session_handoff | Save a detailed handoff for the NEXT chat window / session. Stores: current progress, TODO list (done + remaining), changed files with descriptions, instructions for the next assistant, and any incomplete work. The next session_start automatically includes this handoff so the new window knows EXACTLY what happened and what remains. Call this BEFORE closing a chat window, especially if work is incomplete. This prevents the "continue" problem where new windows lose context, skip tasks, or produce broken code. |
| session_ping | Lightweight checkpoint — call this every ~5 tool calls or whenever you complete a significant step. Stores the current task + files touched so session_start on the NEXT provider can reconstruct what happened even if session_end was never called (e.g. Claude context limit hit, window crashed). This solves the provider-switching problem: Claude → Copilot → Cursor all see the same last checkpoint. Extremely fast — one Redis SET, no blocking operations. |
| auto_learn_session | Auto-learn from a list of session observations WITHOUT explicit learn_from_attempts calls. Pass what happened (commands run, errors seen, solutions found) and the brain classifies and stores lessons automatically. Use at session_end to capture everything you did, even if you forgot to call learn_from_attempts. Returns a summary of what was auto-stored. |
| brain_who_knows | Find who in your team has the most expertise on a given topic. Queries the org-wide knowledge graph (built automatically from learn_from_attempts author fields) and returns a ranked list of contributors whose lessons match the query, ordered by lesson count and confidence. Use to find the right person to ask before starting a task, or to understand knowledge distribution. Example: brain_who_knows(topic="kubernetes deployment") → "🥇 alice — 5 lessons, 94% confidence". |
| brain_file_map | Show what cachly knows about a list of files — experts + related lessons per file. Call this before starting work on unfamiliar files, or in sync_file_changes to see what knowledge exists. For each file path: shows who has previously touched it (from learn_from_attempts author+file_paths) and which lessons reference it. Example: brain_file_map(file_paths=["src/auth/jwt.ts"]) → "🥇 alice (3× · today) — related: fix:jwt-expiry". |
| team_expertise_map | Full team expertise overview — who knows what, at a glance. Returns a ranked table of all contributors with their lesson count, top domains, and last-active date. Use for onboarding (who to ask about X?), retrospectives, or to find knowledge gaps. Built automatically from learn_from_attempts(author=...) calls — no setup needed. |
| brain_collab_pairs | Show the Person↔Person Collaboration Graph for your team (W5). Lists every pair of contributors who have worked together — either by touching the same files in learn_from_attempts or by recalling each other's lessons via smart_recall(requester=...). Each pair includes a "Frag @X und @Y" routing suggestion — ideal for onboarding and bus-factor analysis. Also flags solo contributors whose knowledge no teammate has yet recalled (bus-factor risk). Example: brain_collab_pairs() → "@alice ↔ @bob — 12 events · ask them together about auth/payments". |
| brain_portability | Bring your own model, keep your brain: the same memory in every AI editor. Returns your Brain ID plus ready-to-paste MCP config snippets for every compatible AI client: Claude Code, Cursor, Windsurf, GitHub Copilot (VS Code), Cline, Zed, Continue. All 7 clients connect to the same Brain — same lessons, crystals, predictions, and team data. Use autopilot to configure all detected editors in one command. Example: brain_portability() → config blocks for 7 clients + model-neutrality proof table. |
| skill_gaps | Show knowledge blind spots in your Brain — domains with unresolved failures, lessons with missing attribution, and areas where brain_who_knows cannot help. Run periodically to find where to focus knowledge capture effort. Returns a prioritized list: 🔴 critical (failures with no solutions) → 🟡 warn → 🔵 info. Pairs with brain_coverage for a full knowledge-health picture. |
| brain_coverage | Knowledge-coverage health score for your codebase — scored 0-100. Reports: total lessons, success ratio, attribution completeness, team engagement, and file coverage vs git ls-files. Run after brain_from_git or periodically to track knowledge-capture progress. Use skill_gaps to find what to fix. Example: brain_coverage() → "🟢 Overall score: 78/100 · 42 lessons · 6 contributors · 31% files covered". |
| brain_metrics | Report the three decisive Brain metrics: (1) time-to-first-recall (onboarding friction), (2) recall-lift vs. raw BM25 (the moat proof, from Cachly-Bench), and (3) team-knowledge-reuse — what % of proven recalls used a teammate's lesson. Use to track whether the Brain is delivering its core value. Pass author="handle" to smart_recall so cross-author reuse can be measured. |
| brain_changelog | Generate a human-readable Markdown changelog of lessons learned in the last N days. Groups lessons by topic category, annotates with author, recall count and confidence. Ideal for weekly standups, sprint retros, or async team updates — share the output directly in Slack or a doc. Example: brain_changelog(instance_id="...", days=7) → grouped Markdown changelog of the week's learning. |
| brain_service_map | Map everything the Brain knows about a running service or system: who operates it, which files run in it, every known failure, and every proven fix. Built from lessons tagged with `service="..."` in learn_from_attempts. Ideal for incident triage — when a service is misbehaving (e.g. a restarting pod), instantly surface who knows it and what has gone wrong with it before. Example: brain_service_map(service="prometheus") → operators, known OOM failures, and the fixes that worked. |
| sync_file_changes | Associate recent file changes with brain knowledge. Pass a list of changed file paths (from `git diff --stat`). Returns lessons relevant to those files, and records the file changes in session history. Call this after commits so the brain tracks what changed and why. |
| team_learn | Store a lesson in a shared team brain so all team members benefit. Like learn_from_attempts, but REQUIRES an author name for attribution. Shows up in team_recall with "by <author>" so the team knows who learned it. |
| team_confirm | Endorse (review-confirm) a team lesson so trusted, human-reviewed knowledge ranks above unreviewed auto-learned entries. A senior review weighs more than a peer review; distinct endorsements add a small boost. Confirmed lessons surface higher in smart_recall and team_recall and carry a 🛡️/✔️ badge. Use this in code review or knowledge reviews to bless the canonical solution for a topic. |
| team_assign_role | Assign a role (admin | reviewer | contributor | viewer) to a team member on a shared brain instance. Roles control what each person can do: admin can manage roles and delete lessons; reviewer can senior-review (🛡️ badge, stronger recall boost); contributor can store lessons and peer-review (✔️ badge); viewer is read-only. First call bootstraps governance (no auth required when no admins exist yet). After that, only an admin can assign or change roles. Example: team_assign_role(handle="alice", role="reviewer", assigned_by="bob") — bob must be an admin. |
| team_whoami | Show your own role and capabilities on a shared brain instance. Tells you what you can do (store, review, manage roles) and who to contact if you need a higher role. Run this after onboarding to confirm your role was set correctly. |
| team_roster | Show all team members and their assigned roles on a shared brain instance. Returns a table of handles, roles (👑 admin · 🛡️ reviewer · ✏️ contributor · 👁️ viewer), and capabilities. Use during onboarding to see who can do what, or to verify role assignments. |
| team_audit | View the governance audit log for a shared brain — an immutable trail of who changed roles and who confirmed which lessons, with timestamps. Essential for enterprise compliance and security reviews. Admin-only once governance is active (an admin has been assigned). Events are recorded automatically on team_assign_role and team_confirm — no setup. Example: team_audit(requester="alice") → "👑 role: bob set carol viewer → contributor · ✅ confirm: dave confirmed auth:jwt-skew (senior)". |
| team_grant_scope | Add or remove a team member to/from a named group (sub-team) on a shared brain. Group-scoped lessons (stored with group="...") only surface in smart_recall for members of that group (and admins). This is team-level visibility, orthogonal to lesson-level private. Admin-gated after the role model is bootstrapped. Example: team_grant_scope(handle="alice", group="security", assigned_by="bob") — bob must be admin. |
| team_scopes | List team groups and their members, or the groups a specific person belongs to. Pass handle to see one person's scopes; omit it to see all groups on the instance. Use to audit who can see group-scoped lessons. |
| team_recall | Recall lessons from a shared team brain, showing who learned what. Works on any shared instance (all team members using the same instance_id). Shows author, recency, and severity for each lesson. Use this to onboard new team members or find who knows about a topic. |
| team_synthesize | Team Brain Synthesis — merge multiple contributors' lessons on the same topic into one canonical version. When 2+ developers store lessons for the same topic with different details, this proposes the best merged version. Shows: all contributions by author, what worked (consensus), what failed (union), canonical lesson to store. Use this when onboarding new team members or before documenting a process. |
| memory_crystalize | Compress the last 30-50 sessions and auto-learned lessons into a dense Memory Crystal. A crystal is a compact, structured summary of everything the brain learned — grouped by category (deploy, fix, debug, …). Crystals survive session cleanup and appear in session_start once enough sessions have accumulated. Run this monthly or after a big milestone to preserve institutional knowledge. Returns a digest of what was crystallized. |
| team_crystallize | Create a Team Crystal — the team-wide, causal counterpart to memory_crystalize. Where memory_crystalize compresses ONE brain by category, team_crystallize surfaces what a per-user memory structurally cannot: which fixes solved structurally SIMILAR problems across MULTIPLE people. A pattern only crystallizes when 2+ distinct authors independently converged on it — that cross-person signal is the moat against single-user "Dreaming"-style memory. Needs attributed lessons (learn_from_attempts(author=...) / team_learn). Surfaces in crystal_view. Example: team_crystallize() → "🧩 pool — 3 people converged (alice, bob, carol): bounded pool + timeout". |
| roadmap_add | Add a new item to the persistent project roadmap stored in the Brain. Items survive across sessions and editors — the roadmap is always up to date. Use for features, bugs, refactors, or any planned work. Call roadmap_list to see all open items, roadmap_next to get the next actionable item. |
| roadmap_update | Update the status, priority, or details of a roadmap item. Use to move items through the lifecycle: planned → in-progress → done (or blocked/cancelled). Also use to add notes/findings while working on an item. |
| roadmap_list | List all roadmap items, optionally filtered by status, priority, tag, or milestone. Returns items sorted by priority then creation date. Called automatically by session_start to show open work. |