State · :7777

State between calls

Plugins are stateless by default — every call starts fresh. State Broker stores state with TTL: in-memory, daemon, or Redis. The API never changes.

When to use what

Three modes. One API.

Development

In-Memory

~1ms latency

Fast in-process cache. No infrastructure required. Data resets on restart.

Production

Redis

~5ms latency

Shared state across instances with persistence. Same API — swap with a config change.

Edge

Custom adapter

any latency

Implement ICache and bind in kb.config.json. Any backend you choose.

HTTP API

Four routes. Nothing extra.

GET · PUT · DELETE /state/:key plus POST /state/clear. Keys are namespaced: tenant:default:namespace:key. TTL in milliseconds, default 5 minutes.

Documentation
bash
# Store state with TTL (milliseconds, default 300 000 = 5 min)
PUT /state/tenant:default:mind:conv-abc
Content-Type: application/json

{ "value": { "lastReply": "Hello!", "turn": 3 }, "ttl": 300000 }

# 204 No Content

# Read back
GET /state/tenant:default:mind:conv-abc

# → { "lastReply": "Hello!", "turn": 3 }

# Clear an entire namespace
POST /state/clear?pattern=tenant:default:mind:*

# 204 No Content
Try it now

Starts with the platform.

kb-dev start brings up the State Daemon automatically. Switch the backend in config — don't touch your services.

State Broker — KB Labs