Own your AI data.
Open observability for AI agents.
HypStack is the open-source stack for understanding what your AI is actually doing. It captures every trace and lands it in your own bucket as Apache Iceberg, so you can query millions of sessions straight from object storage. Your data never passes through a vendor you don’t control.
$ npm install -g hypaware $ hyp init # starts the daemon $ hyp query sql "SELECT content_text FROM ai_gateway_messages WHERE role = 'user' LIMIT 10"
1 Overview
Most teams running AI agents can’t answer basic questions about them. The invoice shows one number; the laptops show one developer each; the surveys show what people remember. HypStack records the actual traffic instead, so the questions become queries:
- Where is spend going? Token cost broken down by developer, repo, and workflow, from real sessions rather than a single line on a bill.
- Which prompts and tools work? Which ones succeed, and which quietly loop and burn context, so you can cut what isn’t working.
- How is the team using AI? Patterns across every agent and developer at once, not a survey and not one machine.
The stack is three steps: collect traffic with HypAware, store it as open Iceberg files in a bucket you own, and query it with the libraries or in Hyperparam. Every piece is independent and MIT licensed.
2 Collect: HypAware
HypAware records AI-agent and application telemetry into files you can query. It captures traffic three ways: as a transparent proxy in front of your LLM provider (full request, response, and SSE recordings for Claude Code, Codex, Anthropic, and OpenAI-compatible APIs), as an OTLP endpoint for OpenTelemetry traces, metrics, and logs, and by ingesting agent session transcripts into one queryable row per content block.
Everything normalizes to Iceberg in your bucket, ready for hyp query SQL. It runs standalone
on your machine, where recordings and cache stay local until you choose to ship them, and scales up to
Gateway / Central deployments when many hosts need one control plane.
3 Storage & architecture
HypAware writes traces to Apache Iceberg tables in object storage you own: standard columnar files, an open format, queryable by any engine. There is no proprietary database in the path.
That choice is the whole architecture. Most observability stacks bolt onto a database or a search cluster that has to run around the clock. HypStack starts from object storage instead: traces land as Iceberg files, and every query runs in the client against just the bytes it needs. No server to keep warm, no cluster to scale, no idle cost between queries.
4 Libraries
The stack is built from small, independent libraries. Each is MIT licensed and useful on its own; together they read and write Parquet and Iceberg, and run SQL, full-text, and vector search, in the browser, on Node, or against your data lake.
| Storage & data | ||
| hyparquet | v1.26 | Pure-JS Parquet parser. Zero dependencies, every type and codec, HTTP range requests so you fetch only the bytes you need. |
| icebird | v0.8 | JavaScript Iceberg client. Read and write v1/v2/v3 tables, SQL over Iceberg, file or REST catalogs. Built on hyparquet. |
| hyparquet-writer | v0.15 | The companion writer to hyparquet. Stream rows out as standards-compliant Parquet, no native binaries. |
| Query & search | ||
| squirreling | v0.12 | Streaming async SQL engine. Cell-level lazy evaluation, async UDFs that can call models, 13 kb minified, zero dependencies. |
| hypgrep | v0.2 | Full-text search over Parquet. Build a compact index for a dataset on S3, query it from the browser via range requests. No server. |
| hypvector | v0.2 | Vector search over Parquet. Treat a Parquet file as a vector database, with exact and approximate similarity over range requests. |
5 Benchmarks
Search and semantic retrieval over 3,199,860 real LLM conversations (WildChat-4.8M), run against the same data on every engine. The index lives in object storage and compute happens in the client, with no server and no cluster. At this scale the all-in cost is about $0.33/month, roughly 1,000× cheaper than the equivalent always-on engine on EC2, with nothing idle between queries.
Full-text search: hypgrep vs. the search cluster
| Engine | Index size | Warm query (p50) | All-in / mo | Server |
|---|---|---|---|---|
| hypgrep | 1.20 GB | 237 ms | ~$0.33 | none |
| Elasticsearch | 27.2 GB | 66 ms | $371 | r5.2xlarge 24/7 |
| Quickwit | 28.8 GB | 133 ms | $63 | t3.large 24/7 |
| Athena | none | 5,490 ms | $0.065/query† | serverless |
Vector search: hypvector vs. the vector database
| Engine | Storage | Recall@10 | Query | All-in / mo | Server |
|---|---|---|---|---|---|
| hypvector | 13.7 GB | 0.925 | 147 ms | ~$0.32 | none |
| Pinecone | 13.1 GB | 0.920 | 85 ms | $50 min | managed |
| turbopuffer | 13.1 GB | 0.915 | 198 ms | $16 min | managed |
| S3 Vectors | 13.1 GB | 0.905 | 133 ms | ~$0.79 | serverless |
| pgvector | 41.9 GB | 0.870 | 80 ms | $372 | r5.2xlarge 24/7 |
| Qdrant | 13.1 GB | 0.865 | 70 ms | $186 | r5.xlarge 24/7 |
The always-on engines keep a hot index in RAM and answer fast, but that box runs 24/7 whether you query it once a day or ten times a second. HypStack has no box: the index lives in object storage and compute happens in the client, so you pay for storage and per-query reads, nothing idle. Every competitor was queried over the network, the way it is actually deployed.
† Athena’s $0.065/query is data-scan cost only; it also pays ~$0.30/mo to keep the ~13 GB source parquet in S3.