OpenAI-Compatible Memory Proxy

Not every tool speaks MCP. If your client just calls an OpenAI-compatible/v1/chat/completions endpoint — Continue.dev, aider, a LangChain app, a raw SDK script — rohrpost-proxy gives it memory with zero code changes: point the base URL at the proxy instead of the real API, and every request gets relevant context injected automatically, with the conversation captured back into Rohrpost afterward.

Why the proxy, not MCP

MCP requires a client that supports tool calling and is willing to callrohrpost_recall/rohrpost_ingest on its own initiative. Plenty of tools — especially thin CLI wrappers and scripts built directly on an OpenAI SDK — never call tools at all; they just send chat completions. The proxy sits transparently in that path instead: it recalls context for the incoming messages, prepends it as a system message, and forwards the request upstream. The response (and the original prompt) get written back into Rohrpost as capsules, so the knowledge base grows the same way it would through MCP, without the client knowing anything happened.

Availability: the proxy currently ships as part of the self-hosted stack (the same docker-compose setup as everything else). It isn't exposed on the managed service yet — if you're on app.rohrpost.io, use one of theMCP setup guides instead, or self-host the proxy against your managed gateway (see below).

Run the proxy

The proxy is already wired into deploy/docker-compose.yml — if you're running the full stack, it's up on port 7879 already:

git clone https://codeberg.org/ftieben/rohrpost.io
cd rohrpost.io
./deploy/deploy.sh up

To run it standalone against an existing gateway (including a managed one), build and configure it directly:

cargo build --release --bin rohrpost-proxy

ROHRPOST_PROXY_LISTEN_ADDR="0.0.0.0:8080" \
ROHRPOST_PROXY_UPSTREAM_URL="https://api.openai.com/v1" \
ROHRPOST_DATABASE_URL="postgres://rohrpost:rohrpost@localhost:5432/rohrpost" \
ROHRPOST_NATS_URL="nats://localhost:4222" \
./target/release/rohrpost-proxy

Key configuration variables:

Point your client at it

Anything built on the OpenAI SDK (or compatible) just needs a different base_urland your Rohrpost API key in place of the OpenAI key:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:7879/v1",
    api_key="rp_your_api_key",
)

resp = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": "What did we decide about the auth flow?"}],
)

Tools with an "OpenAI-compatible endpoint" setting (Continue.dev, aider's--openai-api-base, most LangChain/LlamaIndex integrations) work the same way — set the base URL to your proxy and the API key to your rp_ token.

# curl, for a quick sanity check
curl http://localhost:7879/v1/chat/completions \
  -H "Authorization: Bearer rp_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4","messages":[{"role":"user","content":"hello"}]}'

Verify it's working

Ingest a fact through any other Rohrpost client (or the API directly), then send a chat completion through the proxy asking about it — if the proxy is injecting context correctly, the model's response will reference the fact even though your client never mentioned it. The injected system message is visible if you log the full request the proxy forwards, or check the response for signs the model saw context it wasn't given directly.

Troubleshooting

401 on every request

The proxy expects the same rp_-prefixed API key format as the gateway and MCP server, sent as a standard Authorization: Bearer header — not the upstream provider's key. Set ROHRPOST_PROXY_UPSTREAM_API_KEY separately if your upstream (e.g. real OpenAI) needs its own key.

Responses feel generic, like recall isn't happening

Check ROHRPOST_PROXY_TOKEN_BUDGET isn't set too low, and confirm the tenant has anything to recall yet — a fresh tenant has an empty knowledge base until it's been used (via the proxy or any other client) for a while.

Streaming responses

The proxy supports streaming ("stream": true) transparently — injection happens before the request is forwarded, and the response stream is passed through while still being captured for later recall.