What's new in v0.12

Dakera v0.12.0, released on 2026-10-01, adds multilingual search, multimodal memory, multi-vector records and late interaction; makes recall faster and leaner; hardens security and cluster replication; and goes back to v0.11.108 with one command. This page summarizes the release for developers and operators deciding what to use and how to upgrade.

Every new feature is opt-in. An unchanged v0.11.108 deployment upgrades in place: stop v0.11.108, start v0.12 on the same data and environment (a cluster also needs DAKERA_CLUSTER_SECRET from v0.12.1). The operator guide is Upgrading to v0.12, and every change is listed in the Changelog.

Current versions

v0.12 ships as release trains: every component below is released together with the engine. The changelog lists what changed in each component, release by release.

v0.12.2

v0.12.2, released on 2026-10-08, is a patch release that upgrades in place from v0.12.1, v0.12.0 and v0.11.108: back up, then replace the image or binary. See Upgrading from v0.12.1 to v0.12.2 and the Changelog.

• Updates no longer fail with 503 "changed during each of 5 attempts". Records read back from every JSON store are bit-for-bit what was written (about 10% of numbers, such as importance 0.11, came back slightly off), every store keeps ttl_seconds, and conditional writes compare a node-local write revision instead of the whole record.
• Scoped keys fit how teams work. Prefix patterns in key grants (team-*, _dakera_agent_mlx-*), editing a key in place (PATCH /admin/keys/{key_id}, or PATCH /v1/namespaces/{ns}/keys/{key_id} for namespace admins), a rotation grace period of up to 7 days so live clients keep working, and GET /v1/auth/whoami. See Key grants.
• Agents are a server concept. POST /v1/agents creates an agent before its first memory; namespaces report their kind (agent, data, system).
• Sessions close themselves. An idle session is ended after DAKERA_SESSION_IDLE_TIMEOUT_SECS (default 4 h) exactly as a client end would, with ended_reason: "idle". POST /v1/sessions/{id}/touch keeps a quiet session open, and a session can set its own timeout (0 = never).
• Graph View and memory lists stay light. The knowledge graph and the memory listings serve an opt-in content preview (content_preview_chars), and the server reads only the graph nodes it serves.
• Derived data is durable. Sentence sub-memories, graph edges and full-text entries are no longer left stale or dropped under load, a background reconciler repairs what a crash left owed, and sub-memories no longer show up in agent listings or wake-up.
• Node-wide endpoints answer within 2 s even when one namespace cannot be read, and say which one.

Changes that need attention:

1. Sessions end after 4 hours of inactivity by default. Set DAKERA_SESSION_IDLE_TIMEOUT_SECS=0, or start sessions with idle_timeout_secs: 0, to keep the old behavior. Long-open orphan sessions are closed, with their summaries, on the first passes after the upgrade.
2. Stricter validation. Memory metadata, the content limit (now in bytes, DAKERA_MAX_MEMORY_CONTENT_BYTES, and enforced on update too), reserved markers and ids, key namespace lists and imports are validated on every write path; the raw vector routes no longer write memory records into agent namespaces.
3. Authorization tightened. Sessions are authorized by their agent (no _dakera_sessions grant needed), ending a session checks Write scope first, open event streams re-check scope, and agent ids are at most 241 bytes. A foo* entry on a key created before v0.12.2 stays a literal name until the key is saved again.
4. Listings leave derived records out: include_derived=true restores them on GET /v1/agents/{id}/memories and /wake-up.

Released with it: Python SDK 0.14.0, TypeScript SDK 0.12.2, Go SDK v0.12.2, Rust SDK 0.12.2, CLI 0.8.1 and MCP server 0.12.2 add the new routes (agent creation, key edits, rotation grace, whoami, session touch, content previews) and keep working against v0.12.0 and v0.12.1 (release 0.12.2 →).

Dashboard 0.5.1 ships with v0.12.2: Add agent, key edits with prefix patterns, rotation grace, session auto-end labels and lighter memory lists.

v0.12.1

v0.12.1, released on 2026-10-05, is a patch release on v0.12.0. Stop v0.12.0 and start v0.12.1 on the same data and environment; the formats are unchanged. See Upgrading from v0.12.0 to v0.12.1 and the Changelog.

• Cluster nodes require DAKERA_CLUSTER_SECRET (breaking for clusters). On v0.12.0 an upgraded cluster node without a secret started with its node-to-node routes unauthenticated, and POST /internal/sync/key/add let anyone who reached the API port mint a SuperAdmin key. A cluster node without the secret now refuses to start. Set the same secret (at least 16 characters) on every node and upgrade them in one window; dakera --check-config reports a missing or short secret. Single-node deployments are not affected. See Cluster secret.
• Full-text indexes upgraded from v0.11 answer keyword queries again, with no operator step. An index v0.11 built without stemming stayed as built on v0.12.0, so release did not find released until you rebuilt it by hand. Every full-text index built with another analyzer than the configured one is now re-analysed in the background at startup, one namespace at a time, while it keeps serving; a restart resumes, and each cluster node does its own. A changed DAKERA_FULLTEXT_LANGUAGE reaches existing indexes the same way.
• Changing DAKERA_MODEL re-embeds the store by itself. No flag and no admin call: the server starts and re-embeds every agent namespace in the background, one at a time, and answers each namespace with the model its memories are in until its turn, so recall stays correct throughout. Progress is in /health embedding_model_change. Under DAKERA_TIERED=1, late-interaction scoring or the visual lane, startup is refused as before and the manual path stays.
• One definition for every statistics total. A memory is a top-level memory an agent stored, a sub-memory is a sentence record derived from one, and a vector is any stored record. Expect memory counts to drop and session counts to rise on upgrade (ended sessions are now counted); field names and types are unchanged, and new fields such as vector_count on GET /v1/agents keep the old figure. See Statistics totals.
• Faster statistics and listings. Statistics endpoints answer from maintained counts instead of reading every record; on a production store of 25k records they took 16.6 s (/admin/reembed/static-count), 11.2 s (/admin/memory-type-stats), 6.2 s (/admin/ttl/stats) and 2.1 s (/v1/agents/{id}/stats). Session and agent listings no longer read every session record (2.6 s, 2.4 s and 1.9 s with 5k sessions before).
• GET /v1/agents lists every agent, including agents with memories but no session (41 of 84 agents were missing on a production store).
• KPI and analytics figures count memory operations: batch recall, batch store and memory search are counted, the analytics latency covers queries only, GET /v1/kpis gains a latency object, and cache figures include the in-process cache.
• Code audit fixes in security (for example a crash reading some session summaries, POST /v1/memories/extract accepting any key, event streams outliving their key's revocation), data (a dimension-changing re-embed deleting attachments, filters mixing a field with $or / $and dropping the field condition, write-ahead-log checkpoint ordering) and search (wrong Euclidean results from /multi-vector, NaN BM25 scores from out-of-range settings). Session summaries written before v0.12 now read as text.

The rest of this page describes v0.12.0.

v0.12.0 highlights

Multilingual search

Four independent, opt-in layers. A server that sets none of them behaves as v0.11.108 did (English).

• Embeddings: DAKERA_MODEL=bge-m3 puts text from 100+ languages in one 1024-dimensional space (XLM-RoBERTa, CPU ONNX backend only).
• Full-text: DAKERA_FULLTEXT_LANGUAGE selects per-language stemming and stop words; DAKERA_FULLTEXT_CJK_BIGRAMS indexes Chinese, Japanese, Korean, Thai and similar scripts as character bigrams (v0.11.108 did not index such text at all). From v0.12.1 an existing index is re-analysed under a changed setting at the next start; on v0.12.0, POST /admin/fulltext/reindex switches an existing namespace.
• Dates and query routing in seven languages (DAKERA_QUERY_LANG: en, de, fr, es, it, pt, nl, or auto).
• Per-request lang on recall, search, store, batch store, update and extraction.

Details: Multilingual search.

Multimodal memory

Off by default; each feature turns on with one variable.

• Attachments (DAKERA_ATTACHMENTS): files stored per namespace, content-addressed, referenced from memories, counted by quotas, backed up and replicated.
• Speech to text (DAKERA_WHISPER_MODEL): a WAV attachment becomes a memory through a background job. Five models: whisper-base (the default, multilingual, recommended), whisper-tiny.en (lightest English), whisper-base.en (better English), whisper-tiny (lightest multilingual) and whisper-small (quality). The multilingual models detect the spoken language and record it as the memory's lang. See the model table.
• Image indexing and visual recall (DAKERA_VISION, colmodernvbert): recall over document pages by the text of a question. ViDoRe nDCG@5: TabFQuAD 0.643, Shift Project 0.7705 on CPU.

Every media job reserves the memory it needs before it starts, and waits or answers 503 with Retry-After instead of risking an out-of-memory kill. With every model loaded, the process heap measured 530 MiB (memory-mapped model files are not counted). Details: Multimodal memory.

Multi-vector records

DAKERA_RECORDS turns on POST /v1/namespaces/{ns}/records and GET /v1/namespaces/{ns}/records/{id}. A record is one indexed vector plus named extra representations (dense, token_multivector, patch_multivector, stored as f32, f16 or i8), kept atomically beside it by every storage backend, snapshots, export/import and replication. Use records when you compute multi-vector embeddings yourself and want Dakera to keep them with the document. Details: Records and multi-vector.

Late interaction and search controls

• Late interaction: DAKERA_MODEL=colbert-small with DAKERA_SCORING_STRATEGY=late-interaction shortlists by a fixed-dimensional encoding (MUVERA) and reranks with per-token MaxSim. Steady recall p50 is 0.10 s at 1k memories and 0.23 s at 10k. Switch it on where token-level precision matters.
• RaBitQ search mode (DAKERA_SEARCH_MODE=rabitq, DAKERA_RABITQ_BITS 1 to 8) for lower search latency.
• Rerank controls: rerank_candidates per request and DAKERA_RERANK_MAX_CANDIDATES server-wide cap how many candidates the cross-encoder scores. Recall and search answer a rerank_report (applied, candidates, skipped).
• GET /v1/capabilities tells clients what the server supports before they depend on it: models, index kinds, on-disk format version, query languages, the scoring strategy, the multimodal and record switches, and reembed_pending.

Details: Search and ranking.

Performance

Every figure is a measurement; "Before" is the same measurement without the change (v0.11.108's behavior unless noted). More in Performance.

Also: every CPU model runs on one memory-mapped copy with no idle arena; stored vectors no longer depend on what else was in the batch; ANN indexes are saved and reloaded instead of rebuilt; an expired memory no longer forces an index rebuild; concurrent writes into one namespace share the write-ahead log's fsync.

Security hardening

• gRPC requires an API key and is rate limited, time-bounded and audited like REST.
• Encrypted data is bound to its record and keys live in a replicated keyring: rotate one namespace at a time, and old backups still restore. Existing values are re-sealed in the background.
• Namespace-bound decryption: memory content is opened only under the namespace it was read from, and clients cannot store sealed values.
• Tighter permissions: keys pinned to namespaces no longer reach node-wide admin routes; backup download, upload and restore need global super_admin.
• Cluster traffic is authenticated with DAKERA_CLUSTER_SECRET, required on every cluster node from v0.12.1.
• Safer defaults: with authentication off, only local web pages may call the server; knowledge graph edges are private to their agent; imports, extractor responses and graph searches are bounded; secrets are kept out of logs and /health.
• Backups can be encrypted (AES-256-GCM) and compressed (zstd).

Details: Security and Upgrading: security and access.

One-command rollback

dakera downgrade ships in the v0.12.0 binary. Run it once on the stopped deployment, with the server's environment and volumes, and it converts the data back to what v0.11.108 reads: encrypted values, full-text indexes, the write-ahead log, tiered writes, caches and re-embedded models included. No v0.11 patch release is needed.

stop v0.12.0  ->  dakera downgrade  ->  start v0.11.108

• It prints a JSON report and exits 0 (done), 1 (something still needs fixing; run it again) or 78 (refused, nothing changed).
• It refuses while a server still runs on the data, and for deployments on bge-m3, colbert-small or the visual lane until they are moved to a v0.11 model.

Details: Rolling back to v0.11.

Reliability and operations

• Cluster replication is versioned and merges instead of overwriting, with a durable outbox and tombstones. See High availability.
• Tiered storage keeps a durable local hot tier and keeps serving through object-store outages.
• Startup: the server binds its port while models download, with /health/live and /health/ready; /health adds degraded, config_warnings and embed_migration.
• dakera --check-config runs the startup configuration check alone and exits 0 (would start) or 78 (would refuse).
• dakera models list | pull | prune shows, pre-fetches, bakes into an image or cleans models. The images ship their default models, so a default start needs no network. See Models and Docker.
• Observability: Prometheus alert rules and a rebuilt Grafana dashboard, published in dakera-deploy monitoring/ with the dakera-deploy v0.12.0 release. See Operations.
• Data lifecycle: backups, TTL, forget, deduplication and consolidation are hardened end to end.

Telemetry disclosure

When telemetry is on, v0.12.0 sends lifecycle events and a 6-hourly heartbeat. The machine's hostname is sent, and PostHog keeps the connecting IP address and derives a coarse location from it (GeoIP). Opt out with DAKERA_TELEMETRY=0 or DO_NOT_TRACK=1. See Telemetry.

What changes for existing deployments

Read these before upgrading. Each is explained, with what to do, in Upgrading to v0.12.

1. gRPC clients need an API key in the call metadata (x-api-key or authorization: Bearer) when authentication is on.
2. Permissions: keys pinned to namespaces get 403 on node-wide routes; backup download, upload and restore need global super_admin.
3. Namespace quotas are enforced. Quotas set on v0.11 were never checked; writes over a hard quota now get 413.
4. Ranking follows the query more closely. A recall no longer raises the importance of what it returns, the access count is no longer a score term, and recency counts from when a memory was created. smart_score values change scale.
5. A stored, enabled backup schedule starts running at its next slot (v0.11 stored it and never ran it).
6. Health checks: the port answers while models load; point readiness at /health/ready and liveness at /health/live.
7. Configuration: an upgraded deployment starts with warnings, never refusals (/health config_warnings); a fresh install with the same mistakes is refused. Run dakera --check-config first.
8. Stored memories are re-embedded once in the background (they were embedded with the query instruction): about 35 minutes per 10,000 memories on bge-large; recall is served throughout.
9. Clusters: from v0.12.1 every cluster node needs DAKERA_CLUSTER_SECRET. Set the same secret on every node and upgrade them in one window (Cluster secret), and give each node its own S3 bucket.
10. Statistics totals (v0.12.1): memory counts drop (sentence sub-memories are no longer counted as memories) and session counts rise (ended sessions are counted). Warn the owners of dashboards and reports.
11. Sessions auto-end (v0.12.2): a session idle for DAKERA_SESSION_IDLE_TIMEOUT_SECS (default 4 h) is ended by the server; set it to 0 to keep sessions open until a client ends them.
12. Validation (v0.12.2): metadata, content in bytes, reserved markers and ids, key namespace lists and imports are checked on every write path (400); sessions are authorized by their agent.
13. Speech to text defaults to whisper-base (multilingual, language auto-detected), not English-only whisper-tiny.en. Speech is opt-in; a deployment that turns it on without DAKERA_WHISPER_MODEL transcribes with whisper-base. Set DAKERA_WHISPER_MODEL=whisper-tiny.en to keep the lightest English model.
14. Errors: every error body is JSON, every 503 carries Retry-After, configuration errors are 501, over-size bodies are 413.
15. Namespace config: PATCH merges and refuses unknown fields; PUT replaces.
16. Telemetry, when on: lifecycle events and a 6-hourly heartbeat; the hostname is sent and the connecting IP is kept (see above).
17. POST /ops/shutdown really shuts the server down (in v0.11 it only set a flag).

Operating notes

• Persistent storage: keep the data directory on a persistent volume, also when vectors are stored on S3.
• Visual store: use a dedicated data directory for a deployment that indexes document pages.
• Score thresholds: smart_score has a new scale (w_vec * relevance + w_imp * importance + w_rec * recency); re-check any absolute cut on it.
• Clients on v0.11 SDKs: use GET /health/ready to wait for a starting server, and PUT /v1/namespaces/{ns}/config to clear a namespace's entity_types.
• Full-text indexes after upgrading from v0.11.108: v0.12.1 re-analyses them in the background at startup, with no step. On v0.12.0, rebuild them once with POST /admin/fulltext/reindex; see Full-text indexes after the upgrade.
• Restores: run them in a maintenance window; the server keeps serving while a restore runs.

Where to go next

• Upgrading to v0.12: the operator guide, from v0.11.108, v0.12.0 or v0.12.1.
• Rolling back to v0.11: dakera downgrade.
• Changelog: every change in v0.12.2, v0.12.1 and v0.12.0.
• Features: Multilingual search, Multimodal memory, Records and multi-vector, Search and ranking.
• Operations: Operations, Models and Docker, Performance, Telemetry.
• Reference: Configuration, Deployment, Security, High availability, REST API.