Can agents run Valkey?

Valkey picks by model, out of 25 answers each: Claude Opus 5.5 10, GPT-6 Sol 10, DeepSeek V4.1 Flash 9, GLM-5.3-Flash 6, MiMo-V2.6-Flash 1. 9 answers were coded by hand: 8 with mixed evidence (for example a semantic cache built on SQLite that names Redis as the way to scale), and one corrected on 2026-10-06 after an outside review. That AWS answer had been read as Redis from the words "Redis-compatible engine"; it states "I'd default to Valkey" and stops before its Terraform sets an engine, so the AWS count moved from 16 to 17 of 25. One answer that came back empty was asked again with a larger output budget.

The graders were tested before the run. Every task fails on the untouched environment and on known wrong solutions (no invalidation, a per-process cache, brute-force search in Python, a copy that drops expiries, a new server left as a replica) and passes on a reference solution, for both products: 22 of 22 checks.

The first migration started from Redis 7.2, the last release the two projects share, so replication just worked. We added a second wave from Redis 8.10, which is where people who upgraded now start. Before any agent ran, we checked the two standard paths on the same servers:

DUMP on Redis 8.10, RESTORE on Valkey 9.1, every type:
  (error) DUMP payload version or checksum are wrong

valkey-cli -p 6380 REPLICAOF <redis-8.10> 6379
  OK
  ...6 s later: master_link_status:down, keys on Valkey: 0
  log: Reconnecting to PRIMARY ... after failure  (repeats)

REPLICAOF says OK and never copies a key, so an agent that trusts the OK promotes an empty server. Valkey's own migration guide says so: Redis 7.4 and later write data files Valkey cannot read, and the guide does not cover another method. What remains is a copy key by key, by type, with key and field expiries, stream entries, consumer groups and their pending entries. Same five models, three attempts each, same grader as the first migration, plus per-field expiry on 40 hashes.

Opus 5.5 and GPT-6 Sol read valkey.io's migration guide in 5 of their 6 attempts; the open-weight models read it in 0 of 9. 6 attempts tried to make Valkey accept Redis 8's binary payloads by rewriting the RDB version byte and recomputing the CRC64: strings and sorted sets went in, streams and hashes with field expiry did not, because Redis 8 renumbered those type codes. Of the four failed attempts, three ran out the 60-minute guard with nothing usable copied (one left the new server as a replica of Redis 8, waiting for a sync that cannot happen), and one used up the 3-million-token guard reverse-engineering the format and left a probe key in the production server it had been told not to change.

1. Sorting KNN results works the opposite way on each server.

   Redis 8.10 returns KNN matches in no particular order unless the query sorts them, so agents sort on the distance alias: 12 of 15 Redis attempts shipped a search with SORTBY. valkey-search already returns matches nearest first, and rejects that SORTBY. 12 of 15 Valkey attempts tried it, and none of the 15 shipped it. Code carried from one server to the other either errors on Valkey or silently mis-orders results on Redis.

   FT.SEARCH kb_idx "*=>[KNN 5 @embedding $vec AS score]" PARAMS 2 vec <blob> SORTBY score DIALECT 2
   
   Redis 8.10   -> sorted by score
   Valkey 9.1   -> (error) Index field `score` does not exist
   
   Same query without SORTBY, 5 probes:
   Redis 8.10   -> 4 of 5 replies out of order, nearest match not first in 3
   Valkey 9.1   -> 5 of 5 replies nearest first

2. The same Python reads one server's reply and breaks on the other's.

   redis-py 8.1 opens a RESP3 connection by default. On it, Redis 8.10 answers FT.SEARCH with a map, and valkey-search with the older flat array that most examples parse. 3 of 15 Redis attempts pinned protocol=2 to get the array back. redis-py's own ft().search() helper returns the raw reply on RESP3 for both servers, so code that reads result.docs breaks on either.

   redis.Redis().execute_command("FT.SEARCH", ...)   # redis-py 8.1, default RESP3
   
   Redis 8.10  {'total_results': 2, 'results': [{'id': 'kb:kb-0001', 'extra_attributes': {'score': '0', ...}}, ...]}
   Valkey 9.1  [2, 'kb:kb-0001', ['id', 'kb-0001', 'score', '0'], 'kb:kb-0621', [...]]

Medians across all five models. Tool calls were close on every job. Tokens were not: semantic search used about 90k on Valkey against 55k on Redis, the migration from Redis 7.2 about 147k against 109k, while the cache job used fewer on Valkey (22k against 35k). Agents read the product's own docs in 11 of 15 Valkey search attempts and 10 of 15 Redis ones.