Driven by your coding agent · CLI-first

Your agent ran it once.
tablize is why you can trust it tomorrow.

A process ledger for agent-produced data: collect raw (append-only), LLM-clean in pulled batches, accept only what passes server-side golden spot-checks — a row in the result table means it was accepted. Every attempt, batch and model is accounted, and the rules live server-side where no agent can quietly rewrite them. Self-hostable, built for millions of rows.

No AI bundled · bring your coding agent — Claude Code, Codex, Cursor or any other · your model key

  tablize skill · Claude Code
crawl the supplier listings & land them raw
imported · suppliers · raw · append-only · 1,204 rows
clean & extract the needs from raw
pulled batch · 50 rows · recipe v3
golden check 5/5 · accepted 48 · rejected 2 (on the books)
which rows can I trust?
result table · a row is here = it was accepted
every attempt · batch · model — accounted · resumable next session
Works with the agent you already run
Claude CodeCodexCursor ZedCSV / XLSX importREST API
What your agent gets done

One edge, fully accounted: collect → clean → accept.

tablize ships no AI of its own — your coding agent drives it, with your model key. The account covers that one edge, and it's honest about what it doesn't cover: it won't discover your data contract, backfill collection you never ran, or prove the output got used.

Collect raw, append-only

Your agent writes the crawl in as-is. Raw is never edited — fixes land downstream, so the source stays the source.

You say"land the supplier crawl as raw"
tablize pipeline init --name supplier --raw-columns "url:text:unique,title:text"

Pull-based LLM cleaning

The agent pulls a small batch, extracts with your own model key, submits. The progress lives on the server — not in its context window.

You say"clean the next 50 raw rows"
tablize tasks pull drv_x --limit 50

Server-side golden acceptance

Golden rows are checked on the server and their expected answers are never handed to the agent. A row in the result table means it was accepted.

You say"show me only what passed"
tablize derive result-table drv_x --name "clean suppliers"

Every attempt accounted

Attempt, batch, model and rejection reason all go on the books — so a batch can't be quietly retried until it looks clean.

You say"who wrote this row, under which recipe?"
tablize log sht_x

Resume from the ledger

Tomorrow's session — or a second agent — reads open tasks, recipes and pending rows straight from the server. Nobody rebuilds yesterday's state.

You say"pick up where we left off"
tablize context

Run it yourself

One Rust server binary on your own infrastructure, with your own storage backend — your data never leaves your network.

You say"keep our data in-house"
one binary · your infra
Real example

What the gate looks like when it actually bites.

Batches don't all pass, and that's the point. When a golden spot-check misses, the edge halts instead of quietly banking the batch — and a person has to say what they fixed before it moves again. Here is the account a supplier-cleaning run leaves behind.

  tablize skill · Claude Code
keep cleaning the supplier raw table
pulled 50 · extracted with your model key · submitted
golden 5/5 · accepted 48 · rejected 2
! batch b_03 · golden 4/5 · edge halted — nothing banked
after derive resume --reason · b_03 retried · 49 accepted
suppliers · extraction account
batchpulledgoldenacceptedoutcome
b_01505/5482 rejected
b_02505/550clean
b_03504/50halted — nothing banked
b_03 ↻505/549✓ resumed, 1 rejected
b_04505/5473 rejected

A passing gate is a drift tripwire, not a proof the batch is accurate — it says the run didn't visibly go off the rails on known sentinels. That distinction is written into the ledger, not just the docs. A full end-to-end script (crawl → clean → accept → morning report) ships with the agent skill.

Connect

Your agent. Your model key. tablize's data.

The CLI is the primary, complete path — it's the agent's native tongue: results land on disk instead of in the context window, it composes with everything else in the shell, and --help loads on demand.

⌘ CLI — the main path
$ tablize install$ tablize login --url … --token …$ tablize doctor Then your agent just drives it over bash — no wrapper, no bridge. A REST command surface — audited, optimistic-locked, same answer every run.
📦 Skill — travels with the binary
$ tablize installThe same command lays the agent skill into Claude Code and Codex, stamped with the CLI's version. One SKILL.md teaches the agent when & how to reach for the CLI — and doctor tells you when it has fallen behind.
⚡ MCP — optional
$ claude mcp add tablize -- tablize-mcp-serverKept available for agents that prefer a structured tool protocol; the CLI stays the path we invest in. Installed separately from tablize install.
The engine

Built for scale you can verify.

A columnar engine in Rust — handles millions of rows fast, with a versioned answer on every query so you can replay and verify it. The numbers below are from its own benchmarks.

0.44ms

1M-row rollup

Columnar pushdown — 215× over row-based. COUNTIF lands 411×.

100/100

Same answer

Same query, same result, every run — versioned for replay.

~0.5s

Bulk ingest

75,000-row import — columnar-native, no row↔column thrash.

1 binary

Self-hostable

One Rust server on your infra, with your storage backend.

// representative numbers from the engine's own benchmarks — columnar predicate pushdown vs row-based fallback

Install

Paste one prompt — your agent wires itself.

tablize is in private beta — email dk@tablize.com and we'll get you a CLI build and an API key. From there you don't run the setup by hand: paste one prompt into Claude Code, Codex or Cursor, and the agent installs, logs in and self-checks.

01 · Paste into your agent
tablize setup prompt · Claude Code / Codex / Cursor
Set up tablize as my data ledger, so the data we produce gets a server-side account: collect raw append-only, LLM-clean in pulled batches, accept only what passes golden checks.

1. Run tablize install — puts the CLI on PATH and lays the tablize skill into your skills directory, so you'll reach for it on your own next time.
2. Run tablize login --url https://api.tablize.com --token <API_KEY> — ask me for the key (app.tablize.com → profile → API keys).
3. Run tablize doctor and confirm all three layers agree: installed == running, skill == CLI, server online.

Then tell me you're ready. House rules: raw tables are append-only; a row in the result table means it was accepted; never work around the gate.
02 · Or wire it by hand
~/your-project
$ tablize install # CLI on PATH + agent skill (Claude Code / Codex)
$ tablize login --url https://api.tablize.com --token <api-key> # key: app.tablize.com → profile → API keys
$ tablize doctor # installed == running? skill == CLI? server online?
03 · From then on, plain language
set up a collect → clean → accept pipeline for my supplier data
keep cleaning the raw table — halt at the first golden miss
which rows can I trust?
Pricing — one base, tier = rung

Start free. Self-host when it matters.

Same engine on every tier. You only move up a rung when your workload does.

Free
$0
Shared server, quota-capped
  • full CLI + agent skill + MCP
  • shared multi-tenant server
  • quota-capped usage
Try it
Most popular
Pro
Usage-based
Pay only for what runs
  • dedicated, suspend-on-idle
  • persistent workspaces
  • pay only for what runs
Start Pro
Enterprise
Self-host
Always-on · private
  • true private deployment
  • on your own infrastructure
  • your infra, your data
Talk to us

Give your agent data it can be held to.

Golden rows gate every batch, the ledger records who wrote what and under which recipe, and tomorrow's session picks up from that account instead of rebuilding it. Same answer every time, self-hostable, millions of rows — driven by the coding agent you already use.