Move LLM trace data between systems: pull from providers, push to metergraph.
Project description
metergraphrelay
Export OpenAI stored chat completions as trace records, and optionally generate demo conversations to try it out.
Purpose
Download the chat completions already stored in your own OpenAI
account (completions created with store=True) as local JSONL trace
records — useful for auditing, backups, or feeding into other tooling.
This tool only reads what's associated with the API key you provide; it
can't see or export anyone else's data.
Built on OpenAI's List Chat Completions API,
which returns completions that were created with store: true. See the
official OpenAI API reference
for the underlying data model.
Setup
pip install -e ".[dev]"
cp .env.example .env
# edit .env and set OPENAI_API_KEY
Usage
Generate 1-2 demo conversations (stored with store=True) so there's
data to pull:
metergraphrelay demo openai
Pull the 10 most recent stored chat completions into traces.jsonl,
already shaped as metergraph trace records:
metergraphrelay pull openai
Options:
metergraphrelay pull openai -n 25 --output my-traces.jsonl --stdout --include-content --route my-app/support-bot
metergraphrelay demo openai --model gpt-4o-mini
Push a local JSONL file of traces to metergraph:
metergraphrelay push traces.jsonl
pull anthropic and pull langfuse accept the same shape but are not
yet implemented in this version — they check for ANTHROPIC_API_KEY /
LANGFUSE_PUBLIC_KEY+LANGFUSE_SECRET_KEY and report accordingly.
All subcommands accept --env-file PATH to point at a config file
other than ./.env.
Using it against your real system (not just the demo)
metergraphrelay pull openai only finds completions that were created
with store=True. The demo openai subcommand sets that flag for you,
but for your own application to show up in a pull, its own OpenAI calls
need the same flag. The only change required is adding store=True
(and, optionally, metadata to help you tell requests apart later) to
calls you're already making:
from openai import OpenAI
client = OpenAI()
response = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": "..."}],
store=True, # <-- persists this completion for later pulling
metadata={"source": "my-app"}, # optional: filter/identify later via the API
)
No other code changes are needed — the request and response are handled
exactly as before. Once your app is sending store=True, its completions
become visible to metergraphrelay pull openai (or to the
List Chat Completions API
directly) using the same API key.
Two things worth knowing before flipping this on in production:
- Stored completions include full request/response content by default, so treat them as you would any other place your data is retained.
- Storage has no automatic expiry from this tool's side — deletion is a
separate API call (Delete chat completion),
not something
metergraphrelaycurrently does.
Trace record shape
Each line of pull openai's output is a JSON object already shaped for
metergraph's ingest API:
{
"ts": "2026-07-30T12:00:00+00:00",
"provider": "openai",
"model": "gpt-4o-mini",
"status": "success",
"endpoint": "chat.completions",
"input_tokens": 12,
"output_tokens": 34,
"error": false,
"error_type": null,
"request_id": "chatcmpl-...",
"tags": {},
"route": "openai/backfill",
"content_opted_in": false,
"request_json": null,
"response_text": null,
"sdk": "metergraphrelay",
"sdk_version": "0.1.0"
}
request_json/response_text are populated only when --include-content
is passed.
Every completion returned by the stored-completions list already succeeded, so
status is always "success". error/error_type flag a partial record:
--include-content was requested but the follow-up message fetch failed, so
token counts are still real while the content is missing.
Running tests
pytest
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
Filter files by name, interpreter, ABI, and platform.
If you're not sure about the file name format, learn more about wheel file names.
Copy a direct link to the current filters
File details
Details for the file metergraphrelay-0.1.0.tar.gz.
File metadata
- Download URL: metergraphrelay-0.1.0.tar.gz
- Upload date:
- Size: 12.7 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/7.0.0 CPython/3.13.3
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
e370d7a7dc03e09aa16e0f93eab87fa203750cee68d3367b2b4f12fa8256c947
|
|
| MD5 |
e1756633facc2bb16adae6476836cca1
|
|
| BLAKE2b-256 |
6f18d9fbd745e714215cdd0cbc4f3f2f765d3ebdd818b72211ab0222e47436fa
|
File details
Details for the file metergraphrelay-0.1.0-py3-none-any.whl.
File metadata
- Download URL: metergraphrelay-0.1.0-py3-none-any.whl
- Upload date:
- Size: 9.8 kB
- Tags: Python 3
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/7.0.0 CPython/3.13.3
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
08715a5e23f404a6d0cd470660509ab2307af4fdbfdeed387bfe1de03ca60e5e
|
|
| MD5 |
6d8dc97a0aa0bbaa224bd28b99610dcc
|
|
| BLAKE2b-256 |
9ccd8a345cd1079526347f64538a0391f1fcf8b328948ae28a5aad4812d62d50
|