Grepture is a drop-in LLM API proxy and TypeScript package that sits between an application and providers such as OpenAI or Anthropic, logging every call while detecting and redacting PII, blocklisting sensitive content, and tokenizing fields before a request reaches the upstream model.

What it is

Grepture is an open-source proxy for LLM APIs, written in TypeScript and licensed under AGPL-3.0. It sits in the AI and Machine Learning registry under Machine Learning Infrastructure, and its listed topics are ai-gateway, llm-gateway, llm-observability, llmops, and prompt-management. Rather than calling a provider endpoint directly, a client points at the Grepture proxy, which authenticates the request, applies input rules, forwards the payload upstream, applies output rules to the response, and detokenizes anything it replaced. The documented pipeline is Client to Proxy, then Auth, Input Rules, Forward, Output Rules, Detokenize, and back to the client.

The concrete problem it solves is that prompts and responses routinely carry personal data such as email addresses, phone numbers, Social Security numbers, credit card numbers, IP addresses, addresses, and dates of birth, and that traffic otherwise leaves the application untouched. Grepture inspects that traffic in flight and rewrites or blocks it, so the same protection applies to every call instead of being reimplemented inside each application or each provider integration.

Key capabilities

• A redact_pii action detects and redacts email, phone, SSN, credit card, IP, address, and DOB patterns using regex.
• Additional actions include find_replace (literal or regex), tokenize (replace JSON fields with tokens and store originals for later restoration), redact_field, block_request with a custom status code and message, and log_only.
• Rules live in a JSON file, default rules.json, with conditions, actions, apply_to values of input, output, or both, and a sampling_rate of 1 to 100 percent. Rules reload automatically when the file changes or on SIGHUP.
• Upstream routing uses request headers: X-Grepture-Target sets the provider URL and X-Grepture-Auth-Forward forwards the provider credential.
• Log bodies are stored inline up to 50KB; larger payloads are offloaded to any S3-compatible backend configured through R2_ENDPOINT, R2_ACCESS_KEY_ID, R2_SECRET_ACCESS_KEY, and R2_BUCKET, with a 5KB preview and pointer key left in the database.
• Configuration is environment-driven: GREPTURE_API_KEY optionally restricts callers to one bearer token, GREPTURE_RULES_FILE overrides the rules path, GREPTURE_PLUGINS loads comma-separated plugin modules, and PORT defaults to 4001.
• A published Dockerfile builds an image named grepture-proxy.

Who uses it and how

• Teams calling multiple providers through one gateway, since a single proxy target handles both OpenAI-style and Anthropic-style endpoints.
• Privacy or compliance reviewers who need PII stripped before prompts leave the network, with per-rule sampling_rate available for staged rollout.
• Self-hosters running the proxy in Docker with a mounted rules.json, keeping rule changes outside the image and reloadable by file change or SIGHUP.
• High-volume deployments that persist logs and need body offload: the S3 upload runs during the log-batch flush after the response has already been returned, so it adds no latency to the request path.
• Extension authors writing plugin modules loaded at startup through GREPTURE_PLUGINS.

Getting started

Copy and edit the example rules with cp rules.example.json rules.json, then start the proxy with bun run src/index.ts, which listens on port 4001. To containerize, run docker build -t grepture-proxy . and start it with the rules file mounted at /app/rules.json.

How it compares

This registry lists no comparable or competing tools alongside Grepture, and the facts name no paid products it replaces, so no licence, hosting, or cost comparison can be drawn from them. On the evidence available it stands alone in this registry.

When to use it — and when not to

A self-hoster must operate the proxy itself, maintain a rules.json, and, for cloud-mode logging with large bodies, provision an S3-compatible bucket with Object Write permission; without R2_* configured, bodies silently fall back to 50KB inline truncation, and encryption at rest depends entirely on the bucket's own access controls. Local mode writes bodies to stdout with a default 10MB per-request ceiling and no external storage, so it suits single-node development rather than durable audit retention. The project is early and lightly adopted, with 8 stars, 0 forks, and no open issues, and the README excerpt is partial, so anyone needing a proven, widely deployed gateway should evaluate that maturity gap first.

# Copy and edit the example rules
cp rules.example.json rules.json

# Start the proxy
bun run src/index.ts

curl http://localhost:4001/proxy/ \
  -H "Authorization: Bearer any-token" \
  -H "X-Grepture-Target: https://api.anthropic.com/v1/messages" \
  -H "X-Grepture-Auth-Forward: Bearer sk-ant-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4-5-20250514",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "My email is [email protected]"}]
  }'

docker build -t grepture-proxy .

docker run -p 4001:4001 \
  -v $(pwd)/rules.json:/app/rules.json \
  grepture-proxy

Client → Proxy → [Auth] → [Input Rules] → [Forward] → [Output Rules] → [Detokenize] → Client