feat: Add DakeraContextProvider — persistent cross-session coding memory via @dakera mention

Summary

This PR proposes adding a DakeraContextProvider that lets developers surface relevant memories from Dakera — a self-hosted, decay-weighted vector memory server — directly inside their Continue sessions via @dakera <query>.

Motivation

Continue already supports ephemeral file and code context. What's missing is persistent context across sessions: prior debugging approaches, architectural decisions made last week, notes from a design review. Dakera fills this exact gap with a REST API specifically designed for AI agent memory.

Interface fit

Continue's BaseContextProvider (defined in core/context/index.ts) requires:

abstract class BaseContextProvider {
  static description: ContextProviderDescription;
  abstract getContextItems(query: string, extras: ContextProviderExtras): Promise<ContextItem[]>;
}

The proposed implementation is a natural fit:

// core/context/providers/DakeraContextProvider.ts
class DakeraContextProvider extends BaseContextProvider {
  static description: ContextProviderDescription = {
    title: "dakera",
    displayTitle: "Dakera Memory",
    description: "Recall relevant memories from your persistent Dakera memory store",
    type: "query",
  };

  async getContextItems(query: string, extras: ContextProviderExtras): Promise<ContextItem[]> {
    const { url = "http://localhost:3000", apiKey = "", topK = 8 } = this.options;
    // CRITICAL: uses extras.fetch (not native fetch) for IDE proxy compatibility
    const response = await extras.fetch(`${url}/v1/memories/search`, {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        "Authorization": `Bearer ${apiKey}`,
      },
      body: JSON.stringify({ query: query || extras.fullInput, top_k: topK }),
    });
    const data = await response.json();
    return (data.results || []).map((r: any) => ({
      name: `Memory (relevance: ${r.score?.toFixed(2) ?? '?'})`,
      description: r.content?.slice(0, 80) + (r.content?.length > 80 ? '...' : ''),
      content: r.content,
    }));
  }
}
export default DakeraContextProvider;

Registration in core/context/providers/index.ts (following the pattern of every other provider in the Providers array):

import DakeraContextProvider from "./DakeraContextProvider";
// ...
export const Providers: (typeof BaseContextProvider)[] = [
  // existing providers...
  DakeraContextProvider,
];

User config (config.json)

{
  "contextProviders": [
    {
      "name": "dakera",
      "params": {
        "url": "http://localhost:3000",
        "apiKey": "dk_your_key",
        "topK": 8
      }
    }
  ]
}

Usage: type @dakera why did we choose Axum over Actix to recall relevant memories from previous sessions.

Dakera API

Dakera is self-hosted (Docker: docker run -p 3000:3000 dakera/dakera:latest). The relevant endpoint is:

POST /v1/memories/search — body: { query, top_k }, returns { results: [{ content, score, metadata }] }

The Python SDK (pip install dakera), npm package (@dakera-ai/dakera), and MCP server (@dakera-ai/dakera-mcp) are all published. The REST API requires no SDK — just an HTTP call.

Implementation notes

• extras.fetch is correctly used (not native fetch) — handles CORS/proxy routing for remote IDE contexts as documented in the existing HttpContextProvider.ts
• No external runtime dependencies — Dakera server is self-hosted
• type: "query" makes it a typed provider (user enters the recall query directly after @dakera)
• Graceful degradation: empty results or network errors return [] instead of throwing

Contribution

Happy to submit a PR with this implementation including tests. Wanted to open the issue first per CONTRIBUTING.md guidelines. The integration code for the published dakera package is open-source for reference.

/cc @sestinj @dosubot

Start with core/context/index.ts and the existing HttpContextProvider.ts to understand BaseContextProvider, extras.fetch, and error handling. Then inspect core/context/providers/index.ts for registration. Done means the Dakera provider accepts the documented options, returns mapped memory results, degrades gracefully on empty or failed requests, and is available through the @dakera context-provider configuration.