Setup Guide · All Providers

Agent Memory Setup

One install, one licence, memory in every agent you run. Pick the tab for how you work — MCP client or raw API — and follow the steps. Everything below runs on the same local VEKTOR engine: one SQLite file, zero embedding API calls, zero cloud round-trips.

Survives session resets

Preferences, decisions, and project state persist across every conversation and every restart.

Zero embedding cost

Local INT8 embedding model. No per-call API charges for storing or recalling memory.

Local by default

SQLite on your own disk. Memory never has to leave your machine to be useful.

Millisecond recall

Recall against a warm index runs in single-digit milliseconds — no network hop, no cold start.

Choose your setup

Claude Desktop & Claude Code (MCP)

VEKTOR connects to Claude over the Model Context Protocol. Claude gets native memory tools it can call on its own — vektor_store, vektor_recall, vektor_graph, vektor_delta, and more — no code required on your end.

1

Install

Download the package from the Downloads page and install it globally:

bash
npm install -g ./vektor-slipstream-1.8.0.tgz
2

Activate your licence

Your key is emailed on purchase. Activating launches the setup wizard automatically:

bash
vektor activate YOUR-LICENCE-KEY-HERE
3

Run the setup wizard

If you skipped it, or need to re-run it later:

bash
vektor setup

The wizard detects Claude Desktop on your machine and writes the MCP config for you — the same wizard also configures Cursor, Windsurf, VS Code, Continue, and Groq Desktop in one pass. Pick an AI provider (Ollama, Claude, OpenAI, Groq, Gemini, Mistral, xAI, or OpenRouter) when prompted; this is the model VEKTOR itself uses internally for background memory work, separate from whatever model Claude Desktop is running.

4

Restart Claude Desktop and check for the tools

Quit Claude completely and reopen it. Look for “vektor” in the MCP tools list at the bottom of a conversation.

Connected
If “vektor” shows up in the MCP tools list, Claude can now call the memory tools on its own whenever context is relevant.

Manual config (if the wizard didn't detect your install)

Find your config file — macOS: ~/Library/Application Support/Claude/claude_desktop_config.json, Windows: %APPDATA%\\Claude\\claude_desktop_config.json, Linux: ~/.config/Claude/claude_desktop_config.json — and add VEKTOR to mcpServers:

json
{
  "mcpServers": {
    "vektor": {
      "command": "vektor",
      "args": ["mcp"],
      "env": {
        "VEKTOR_LICENCE_KEY": "YOUR-LICENCE-KEY-HERE",
        "SLIPSTREAM_AGENT_ID": "claude-desktop"
      }
    }
  }
}

Available memory tools

vektor_store

Save something to memory with an importance score.

vektor_recall

Semantic search against everything stored.

vektor_graph

Traverse connections between related memories.

vektor_delta

See what changed on a topic recently.

vektor_status

Health check — db path, size, last write.

Try it

Ask Claude to remember something:

"Store this: I prefer TypeScript over Python, use VS Code, and want concise answers. Mark it important."

Then, in a later conversation:

"What do you remember about my tooling preferences?"
Recall isn't automatic every turn
Claude decides when a query is worth checking memory for. If it seems to have missed something obvious, prompt it directly: “check what you remember about X first.”

Cursor & Windsurf

Both are MCP clients, so the setup mirrors Claude Desktop — same package, same licence, same vektor setup wizard, different config file.

1

Install and activate

bash
npm install -g ./vektor-slipstream-1.8.0.tgz
vektor activate YOUR-LICENCE-KEY-HERE
2

Run the wizard

The same wizard that configures Claude Desktop detects Cursor and Windsurf on your machine and writes each app's MCP config for you:

bash
vektor setup

Both editors read MCP config from a project or user-level mcp.json. The wizard picks the right path for whichever IDE it finds — you don't need to know it.

3

Manual config, if needed

Add to your mcp.json (Cursor: Settings → MCP; Windsurf: Windsurf Settings → MCP Servers):

json
{
  "mcpServers": {
    "vektor": {
      "command": "vektor",
      "args": ["mcp"],
      "env": {
        "VEKTOR_LICENCE_KEY": "YOUR-LICENCE-KEY-HERE",
        "SLIPSTREAM_AGENT_ID": "cursor"
      }
    }
  }
}

Swap "cursor" for "windsurf" in SLIPSTREAM_AGENT_ID if you're configuring Windsurf — each editor gets its own agent id so you can tell which one wrote a given memory.

Shared memory across editors
Point both configs at the same dbPath and Cursor and Windsurf read and write the same memory graph — useful if you switch between them on the same codebase.

Coding-specific patterns

For IDE agents, store architectural decisions and conventions, not code itself:

"Remember: this repo uses Zod for all API validation, not manual type guards. Tests live next to source files, not in a separate /tests folder."

Next time you open the project, ask the agent to check memory before it proposes a pattern that conflicts with an established one.

OpenAI Agents SDK

If you're building with the OpenAI Agents SDK (or the raw Chat Completions API) rather than an MCP client, you use VEKTOR's programmatic createMemory() interface directly in your code.

1

Install and activate

bash
npm install -g ./vektor-slipstream-1.8.0.tgz
vektor activate YOUR-LICENCE-KEY-HERE

The SDK path doesn't require the setup wizard's MCP config — you're calling the memory engine directly from code, so skip straight to writing it.

2

Wrap your agent loop

Recall before the model call, store after it:

javascript
import OpenAI from 'openai';
import { createMemory } from 'vektor-slipstream';

const memory = await createMemory({
  agentId:    'my-openai-agent',
  licenceKey: process.env.VEKTOR_LICENCE_KEY,
});

const client = new OpenAI();

async function respond(userMessage) {
  // Recall relevant context before calling the model
  const memories = await memory.recall(userMessage, 5);
  const context = memories.map(m => m.content).join('\
');

  const response = await client.chat.completions.create({
    model: 'gpt-4.1',
    messages: [
      { role: 'system', content: `Relevant context:\
${context}` },
      { role: 'user', content: userMessage },
    ],
  });

  const reply = response.choices[0].message.content;

  // Store anything worth remembering from this exchange
  await memory.store({
    content: `User asked: ${userMessage}`,
    importance: 5,
    tags: ['conversation'],
  });

  return reply;
}
3

Agents SDK function-tool pattern

If you're using the Agents SDK's tool-calling loop, expose recall and store as tools the model can call itself, mirroring how Claude's MCP tools work:

javascript
const tools = [
  {
    type: 'function',
    function: {
      name: 'recall_memory',
      description: 'Search long-term memory for relevant context',
      parameters: { type: 'object', properties: { query: { type: 'string' } } },
    },
  },
];
// route calls to tools[i] into memory.recall() / memory.store()
One graph, any model
createMemory() is model-agnostic — the same SQLite graph works whether the calling model is GPT, Claude, or a local Ollama model. Give agents from different providers the same dbPath to share memory between them.

OpenRouter

OpenRouter agents follow the same programmatic pattern as OpenAI — VEKTOR doesn't care which backend model OpenRouter routes to, since memory sits outside the model call entirely.

1

Install and activate

bash
npm install -g ./vektor-slipstream-1.8.0.tgz
vektor activate YOUR-LICENCE-KEY-HERE
2

Point the OpenAI SDK client at OpenRouter

OpenRouter is OpenAI-compatible, so the same client works with a different base URL:

javascript
import OpenAI from 'openai';
import { createMemory } from 'vektor-slipstream';

const memory = await createMemory({
  agentId:    'my-openrouter-agent',
  licenceKey: process.env.VEKTOR_LICENCE_KEY,
});

const client = new OpenAI({
  baseURL: 'https://openrouter.ai/api/v1',
  apiKey:  process.env.OPENROUTER_API_KEY,
});

async function respond(userMessage, model = 'anthropic/claude-3.5-sonnet') {
  const memories = await memory.recall(userMessage, 5);
  const context = memories.map(m => m.content).join('\
');

  const response = await client.chat.completions.create({
    model,
    messages: [
      { role: 'system', content: `Relevant context:\
${context}` },
      { role: 'user', content: userMessage },
    ],
  });

  await memory.store({ content: `User asked: ${userMessage}`, importance: 5 });
  return response.choices[0].message.content;
}
3

Multi-model, one memory

Route different queries to different backend models through OpenRouter while every request reads from and writes to the same memory graph — a coding query might go to Claude, a fast classification query to a smaller open model, both sharing context:

javascript
await respond('Refactor this function', 'anthropic/claude-3.5-sonnet');
await respond('Classify this ticket', 'meta-llama/llama-3.1-8b-instruct');
// both calls recall from and store to the same memory.db
Why this matters for OpenRouter specifically
OpenRouter's whole pitch is swapping models freely. Without an external memory layer, swapping models means losing context every time you route to a different backend. VEKTOR keeps the memory graph outside any single model, so it survives the swap.

Troubleshooting

MCP tools not showing up (Claude, Cursor, Windsurf)
  • Re-run vektor setup and confirm it detected the right app
  • Check vektor status — confirms the licence is valid and the MCP server is reachable
  • Fully quit and reopen the app — closing the window isn't enough
  • Check logs: macOS Claude logs live at ~/Library/Logs/Claude/
Memory not persisting (any setup)
  • Run vektor status to confirm the db path and size
  • Check SLIPSTREAM_AGENT_ID matches across every config that should share memory
  • Confirm disk space and file permissions on the machine running the engine
"Command not found: vektor"
  • Confirm the global npm bin directory is on your PATH: npm config get prefix
  • Re-run the install: npm install -g ./vektor-slipstream-1.8.0.tgz --force

Best practices

Rate importance honestly

9–10 for constraints and core preferences that should almost never be forgotten, 6–8 for recent decisions, 1–5 for anything that's likely to change soon.

Tag for precision recall

Tags narrow what a recall query matches against — use a handful of consistent tags rather than one-off labels per memory.

Update instead of duplicating

VEKTOR deduplicates automatically, but an explicit update when a preference changes is clearer than letting two versions coexist.

Don't store secrets

Memory lives in local SQLite, not a secrets manager. Keep API keys, passwords, and other credentials out of it entirely.

What's next

API Reference

Every method on createMemory(), full parameter and return types.
Multi-Agent Systems

Share one memory graph across several agents with conflict resolution.
Quickstart

The general install-to-first-memory walkthrough this page builds on.
Full FAQ

Pricing, licensing, and general product questions.