Introducing Tera—the World’s Most Efficient Data Coworker

Tera is Teradata's agentic coworker for data and AI work. We built it with the conviction that a big-data warehouse needs a different kind of agent. What surprised us was that this different kind of agent turned out to be better at not just data, but everything.

This report presents the results of measuring it against Anthropic's own Claude Code—the industry's baseline—on four public benchmarks. Same tasks. Same limits. Same model. On every one, Tera does the same work at about half the cost, in about half the wall time with equal or better accuracy than Claude Code. 

The rest of this report is why—what forced us to build our own, why the discipline it required turned out to matter beyond data, and where each number came from.

Why we built our own harness

Every enterprise now buys its frontier models from the same short menu. The harness around the model—what context it feeds in, which tools it can reach, how it checks an answer before offering it, when it decides the work is done—is the real differentiator. And it’s where data teams hit a wall. General-purpose coding agents, however fluent in SQL, don’t survive contact with a production warehouse. 

Teradata's work is data work, and data breaks the assumptions a coding agent is built on: 

• A wrong number looks like a right one. Code that’s nearly right fails a test. A query that’s nearly right returns a number. Join VARCHAR to CHAR and trailing spaces silently drop 40% of the rows; the revenue figure that reaches the dashboard is wrong, plausible, and indistinguishable from a correct one. Nothing turns red. No test catches it, no reviewer spots it. If it surfaces at all it surfaces weeks later in a board pack.
• Failure is catastrophic. An exploring agent fires a hundred queries during a single investigation, in parallel, with nobody watching any of them. Every one is a live action against production infrastructure. There is no review step at the end because there is no end—the exploration is the execution. One careless predicate in the middle takes the warehouse down for everyone on it. 
• Nothing fits (in agent context). Not the schema—thousands of tables before a single row is read. Not the data—nobody reads a billion rows at any budget. Not even the results of the queries the agent runs to understand the data, which can exceed the window on their own. A repository can be read end to end if you’re willing to pay for it; a warehouse can’t be read at all, by anyone, ever. The agent must know what to ask for before it asks—and be right.
• Access is not configuration. Personally identifiable information (PII) can't enter the transcript. Credentials can't land in a session log. Row-level permissions apply to every reach the agent makes, not to the answer it finally returns. A coding agent that leaks a secret into its own logs has an incident; a data agent that does it has a breach.

Together these set the standard of care at which the agent must operate. A coding agent can afford to be careless because the environment corrects it—the build breaks, the test goes red, review catches the commit. Those are free corrections it never had to earn. In data none of them exist, so the agent has to carry the discipline itself.

That’s what we built Tera for: make the error rarer, keep the blast radius small, and fail fast when it fails.

What we didn’t expect is that the same discipline would win outside data. Measured on general software engineering—unfamiliar codebases, changes spanning dozens of files, none of it anywhere near a warehouse—Tera matched the best available agents on quality and beat them substantially on cost. Nothing in its design was aimed at that result.

So we measured it properly: four types of enterprise workload, four benchmarks we don’t own, graded by tests we don’t control. 

What we measured 

We picked four public benchmarks and ran them in the order that mattered to us: from the work Teradata's customers pay us to do, to work we weren’t built for at all. 

data-eng-bench—Snowflake Labs 

data-eng-bench, created by Snowflake Labs and Bespoke Labs, is the closest test to our day job. Its 103 tasks are dbt transformation models built and repaired over a synthesized retail warehouse. Grading is by pytest, 27 assertions per task, and a task passes only when every assertion passes. Every task is run three times and we report Pass³—all three attempts must succeed—because a pipeline that works one time in three has not been delivered. 

$1.23 per reliably-delivered pipeline against $2.61 for CoCo—Snowflake's own agent—and $3.40 for Claude Code.

ᵖ CoCo figures published by Snowflake; cost estimated under full accounting. Steps and tool operations blank because Snowflake publishes only a multiplier against its own Claude Code run.

ADE-bench—dbt Labs 

ADE-bench, from dbt Labs, is one step out from data engineering into analytics engineering: 75 tasks inside real dbt projects—airbnb, asana, quickbooks, formula one. A package upgrade has broken compilation. A metric is returning the wrong figure. A model needs restructuring. The brief arrives the way briefs actually arrive: two sentences from someone who doesn’t know how many files the change will touch, and the work of finding that out is the task.

Tera Sonnet is the 2026–09–11 latest-3ff09585 sweep (57/75). Claude Sonnet is the 2026–09–05 08:58 sealed sweep (52/75)—the matched-arm baseline. Tera Opus is the 2026–09–06 03:21 sweep (56/75); Claude Opus is the 2026–09–05 07:27 sweep (56/75). All runs on us-west-2 Bedrock, sealed network, 300s test timeout.

Tera wins on cost, wall clock, and turns on both model tiers. On Sonnet, Tera resolves five more tasks; on Opus, both agents tie at 56/75 but Tera does it in 60% of the wall time and 60% of the cost. 

DataAgentBench—UC Berkeley and Hasura 

DataAgentBench, from UC Berkeley and Hasura, is the one that looks least like the others. It poses 54 analytical questions across 12 real datasets—Yelp reviews, GitHub repositories, patent filings, CRM records, stock markets—five runs each, graded on exact match against ground truth. It’s deliberately not an SQL benchmark. The data sits in more than one database on more than one engine, join keys don’t line up, and in several cases the answer must be pulled out of unstructured text before it can be computed at all. 

SWE-bench Pro—Scale AI 

SWE-bench Pro, from Scale AI, is the general-software-engineering benchmark, and it’s the one we didn’t target. Its 731 tasks are real merged pull requests from production open-source systems, including Ansible, Teleport, Proton Mail, qutebrowser, NodeBB, and Element. The agent gets the repository as it stood the moment before the fix and the issue text as a user actually filed it. When the agent is finished the maintainers' own test suite—withheld until that point—is applied, and the task resolves only if every failing test now passes and every test that was already passing still does. There’s no partial credit and no model judging the result.

We ran this one because if the discipline that data forced turned out to generalize, general software engineering is where the sharpest test would be. Both agents drove claude-opus-5 under identical limits, so capability was fixed before either of them started. A harness cannot make a model more capable; it decides only how much compute to spend wielding what’s already there. 
 

Opus arm: full 731-task campaign Fable arm: 147-instance subset. 

 

Agent turn—the master variable 

Every agent's bill has one dominant term: the number of turns it takes to finish a task. Every turn re-reads the entire conversation, and every turn spends a fresh block of reasoning tokens. The bill is set by turns and turns alone. 
 

This isn't a Tera-specific claim. It's a property of how chat-completion APIs bill. Across the four agents we measured, cache re-reads and reasoning together carry 96% of every dollar, and both scale with turns. Reduce turns and both terms of the bill collapse together. Reduce turns and the wall clock shrinks with them. Reduce turns and there are fewer opportunities to take a wrong step. 

 

Deep batching 

Every agent batches somewhere (Claude Code batches parallel tool calls, Cursor batches file reads). Tera takes batching to another level: it batches at every layer—DB, file, shell, discovery, output. That commitment—batching everywhere, all the time, as the default rather than the optimization—is what we call deep batching. 

Each batch saves a turn. The savings compound: fewer turns → smaller transcript → less re-read on the next turn → cheaper still. 

What halving the turns actually buys 

Fewer turns turns into fewer tokens, fewer dollars, less wall clock. On data-eng-bench Opus the compounding is direct:

2.5× fewer steps → 4.6× fewer tokens → 2.7× cheaper → 2.0× faster. Every downstream number in this report traces back to that first ratio. 

Where the turn savings come from: DB, file, shell 

The 2.5× turn advantage on data-eng-bench Opus isn't spread evenly. Break the tool calls into three families—DB operations, file operations, shell operations—and the shape of the savings shows itself: Tera is roughly 2.3× ahead on DB, 2.5× on file, and 4.6× on shell.

Two mechanisms are at work, and the data separates them cleanly:

1. Purpose-built tools replace shell scripting. Claude Code has generic Bash and Edit. Tera has execute_query, table_profile, file_read, file_write, edit_files. Claude Code recreates database work through shell—its shell_dbprobe (probing tables via shell) fires 11.86 times per trial against Tera's 0.37. Every one of those shell probes is one turn Tera skips.
2. Within Tera's tools, each call carries multiple items. table_profile averages 3.28 tables per call—Tera profiles the whole set of interesting tables in one turn. execute_query averages 1.22 SQL statements per call. Claude Code, going through shell, gets one item per invocation. 

The full tool-call profile 

Tools per LLM turn is matched (1.19 vs 1.22). Both agents do about 1.2 tool calls per LLM turn. Tera doesn't beat Claude Code by cramming more tools into one turn—it beats Claude Code by needing fewer turns because each purpose-built call replaces three to five shell probes. 

Everything about Tera's harness—the lean tool surface, the front-loaded discovery, the warehouse push-down—is subordinate to one measurable outcome: half the turns to finish the same job.