v0.1.2

Hide protocol-artifact client_version for go-http-client rows (always Go HTTP protocol version, never app identity).

Highlights:

• New clientDisplay.ts helpers (displayClientVersion, clientLabel) centralize the noisy-version allowlist.
• Wired in Landing ACTIVE CLIENTS and TracesList client cell tooltip.

---

Added

• Protocol-artifact client_version suppression (commit
  9251f25): Go's net/http stdlib emits
  Go-http-client/2.0 (HTTP/2) or Go-http-client/1.1 regardless of
  the calling app. Showing "2.0" next to "go-http-client" implies
  operator identity signal where the parser only knows the protocol
  version. clientDisplay.ts centralizes a noisy-version allowlist
  behind displayClientVersion(kind, version) + clientLabel; wired
  in Landing ACTIVE CLIENTS + TracesList client cell tooltip.
  Audit-driven (v0.1.1 deploy workflow showed sub2api's 27/200
  go-http-client rows all report version 2.0).

v0.1.1

Storage retention UI surface for the api-log v0.1.1 backend.

Highlights:

• Landing STATUS strip gains a state badge (ok / warning / critical) when retention is configured.
• New Settings → Storage card with max_bytes / max_age_days / warn_at_percent inputs that GET + PUT /api/config/retention.
• i18n strings for both languages.

---

Added

• Storage retention surface (matches api-log v0.1.1 backend):
  Landing STATUS strip's data cell gains a state badge (ok /
  warning / critical) when the backend has retention configured.
  Settings adds a new Storage card with max_bytes /
  max_age_days / warn_at_percent inputs that GET + PUT
  /api/config/retention. Both knobs zero surfaces a "disabled"
  status row; 503 from a coord-less backend renders the card with
  a helpful hint. i18n strings for both languages.

v0.1.0

api-log-viewer v0.1.0 is the first Svelte 5 SPA frontend for api-log traces: a static viewer for LLM gateway request/response logs, built for operators running api-log in front of sub2api, CLIProxyAPI (CPA), new-api, or compatible gateway stacks.

What is included

• Reads the api-log `>= 0.1.0` HTTP read API.
• Displays recorded requests, responses, SSE chunks, tool calls, reasoning content, sessions, raw headers/bodies, and replay data.
• Supports OpenAI Chat Completions, Anthropic Messages, OpenAI Responses, OpenAI Image Generations, and Gemini trace shapes.
• Ships as a hash-router SPA; no server-side rendering or frontend runtime required.
• Operator pages: trace search, detail inspection, plugin config, export bundles, settings, auth, theme, en/zh language switch.
• `dist.zip` is attached as the built static SPA bundle.

Serve the attached dist.zip

Download and unpack the attached release asset:

gh release download v0.1.0 --repo 2nd1st/api-log-viewer --pattern 'dist.zip'
unzip -q dist.zip -d /opt/api-log-viewer
ls /opt/api-log-viewer/dist/index.html

Serve `/opt/api-log-viewer/dist` as static files and reverse-proxy `/api/*` plus `/healthz` to api-log's read API on the same origin.

Caddy

viewer.example.internal {
  root * /opt/api-log-viewer/dist
  file_server

  handle /api/* {
    reverse_proxy 127.0.0.1:7862
  }

  handle /healthz {
    reverse_proxy 127.0.0.1:7862
  }
}

Nginx

server {
  listen 443 ssl;
  server_name viewer.example.internal;

  root /opt/api-log-viewer/dist;
  index index.html;

  location / {
    try_files \$uri /index.html;
  }

  location /api/ {
    proxy_pass http://127.0.0.1:7862;
  }

  location /healthz {
    proxy_pass http://127.0.0.1:7862;
  }
}

api-log hosted viewer

api-log `v0.1.0` can host this viewer at `/viewer/` by default. The backend fetches the pinned `dist.zip`, verifies its SHA-256, extracts it into `data/viewer-cache/`, and serves it without embedding HTML into the binary.

docker pull ghcr.io/2nd1st/api-log:0.1.0
# Start api-log normally, then open:
# http://127.0.0.1:7862/viewer/

For offline or isolated deployments, unpack `dist.zip` yourself and point api-log at the local `dist/` directory:

APILOG_VIEWER_LOCAL_PATH=/opt/api-log-viewer/dist
APILOG_VIEWER_PUBLIC_PATH=/viewer

Security notice

The viewer renders what the backend recorded. api-log records raw request headers, including `Authorization` and `x-api-key`, unless your deployment redacts before capture. Treat the viewer origin, the admin bearer token, and the api-log data directory as trusted-network assets. Put the viewer behind VPN, mTLS, or reverse-proxy authentication on shared deployments.

Backend pairing

Backend repo: https://github.com/2nd1st/api-log

The normal production layout is:

1. Clients send traffic to api-log's proxy listener.
2. api-log forwards unchanged traffic to your LLM gateway and records JSONL + SQLite traces.
3. api-log-viewer reads api-log's HTTP read API from the same origin.

Known limitations / v0.1.x direction

• v0.1.0 reads one api-log backend origin at a time.
• Standalone JSONL / SQLite store adapters are a post-v0.1 direction; this release reads the api-log HTTP read API.
• The viewer does not capture, route, store, replay to upstream, or redact traffic.
• The admin bearer token is stored in browser `localStorage`; protect the viewer origin.
• v0.1.x focus: sharper filters, richer protocol rendering, export workflows, and the adopter-pluggable store boundary.