# What Telemetry Data Does G0DM0D3 Collect? A Complete Guide to Its Three-Tier Architecture

> Discover what telemetry data G0DM0D3 collects via its robust three-tier architecture. Learn about its privacy-first approach, excluding sensitive info unless opted-in.

- Repository: [pliny/G0DM0D3](https://github.com/elder-plinius/G0DM0D3)
- Tags: how-to-guide
- Published: 2026-07-19

---

**G0DM0D3 collects operational metadata through a three-tier telemetry system that deliberately excludes prompt content, responses, API keys, and personally identifiable information (PII), unless users explicitly opt-in to public dataset contribution.**

The open-source project **elder-plinius/G0DM0D3** implements a privacy-first telemetry architecture designed to gather performance insights without compromising user privacy. Understanding what telemetry data G0DM0D3 collects requires examining its strict separation between structural metadata and user-generated content across client and server boundaries.

## The Three-Tier Telemetry Architecture

G0DM0D3 separates data collection into three distinct tiers that run across the browser client and optional API server. Each tier operates independently, with only Tier 3 capable of capturing conversation content—and only when users explicitly consent to publishing data to a public HuggingFace dataset.

The architecture ensures that **prompt text, response text, API keys, and dedicated PII fields** remain excluded from automatic collection. According to the source code in [`src/lib/telemetry.ts`](https://github.com/elder-plinius/G0DM0D3/blob/main/src/lib/telemetry.ts) and [`functions/api/telemetry.ts`](https://github.com/elder-plinius/G0DM0D3/blob/main/functions/api/telemetry.ts), the system uses a fire-and-forget batching mechanism that writes JSON-L batches to Cloudflare KV before publishing to the public dataset `pliny-the-prompter/g0dm0d3`.

## Tier 1: ZDR Metadata Tracker (Server-Side)

The **ZDR Metadata Tracker** operates exclusively on the API server (Node/Express) and activates for every API call without exception. This tier records purely operational metrics to monitor system health and performance characteristics.

**What it records:**
- Timestamp, endpoint, and mode
- Pipeline flags and model counts
- Per-model results (name, score, duration, success flag)
- Total duration and response length (character count only)
- Error categories and other operational fields

**What it excludes:**
- Prompt or response content
- API keys
- IP addresses
- Any dedicated PII fields

This server-side implementation ensures that even if the client is compromised or configured incorrectly, the API server never logs the actual content of conversations passing through it.

## Tier 2: Client-Side Telemetry Beacon

The **Client-Side Telemetry Beacon** runs in the browser (either the stand-alone [`index.html`](https://github.com/elder-plinius/G0DM0D3/blob/main/index.html) or the React frontend) and activates by default for all users. Users can disable this tier entirely by enabling **No-Log Mode** or **Local-only mode** in the settings.

Located in [`src/lib/telemetry.ts`](https://github.com/elder-plinius/G0DM0D3/blob/main/src/lib/telemetry.ts), this beacon captures interaction patterns and performance metrics while maintaining strict content exclusion policies.

**Collected fields include:**
- Event type (e.g., `chat_completion`)
- Timestamp and randomly generated session ID
- Mode, model name(s), and latency measurements
- Content lengths (character counts only, never full text)
- Success flags and pipeline configuration (autotune, parseltongue, STM modules, strategy, godmode)
- AutoTune detection details and Parseltongue trigger counts
- ULTRAPLINIAN race details
- **Harm-taxonomy classification label** (category only, never the raw prompt)

**Explicitly excluded:**
- Full prompt or response text
- API keys and tokens
- Images
- Request IP addresses (IP is used only for rate-limiting inside Cloudflare functions and never stored in telemetry records)

The beacon batches events in memory (flushing at 20 events or 30 seconds) and transmits them to the Cloudflare Pages Function endpoint `/api/telemetry`.

## Tier 3: Opt-In Dataset Collection

**Tier 3 represents the only mechanism through which G0DM0D3 collects full conversation content**, and it requires explicit user activation. This tier activates only when a caller sends `contribute_to_dataset: true` in their request.

When enabled, this tier collects:
- **Full conversation content** (complete prompts and responses)
- Model and endpoint used
- Mode, AutoTune, Parseltongue, STM, and ULTRAPLINIAN details
- User feedback

**Critical privacy note:** This data is published immediately to a **public HuggingFace dataset** (`pliny-the-prompter/g0dm0d3`). Users must understand that enabling this tier makes their conversations publicly accessible for research and analysis purposes.

## How Telemetry is Transmitted and Stored

All telemetry follows a **fire-and-forget** architecture designed for minimal performance impact and maximum privacy.

**Batching strategy:**
- **Client-side:** Buffers up to 20 events or flushes every 30 seconds
- **Server-side (Cloudflare KV):** Buffers up to 50 events or flushes every 30 minutes

The Cloudflare Pages Function in [`functions/api/telemetry.ts`](https://github.com/elder-plinius/G0DM0D3/blob/main/functions/api/telemetry.ts) receives these batches and writes them to the public HuggingFace dataset. If the `TELEMETRY_KV` binding is unavailable, the function falls back to in-memory isolates, discarding events only if delivery fails entirely.

This implementation ensures that telemetry never blocks user operations or retains data indefinitely in volatile memory.

## Controlling Telemetry Collection

Developers and users can programmatically control telemetry through the API exposed in [`src/lib/telemetry.ts`](https://github.com/elder-plinius/G0DM0D3/blob/main/src/lib/telemetry.ts).

### Starting the Telemetry System

Initialize the periodic flush timer during application startup:

```typescript
import { startTelemetry } from '@/lib/telemetry'

// Initialise the periodic flush timer – this begins collecting events.
startTelemetry()

```

### Recording Events Manually

After each LLM request, record structured metadata without exposing content:

```typescript
import { recordChatEvent } from '@/lib/telemetry'

function onChatResponse(data) {
  recordChatEvent({
    mode: 'standard',
    model: data.model,
    duration_ms: data.latency,
    response_length: data.response.length,
    success: data.success,
    pipeline: {
      autotune: data.autotuneEnabled,
      parseltongue: data.parseltongueEnabled,
      stm_modules: data.stmModules,
      godmode: data.godmodeEnabled,
    },
    autotune: { detected_context: data.context, confidence: data.confidence },
    parseltongue: { triggers_found: data.triggers, technique: data.technique, intensity: data.intensity },
  })
}

```

### Disabling Telemetry

When users toggle **No-Log Mode** in [`src/components/SettingsModal.tsx`](https://github.com/elder-plinius/G0DM0D3/blob/main/src/components/SettingsModal.tsx), stop collection and clear buffers:

```typescript
import { stopTelemetry } from '@/lib/telemetry'

// Stop the timer and flush any remaining buffered events.
stopTelemetry()

```

### Custom Event Tracking

For feature usage analytics, send arbitrary event types:

```typescript
import { recordEvent } from '@/lib/telemetry'

recordEvent('feature_use', { feature: 'ultraplinian', enabled: true })

```

## Summary

- **G0DM0D3 employs a three-tier telemetry architecture** that separates server-side metadata (Tier 1), client-side behavioral metrics (Tier 2), and optional public dataset contribution (Tier 3).
- **No prompt or response content** is collected in Tiers 1 or 2; only character counts and operational metadata are transmitted.
- **API keys and PII** are explicitly excluded from all automatic telemetry collection according to [`TERMS.md`](https://github.com/elder-plinius/G0DM0D3/blob/main/TERMS.md) and the implementation in [`src/lib/telemetry.ts`](https://github.com/elder-plinius/G0DM0D3/blob/main/src/lib/telemetry.ts).
- **Users control Tier 2 collection** through No-Log or Local-only modes, which immediately stop the beacon and clear pending buffers.
- **Tier 3 requires explicit opt-in** and publishes full conversations to the public HuggingFace dataset `pliny-the-prompter/g0dm0d3`.
- **All telemetry is fire-and-forget**, using batched JSON-L writes to Cloudflare KV with fallback handling to prevent data loss or blocking.

## Frequently Asked Questions

### Does G0DM0D3 store my API keys in telemetry logs?

No. API keys are stored exclusively in browser local storage and transmitted only to the configured model provider endpoints. The telemetry system in [`src/lib/telemetry.ts`](https://github.com/elder-plinius/G0DM0D3/blob/main/src/lib/telemetry.ts) explicitly excludes API keys, tokens, and credentials from all event schemas. Both Tier 1 (server-side) and Tier 2 (client-side) telemetry filters actively strip any authentication materials before batching.

### Can I use G0DM0D3 without sending any telemetry data?

Yes. You can disable Tier 2 telemetry entirely by enabling **No-Log Mode** or **Local-only mode** in the settings interface ([`src/components/SettingsModal.tsx`](https://github.com/elder-plinius/G0DM0D3/blob/main/src/components/SettingsModal.tsx)). When disabled, `stopTelemetry()` clears the event buffer and halts the periodic flush timer. Note that Tier 1 server-side metadata may still be collected if you use the API server, though this excludes all content and PII.

### What happens if I enable the dataset contribution feature?

When you set `contribute_to_dataset: true`, Tier 3 telemetry activates and transmits **full conversation content** (complete prompts and responses) along with pipeline configuration details to a public HuggingFace dataset. This data becomes immediately accessible to the public for research purposes. This is the only tier that captures actual conversation text, and it requires explicit user consent per the data collection terms outlined in [`TERMS.md`](https://github.com/elder-plinius/G0DM0D3/blob/main/TERMS.md).

### Where is the telemetry data physically stored?

Telemetry events are batched in memory (client-side for 30 seconds or 20 events, server-side for 30 minutes or 50 events) before being transmitted to a Cloudflare Pages Function at `/api/telemetry`. The function writes JSON-L batches to Cloudflare KV and subsequently publishes them to the HuggingFace dataset `pliny-the-prompter/g0dm0d3`. If Cloudflare KV is unavailable, the system uses in-memory isolates as a fallback, discarding data only if transmission fails completely.