Not subscribed? Sign up to get it in your inbox every week.
PRESENTED BY OMNISEND.COM
Your email banners shouldn't need a download folder
Omnisend now connects straight to Canva. Drop your designs into one Canva folder and they sync to your Omnisend image library on their own, every 12 hours or whenever you hit sync. No exporting, no re-uploading, and updated designs re-sync automatically. And if you're on another platform, Omnisend handles the migration for you, free, in 5 days.
Use code THEBOTTLENECK for 30% off your first 3 months.
Every AI bill has two dials
Did you hear the one about Uber burning through its entire 2026 AI budget by April?
Uber rolled out Claude Code to its engineers in December; by March, 84% of Uber’s engineers were using it. At an average of $150 to $250 per engineer per month (and much more for high-volume users—$500 to $2000), things got a bit out of hand.
Their CTO Praveen Neppalli Naga told The Information they’re back to the drawing board, and as of June, Uber’s capping Claude spend at $1500 per engineer per month.
Uber didn’t do anything wrong here, and most of the finance teams I’ve talked to are a couple of quarters behind them.
The good news is the math is simple. You have two dials for how much AI costs you: how much you’re paying per token, and how many tokens you’re spending.
Two YC S26 startups recently caught my eye, and I figured I’d pull them out as examples of each dial.
Dial 1: pay less per token
It’s obvious you can pay less per token by using open weight models. As of this week, they had a median 78% lower blended API price on BenchLM (only $0.43 per million tokens versus $1.93 for proprietary models), and the best of them lagged the frontier by “around four months on average in 2025,” according to Epoch AI.
The bigger savings come from realizing that a lot of AI spend comes from running the same narrow task over and over on a model that’s much more powerful than you need.
Orchestra lets you point your OpenAI or Anthropic calls at their gateway (one URL change), records all the traffic you send them in production, turns it into evals, and trains a small model for each task you send through that meets your bar for quality/cost/latency.
They have a couple of interesting case studies:
They trained a 30B open model to label 39,962 YouTube comments for $2.82 (versus $12.48 on Sonnet or $139.63 on Opus), with 99.5% agreement with Sonnet’s labels.
They fine-tuned an 8B model to run 30 workflows for their business at ~6x lower cost and 5x faster than Sonnet 4.6.
It’s a trade-off, and you give up a little quality for a lot of cost.
Use dial 1 for classification, extraction, tagging, routing, scoring, and other narrow tasks you run hundreds of times a day. Note that it’s not an option unless you have an eval to run.
Dial 2: spend fewer tokens
This dial is particularly important for agents because agents spend all their money on reads.
Every turn of the loop re-sends all the previous conversation, files, tool calls, instructions, etc., so the cost of generating the output is a rounding error.
Some providers (Anthropic and OpenAI) are enabling prompt caching, which charges roughly 0.1x the normal token prices if the start of your prompt was seen recently. You can get this benefit for free as long as you keep static parts of your prompt (system instructions, documents you’re querying against, etc) at the front of your prompt and in the same order. I’m surprised how many teams I talk to aren’t taking advantage of this.
Agents “rediscovering” context that is already known in your organization. When an agent takes on a new task, it needs to spend a decent number of turns figuring out context relevant to that task - what code is relevant, what was already tried in the past, why the obvious solution won’t work, etc.
Glen gives your team’s agents a shared memory, consisting of past agent sessions, Slack threads, PRs, tickets, docs, and more. Glen adds a bunch of tokens to the start of your agent sessions, so that your agents have all of the context they need to solve a problem from the start.
To test it, the founder replayed 100 merged pull requests in one workspace, with and without Glen's memory, five runs each. With memory, agents used 29% fewer tokens and finished 21% faster, with quality at parity or better. In one example, agents with the team's context chose the broader, correct fix in 4 of 5 runs, while agents without it settled for a narrow patch in 9 of 10.
Open ended workloads - coding, research, analysis, etc. that you still want to run on frontier models.
Which dial should you turn first?
Break down your LLM costs by workload. Right now you probably just have one total number. Tag your workloads so that you can see how much you’re spending on support ticket triage, coding agents, document extraction, running an internal chatbot, etc.
Turn on caching, and make sure you’re getting cache hits.
Reduce rediscovery in your agent workloads, either with a tool like Glen or with better prompt instructions/docs.
Build an eval, distill your model, or switch to a smaller model for your high volume narrow workloads.
Keep using your favorite frontier model for your harder, more open-ended workloads.
I feel like a lot of companies are spending way too much time debating over which frontier model to use (which honestly has the smallest impact) and not enough time thinking about the above.
What can you do on Monday to reduce your AI bill?
Pull up your AI bill from last month, and break it down into your 3 biggest workloads. For each of those workloads, ask yourself: is this a narrow task with a checkable answer, or is it a more open ended task that requires good judgment?
From there, you know which dial to turn. If you have trouble breaking down your workloads, start there - you can’t turn the right dial if you don’t know which one it is.
Till next time,
Chris
