Fetch Multiple Memories in One Call: Batch Retrieval is Here

You search for memories. The results look good. Now you need the full content of all five. You loop through the IDs, making five individual API calls. Your script takes 2 seconds instead of 200ms. This shouldn't be hard.

It isn't anymore.

The Multi-Fetch Problem

Memory workflows often follow this pattern:

1. Search for relevant memories
2. Get the IDs you need
3. Fetch full details for each one

Step 3 has always been the bottleneck. Each memory required a separate GET request. Five memories? Five round trips to the API. Twenty memories? Twenty round trips.

The latency adds up:

• 5 memories x 50ms latency = 250ms (just in network overhead)
• 20 memories x 50ms latency = 1000ms (one full second waiting)
• Plus the actual processing time for each request

For scripts, automation, and AI workflows that need to fetch multiple memories, this was slow and wasteful.

Introducing Batch Retrieval

MemNexus CLI v1.7.29 introduces batch memory retrieval: fetch multiple memories in a single API call.

Multiple IDs as Arguments

mx memories get mem_abc123 mem_def456 mem_ghi789

Pass multiple memory IDs as arguments. The CLI fetches them all in one batch request and displays the results.

Piping from Search

The real power comes from piping search results directly into batch get:

mx memories search --query "API migration" --id-only | mx memories get --stdin

One command. One API call. All the memories you need.

How It Works

The --stdin Flag

mx memories get --stdin

This tells the CLI to read memory IDs from standard input. IDs can be separated by newlines or spaces—the CLI handles both.

The --id-only Flag

mx memories search --query "payment bug" --id-only

Search now has an --id-only flag that outputs just the memory IDs, one per line. Perfect for piping to batch get.

Pipeline Pattern

# Search + batch get (one API call for retrieval)
mx memories search --query "architecture decisions" --id-only | mx memories get --stdin

# Filter + batch get
mx memories search --query "deployment" --topics "completed" --id-only | mx memories get --stdin

# Recent work + batch get
mx memories search --query "last week" --recent 7d --id-only | mx memories get --stdin

Under the Hood

Batch retrieval uses a dedicated API endpoint for fetching multiple memories at once.

One request, multiple memories:

{
  "ids": ["mem_abc123", "mem_def456", "mem_ghi789"]
}

Response includes metadata:

{
  "data": [ /* array of memory objects */ ],
  "meta": {
    "requested": 3,
    "found": 3,
    "missing": []
  }
}

If some IDs don't exist, the API returns what it found and lists the missing IDs. No error—just transparent reporting.

Limits:

• Maximum 100 IDs per batch request
• SDK: v1.17.0+
• CLI: v1.7.29+

Short ID Support Works Too

Remember short ID prefixes? They work in batch mode:

mx memories get abc123 def456 ghi789

The CLI resolves short IDs (minimum 6 characters) to full UUIDs before making the batch request. If a prefix is ambiguous or not found, the CLI warns you and skips it.

Real-World Examples

Export Related Memories

# Find all memories about a feature, export them
mx memories search --query "user authentication" --id-only | \
  mx memories get --stdin --format json > auth-memories.json

Context for AI Assistant

# Get recent debugging session, format for LLM
mx memories search --query "bug investigation" --recent 24h --id-only | \
  mx memories get --stdin --format yaml

Audit Trail

# Fetch all memories from a specific conversation
mx conversations get conv_abc123 --id-only | \
  mx memories get --stdin

Team Handoff

# Package up project context
mx memories search --query "project phoenix" --topics "decision,implementation" --id-only | \
  mx memories get --stdin --format json > phoenix-handoff.json

The Performance Difference

Before (serial requests):

# 5 individual requests
for id in mem_a mem_b mem_c mem_d mem_e; do
  mx memories get $id
done

# ~250ms of latency alone (5 x 50ms)
# Plus request processing time
# Total: ~500ms+

After (batch request):

# 1 batch request
mx memories get mem_a mem_b mem_c mem_d mem_e

# ~50ms latency
# One processing operation
# Total: ~100ms

5x faster for five memories. The speedup scales linearly with the number of memories.

Error Handling

Batch requests fail gracefully. If some IDs don't exist:

$ mx memories get mem_valid1 mem_invalid mem_valid2
Found 2 of 3 memories
Missing IDs: mem_invalid

# Displays the 2 valid memories
# Reports the 1 missing ID
# Exit code: 0 (success for partial results)

You get what's available. No all-or-nothing failure.

Combining with Filters

Search filters work seamlessly with batch retrieval:

# Completed work from this week
mx memories search --query "sprint tasks" \
  --recent 7d \
  --topics "completed" \
  --exclude-topics "meeting-notes" \
  --id-only | \
  mx memories get --stdin

Build precise searches, then fetch everything in one call.

Output Formats

Batch get supports all standard formats:

# Human-readable table (default)
mx memories get id1 id2 id3

# JSON for scripting
mx memories get id1 id2 id3 --format json

# YAML for configuration
mx memories get id1 id2 id3 --format yaml

Workflow Integration

CI/CD Context Loading

#!/bin/bash
# Load deployment context from memories

DEPLOY_IDS=$(mx memories search \
  --query "production deployment" \
  --topics "runbook,configuration" \
  --id-only)

CONTEXT=$(mx memories get --stdin --format json <<< "$DEPLOY_IDS")

echo "$CONTEXT" | jq -r '.[].content' > deployment-notes.txt

Daily Standup Prep

#!/bin/bash
# Gather yesterday's work

mx memories search \
  --query "development tasks" \
  --recent 24h \
  --exclude-topics "auto-saved" \
  --id-only | \
  mx memories get --stdin --format yaml > standup-notes.yaml

Documentation Generation

#!/bin/bash
# Export architecture decisions

mx memories search \
  --query "architecture decision record" \
  --topics "decision,architecture" \
  --id-only | \
  mx memories get --stdin --format json | \
  jq -r '.[] | "## \(.createdAt)\n\n\(.content)\n\n---"' > ADRs.md

Migration Guide

Before

# Script to fetch multiple memories (slow)
#!/bin/bash
IDS=("mem_abc123" "mem_def456" "mem_ghi789")

for id in "${IDS[@]}"; do
  mx memories get "$id" --format json >> results.json
done

After

# One command (fast)
mx memories get mem_abc123 mem_def456 mem_ghi789 --format json > results.json

# Or with search
mx memories search --query "my topic" --id-only | \
  mx memories get --stdin --format json > results.json

Upgrading

Batch retrieval is available now in CLI v1.7.29:

mx update
mx --version  # Should show 1.7.29

The feature requires:

• CLI: v1.7.29+
• SDK: v1.17.0+
• Core API: (automatically compatible if running latest)

No configuration changes needed. The batch endpoint is automatically available.

What This Enables

Faster automation scripts: No more looping through IDs with sleep delays to avoid rate limits.

Better AI context: Load complete context in a single round trip. LLMs can access all relevant memories without sequential fetching.

Efficient exports: Backup, migration, or documentation generation that was painful is now practical.

Responsive CLI tools: Build interactive tools that fetch memory groups without noticeable lag.

Technical Details

Request Format

{
  "ids": string[]  // Max 100 IDs
}

Response Format

{
  "data": Memory[],
  "meta": {
    "requested": number,
    "found": number,
    "missing": string[]
  }
}

Short ID Resolution

Short IDs (6+ characters) are resolved client-side before the batch request. The CLI:

1. Accepts both full UUIDs and short prefixes
2. Resolves each short ID to full UUID
3. Sends full UUIDs to batch endpoint
4. Warns about ambiguous or missing prefixes

Rate Limits

Batch requests count as a single API call for rate limiting purposes. Fetching 50 memories in batch uses the same quota as fetching one memory individually.

What's Next

This is the first step in more efficient bulk operations. Coming soon:

• Batch create: Save multiple memories in one request
• Batch update: Update multiple memories atomically
• Batch delete: Remove multiple memories in one call
• Batch operations in SDK: First-class batch support in TypeScript SDK

Because single operations are convenient. But batch operations are fast.

---

Batch memory retrieval is available now in MemNexus CLI v1.7.29. Update with mx update or install with npm install -g @memnexus-ai/cli.