5 · Agent session that remembers

Same X-Conversation-Id across turns resumes the real Devin session — not a replayed transcript.

What it is

An explicit X-Conversation-Id (or body field) tells routsi it owns memory for this thread, not the client. First turn runs devin -p and captures the resulting session id (via devin list --format json); every later turn with the same conversation id runs devin -r <session> -p — a real resumed Devin session, so the agent keeps its own internal state, not just a re-sent transcript.

Why

Multi-turn agent work (a refactor plan, an incident investigation) needs the agent's own continuity — file edits, shell history, its own reasoning trace — which a client replaying "here's everything said so far" can't reconstruct. This also keeps the client dead simple: send only the new message, never the growing history.

Configure

- name: devin
  type: devin
  provider: cognition
  variants: [sonnet, opus]     # -> devin --model <variant>

curl localhost:8080/v1/chat/completions \
  -H 'X-Conversation-Id: refactor-1' \
  -d '{"model":"devin/claude-opus-4.8","messages":[{"role":"user","content":"draft a refactor plan for the auth module"}]}'

curl localhost:8080/v1/chat/completions \
  -H 'X-Conversation-Id: refactor-1' \
  -d '{"model":"devin/claude-opus-4.8","messages":[{"role":"user","content":"now do step 2"}]}'
# → Devin resumes session refactor-1, remembers step 1

How to adapt

The same conversation-id contract applies to codex/copilot/claude model types and to forward upstreams routed through toolnexus — pass an id and the proxy manages memory; omit it and the client resends full history as usual (raw passthrough). Fingerprint ids (fp- prefix, hashed first user message) are for routing stickiness only and never trigger proxy-managed memory. See Agents as models for the full config shape (custom bin:/args:, variants, permission mode).

Next: Pull-worker →