Last updated: July 2026
This page explains how Zephex uses data that flows through the Service — tool calls, request metadata, dashboard usage, and team rollout responsibilities.
zephex.dev/mcp) — your client connects here (Vercel).Uptime: zephex.dev/status. Technical detail: Data Handling (docs). Team rollout: Team policy.
Zephex does not use prompts, tool inputs, tool outputs, or repository content accessed through tools to train, fine-tune, or evaluate AI models. This applies to all plans without exception.
If you roll Zephex out to a team, the account owner remains responsible for every API key created under that account. Each developer should use named keys per environment; shared keys in chat or public repos violate our acceptable-use rules.
Each tool receives only the arguments you send (paths, queries, URLs). Outputs return to your editor and are not persisted by Zephex.
| Tool | Purpose | Typical team use |
|---|---|---|
get_project_context | Project Context | First on a new repo before guessing install/test commands. Follow related_topics for deeper slices. |
read_code | Code Reader | Known symbol or files[] from find_code. Outline before 300+ line files. Scan/smell on 3–8 focus files. |
find_code | Code Search | Unknown location; pasted line; rename before editing; multi-keyword topic hunt. |
explain_architecture | Architecture Analyzer | Before cross-cutting edits — how does this feature/subsystem span modules? |
Zephex_dev_info | Zephex Dev Info | Generic playbook after repo tools if local context is insufficient. |
audit_headers | Site Audit | User pastes live URL — post-deploy, security, framework, secrets, is it up. |
check_test | Test Pulse | After code changes, before push, or when user asks if tests pass — not to find which files to edit. |
check_package | Package Check | Before npm/pip/cargo install or version bump. User asks "is X safe?" or "how do I upgrade X?" |
keep_thinking | Keep Thinking | High-blast-radius edit (auth, billing, schema); debugging after 2+ failed attempts; task spans 3+ files. |
project_memory | Project Memory | User says remember/recall; before unfamiliar subsystem; after non-obvious decision. |
Tool reference: docs/tools
| Data | Stored? | Duration |
|---|---|---|
| Source code in tool calls | No | — |
| Tool input arguments | No | — |
| Tool output / response body | No | — |
| AI chat / prompts | No | — |
| Tool name per call | Yes | 90 days |
| Timestamp + success/error + latency | Yes | 90 days |
| API key hash (HMAC-SHA256 + salt) | Yes | Until revoked |
| Hashed IP address | Yes | 90 days |
Plans: Pricing tiers
Depending on what you do, the Service may process in memory:
None of the above is written to disk or retained after the HTTP response completes.
We log the minimum required for security and billing: tool name, timestamp, status, and latency — not tool arguments or response bodies. Usage events roll off after 90 days. Account deletion removes profile and key data within 30 days (billing records may be anonymized per tax law).
Data questions: support@zephex.dev
Last updated: July 2026
This page explains how Zephex uses data that flows through the Service — tool calls, request metadata, dashboard usage, and team rollout responsibilities.
zephex.dev/mcp) — your client connects here (Vercel).Uptime: zephex.dev/status. Technical detail: Data Handling (docs). Team rollout: Team policy.
Zephex does not use prompts, tool inputs, tool outputs, or repository content accessed through tools to train, fine-tune, or evaluate AI models. This applies to all plans without exception.
If you roll Zephex out to a team, the account owner remains responsible for every API key created under that account. Each developer should use named keys per environment; shared keys in chat or public repos violate our acceptable-use rules.
Each tool receives only the arguments you send (paths, queries, URLs). Outputs return to your editor and are not persisted by Zephex.
| Tool | Purpose | Typical team use |
|---|---|---|
get_project_context | Project Context | First on a new repo before guessing install/test commands. Follow related_topics for deeper slices. |
read_code | Code Reader | Known symbol or files[] from find_code. Outline before 300+ line files. Scan/smell on 3–8 focus files. |
find_code | Code Search | Unknown location; pasted line; rename before editing; multi-keyword topic hunt. |
explain_architecture | Architecture Analyzer | Before cross-cutting edits — how does this feature/subsystem span modules? |
Zephex_dev_info | Zephex Dev Info | Generic playbook after repo tools if local context is insufficient. |
audit_headers | Site Audit | User pastes live URL — post-deploy, security, framework, secrets, is it up. |
check_test | Test Pulse | After code changes, before push, or when user asks if tests pass — not to find which files to edit. |
check_package | Package Check | Before npm/pip/cargo install or version bump. User asks "is X safe?" or "how do I upgrade X?" |
keep_thinking | Keep Thinking | High-blast-radius edit (auth, billing, schema); debugging after 2+ failed attempts; task spans 3+ files. |
project_memory | Project Memory | User says remember/recall; before unfamiliar subsystem; after non-obvious decision. |
Tool reference: docs/tools
| Data | Stored? | Duration |
|---|---|---|
| Source code in tool calls | No | — |
| Tool input arguments | No | — |
| Tool output / response body | No | — |
| AI chat / prompts | No | — |
| Tool name per call | Yes | 90 days |
| Timestamp + success/error + latency | Yes | 90 days |
| API key hash (HMAC-SHA256 + salt) | Yes | Until revoked |
| Hashed IP address | Yes | 90 days |
Plans: Pricing tiers
Depending on what you do, the Service may process in memory:
None of the above is written to disk or retained after the HTTP response completes.
We log the minimum required for security and billing: tool name, timestamp, status, and latency — not tool arguments or response bodies. Usage events roll off after 90 days. Account deletion removes profile and key data within 30 days (billing records may be anonymized per tax law).
Data questions: support@zephex.dev