What's new in tl v0.8.1: fewer wasted credits and gentler error messages for raw data queries

A new release of the tl CLI is out today: v0.8.1. It’s a follow-on to the big v0.8.0 rename, focused on the moments where your AI agent used to burn credits or hit a wall for no good reason — repeated queries, typos on freshly renamed fields, stale help examples. All of it is picked up automatically the next time you (or your agent) run tl update, whether you’re on Claude Code, Gemini, Codex, or OpenCode.

Stop paying twice for the same answer

If you’ve ever watched an agent grind through a research session, you may have noticed it occasionally re-runs the same data query — sometimes two or three times in the space of a minute — just to double-check itself. That’s fine when the query is free. It’s not fine when every run is billed and the answer is almost certainly identical.

As of v0.8.1, when your agent (or you) re-runs the exact same tl db pg, tl db fb, or tl db es query three or more times inside a five-minute window, the CLI now flags it on the way out — a friendly warning on the error stream that says “you’ve already run this query recently, and each run costs credits.” The query still executes; nothing is blocked. It’s a nudge, not a gate.

The practical effect: your agent notices the warning, remembers the earlier answer instead of re-fetching it, and moves on to the next question. Over a long analytical session, that’s real credits back in your balance.

In agent-speak, the kind of thing that used to happen quietly in the background now happens out loud:

• “I ran that view-count query a minute ago — reusing the last result instead of re-fetching.”
• “Skipping the second identical count() — I already have it above.”*
• “You’ve asked me for this brand’s repeat partners three times today; here’s the cached shortlist from earlier.”

If you’re running a batch job on purpose (say, refreshing the same query on a schedule and want fresh numbers each time), suppress the warning with --no-repeat-warning on the command, or set TL_NO_REPEAT_WARNING=1 in the environment for the whole run.

When a typo hits a renamed field, the error now points at the fix

Last week’s v0.8.0 release renamed several fields across the CLI so they’d read like the thing they actually represent — subscribers instead of the old count column, scheduled_date instead of send_date, advertiser for the brand-side party on a sponsorship. Great in the medium term. In the short term, your agent occasionally still reaches for a name from the old vocabulary and gets a database error back.

v0.8.1 catches that moment. When a raw data query references a field or table that doesn’t exist, the error message now:

• Maps the old name to the new one (“looks like you meant subscribers — the previous reach field was renamed in v0.8.0”), so your agent can retry with the right vocabulary on the very next attempt.
• Explains where the field lives when the answer is on a related table, so a join question doesn’t turn into a guessing game.
• Points at the exact next command to run — usually tl schema pg <table> — for a live, always-current cheat-sheet.

In agent-speak, sessions that would have stalled now recover on their own:

• “That column was renamed — retrying with subscribers instead of reach.”
• “That field lives on the channels table, not sponsorships — joining and re-running.”
• “Let me pull tl schema pg sponsorships to double-check the current field names.”

None of this is new capability — it’s the CLI meeting your agent halfway when the vocabulary drifts. If you’ve noticed your agent occasionally getting stuck on a “field does not exist” loop over the last few days, this release is the fix.

Fresher help examples and a per-table “common traps” block

Small but meaningful polish while we were in there:

• tl db pg --help examples have been refreshed to the current schema names. If your agent (or you) copies an example verbatim to bootstrap a query, it’ll be reaching for the right vocabulary from the first attempt.
• tl schema pg <table> now surfaces a per-table common traps block — a short, curated list of gotchas for that specific table: which fields were renamed recently, where a related field actually lives, which columns are safe to sort on. Think of it as the “here be dragons” section, right where your agent goes to look up the shape of a table anyway.

Put together, the schema reference your agent leans on becomes a lot more self-serving — fewer round-trips, fewer wrong turns, fewer moments where you have to step in and translate.

Updating

Run tl update to pick all of this up — or just keep working, and the auto-updater will catch you up on your next command. tl changelog shows the running log of what’s landed.

Happy hunting.