Stop chasing fads. Operate Claude like a startup founder.

A developer running an AI-native startup shares five ways to operate Claude Code like a business, focusing on cost tracking, prompt caching, and telemetry. The post details using tools like ccusage and OpenTelemetry to monitor spend and edit acceptance rates, and explains how to optimize prompt caching to cut costs by up to 90%. The developer emphasizes that operational discipline, not chasing trends, is key to building a trustworthy AI coding setup.

I am running an AI-native startup. Early on though, I would spend so much time staying ahead of every new AI hot take that I lost focus on what I needed to do to move the company forward. I didn't need a hundred skills, fifty MCP servers, or Ralph Wiggum loops sending my API bill to the moon. I needed answers to plain questions. What is this model costing me? Is it writing code I keep? Is that tip I saw on X helping, or just making me feel busy? Those are operating questions. Using Claude is the easy part. You send a prompt, it writes code, you ship. Operating is what turns prompts into something you can trust at speed. That isn't about model quality. It's about what you build around the model. What I didn't realize is that everything I needed, Claude had already shipped. There are three layers Claude provides, depending on the task: The skill is knowing which of the three to reach for, and when. Here are five ways I used these three layers to build an AI-coding configuration I trust. Beyond the monthly subscription and the API line item, do you know the numbers behind the numbers? They are sitting on your laptop. Claude Code writes a JSONL log of every session to disk. A free tool called ccusage https://github.com/ryoppippi/ccusage reads those logs and reconstructs your spend and cache-hit rate across your entire history instantly: npx ccusage@latest daily There's a number that matters even more, whether the model's edits are getting accepted or thrown away. You won't find that one in the log. That answer comes from Claude Code's OpenTelemetry export https://docs.claude.com/en/docs/claude-code/monitoring-usage . You turn it on in settings and point it at a dashboard: // .claude/settings.json { "env": { "CLAUDE CODE ENABLE TELEMETRY": "1", "OTEL METRICS EXPORTER": "otlp" } } The accept/reject rate is the closest thing you have to knowing whether the model's output is worth keeping. A high reject rate means you're paying to generate edits you then delete. There was no need to write code or make API calls. All it required was simple configuration. That's the first layer, extending Claude Code. Prompt caching https://docs.claude.com/en/docs/build-with-claude/prompt-caching is your biggest single cost lever. A cached read costs roughly 10% of the normal input price. A stable prefix you reuse on every call, like your system prompt, CLAUDE.md, or tool definitions, should be almost free after the first call. Anthropic's caching runs on an explicit cache control marker, and the savings on a long stable prefix are around 90%. The issue is that caching matches on an exact prefix. If anything at the top of your context changes between calls, like a timestamp, a session ID, or reordered tool definitions, every byte downstream of the change is a cache miss, meaning you pay full write price. One volatile token at the top invalidates everything under it, and it's the most common reason a cache-hit rate sits far lower than it should. You can see it working by reading the API response yourself. This is your first direct call to the Messages API, the Call layer, firing the same request twice to print the cache fields: python // cache-probe.ts: a direct Messages API request, twice import Anthropic from "@anthropic-ai/sdk"; import { readFileSync } from "node:fs"; const client = new Anthropic ; // reads ANTHROPIC API KEY const stablePrefix = readFileSync "sample-context.md", "utf8" ; // a big, stable body async function call label: string { const res = await client.messages.create { model: "claude-haiku-4-5", max tokens: 128, system: { type: "text", text: stablePrefix, cache control: { type: "ephemeral", ttl: "1h" }, // the lever } , messages: { role: "user", content: "One-line summary." } , } ; console.log label, { write: res.usage.cache creation input tokens, // tokens written to cache read: res.usage.cache read input tokens, // tokens served from cache } ; } await call "cold" ; // write 0, read = 0 - you paid to fill the cache await call "warm" ; // write = 0, read 0 - served from cache, ~90% cheaper The cold call shows a write and no read. The warm call flips, with no write and a read served back at a tenth of the price. If both reads come back zero, your prefix is either below the cache minimum about 4,096 tokens for Haiku or it's changing between calls, which is the bug you're searching for. The usage object tells you exactly what got cached. One detail that's easy to miss is that the effective cache TTL defaults to five minutes. Pause to read a diff for ten minutes, and the cache can expire and re-warm at full write price on your next call. Setting ttl: "1h" on a slow interactive loop is worth it. The five-minute default is tuned for an agent running flat out, not an engineer thinking through a problem. In July 2025, an AI agent at Replit deleted a production database https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/ during a code freeze. A worse version went viral in 2026 when a founder watched an agent wipe both the production database and its backups, even though the project had explicit written rules telling it not to. The lesson most people took was "the AI did it." The actual lesson is that the safety rule lived in a config file and was treated like a prompt. The model can reason its way around it or just lose the thread once the context window fills. If a rule must stick, it has to run as code. Claude Code gives you that through hooks https://docs.claude.com/en/docs/claude-code/hooks . A hook is a deterministic check that runs before a tool call and can block it outright, with no model judgment in the loop. Here's a PreToolUse hook that inspects every shell command for a destructive operation against anything related to production, and blocks it unless it sees a typed confirmation: js // a PreToolUse hook: deterministic, runs before the tool, can refuse const command = toolInput.command ?? ""; const destructive = /\b drop\s+table|truncate|rm\s+-rf|reset-db \b/i.test command ; const looksProd = / prod|production /i.test command ; if destructive && looksProd { return { decision: "block", reason: "Destructive op against a production target. Requires typed confirmation.", }; } You can use the same method to guard against hallucinated packages. Models will confidently recommend a package that doesn't exist. Attackers register those exact names and wait, an exploit called slopsquatting. A second hook checks that an install target actually exists, and clears a minimum age and download count, before it runs. The key point is that the check runs in code, where the model can't ignore it. One warning, though. Once a hook is scanning every command for trigger words, it will block your own commands too, including a harmless echo that happens to mention one. When you need a trigger word in a command, pipe it in from a text file so it never appears in the command line the hook scans. This is another example of extending Claude Code. The key pattern to follow is that anything that has to be reliable belongs in a hook, never left to a model's judgment. The top frustration with AI coding tools isn't the model failing outright. It's output that's almost right but not quite. It is the most common complaint by a wide margin, named by 66% of developers in the Stack Overflow 2025 survey https://survey.stackoverflow.co/2025/ai . Almost-right is worse than plainly wrong. Wrong gets caught immediately. Almost-right looks shippable, passes review, and fails many weeks later because of an edge case that was never checked. A normal CI gate won't help. Lint, types, and happy-path tests all go green on code that's subtly off. Take this simple function: // lib/stats.ts export function averageEventsPerMember members: Member , events: Event : number { return events.length / members.length; // looks fine. returns NaN when members is empty. } The happy-path test passes. CI is green. The bug only appears when the members list is empty, and then a user sees NaN on the screen. Two simple tools catch most of this, and neither needs a full agent. The first is a scope check, the Call layer doing one small job. After a change, a single stateless API call scores the diff for whether it stayed inside the task you asked for: python // scope-check.ts: a disposable scorer on a single API call import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic ; export async function scopeScore taskSpec: string, diff: string { const res = await client.messages.create { model: "claude-haiku-4-5", // fast and the right tool for a bounded job max tokens: 200, system: "You score code diffs for scope creep. Reply ONLY with JSON: " + '{"in scope": boolean, "out of scope": string , "risk": "low"|"med"|"high"}.', messages: { role: "user", content: TASK:\n${taskSpec}\n\nDIFF:\n${diff} } , } ; const raw = res.content.find b = b.type === "text" ?.text ?? "{}"; const clean = raw.replace / {% endraw %} json| {% raw %} /g, "" .trim ; // strip fences the model adds try { return JSON.parse clean ; } catch { return { in scope: true, out of scope: , risk: "low" }; } } That call costs a fraction of a cent and catches the model editing three files when you asked it to touch one. The fence-stripping and the try/catch matter. Models often wrap JSON in markdown, which crashes a raw parse in production, so you strip the fences and catch the failure. The second is a verifier subagent. After a change, it writes adversarial tests aimed at exactly what you changed and runs them before you do, so almost-right gets caught by a grader you built. That is the Extend layer again, a subagent you configure once and reuse. I wrote about the checks I run in an earlier post, Four checks I built to trust them https://dev.to/triberoi/i-use-ai-agents-to-code-four-checks-i-built-to-trust-them-2cl4 . Every time you edit your CLAUDE.md, swap a model, or restructure your context, you're running an experiment, but no one treats it like one. You make the change and you keep it or revert it based on a hunch. ETH Zurich evaluated LLM-generated context files https://arxiv.org/abs/2602.11988 and found they decreased task success by a few percent while raising cost by more than 20%. Context the model wrote for itself was making the agent worse and more expensive. The only fix is to measure against your own tasks. You build a small harness that runs your setup headless against a fixed set of tasks, under two configurations, and compares them. This is the third layer, where you embed Claude as an agent inside your own code, through the Agent SDK https://docs.claude.com/en/api/agent-sdk/overview , which makes implementing the headless part simple: js // harness.ts: drive headless Claude agents from your own code import { query } from "@anthropic-ai/claude-agent-sdk"; async function runTask task: GoldenTask, configDir: string { let cost = 0; for await const msg of query { prompt: task.prompt, options: { cwd: task.repoPath, settingSources: configDir }, // config A or config B } { if msg.type === "result" cost = msg.total cost usd ?? 0; } const passed = await task.check task.repoPath ; return { passed, cost }; } // Run the task set under config A and config B, several times each, // then compare pass-rate and cost. When I ran this on a bloated config against a lean one, the heavy one stuffed with every "best practice" I'd collected, the verdict was that it cost 1.26 times as much for the same pass rate. Based on vibes, I would have kept it, but the numbers told me otherwise. One caveat is that agentic eval results drift with API latency by time of day, and a single A-versus-B run can hand you a difference that's pure noise. You have to run the comparison several times to give this eval real rigor. None of this is hard. Each part is less than an hour of work. Almost all of it ships with Claude, the telemetry, the cache controls, the hooks, the disposable API calls, and the headless SDK. These five ideas run across the three layers Claude already provides. You extend it with hooks and telemetry. You call it for simple, bounded jobs. You embed it as an agent when you want it to run on its own. Operating well is knowing which of the three a task needs. | Practice | Layer | |---|---| | Telemetry & accept-rate | Extend | | Prompt caching probe | Call | | Hooks as guardrails | Extend | | Scope check + verifier | Call + Extend | | A/B eval harness | Embed | Small teams usually skip all of this as it feels tedious. Nothing forces the issue until the bill spikes or a database disappears. The hot takes will keep coming. Implementing these now is what lets you ignore them and operate Claude reliably so you can focus on shipping product. I built all five into a workshop that walks you through writing each tool yourself, against a sample codebase, one part at a time. It's open source on GitHub, and you can run it solo this weekend or with your team. Start the Claude Founders Workshop. https://github.com/startupmark/claude-founders-workshop Ask a founder what their last feature cost in tokens, or whether the model's output is worth keeping, and most can't answer. Not for lack of caring. Nothing on their screen shows them, so the question never gets asked. That gap is the whole point of this workshop. The Stack Overflow 2025 survey found that the top frustration with AI coding tools isn't outright failure, it's output that's "almost right but not quite" 66% of developers , the kind that looks shippable until it breaks on an edge case. Many teams are using Claude. Very few are operating it: watching the spend, capping the blast radius, catching the near-misses, and proving a config change actually helped instead of guessing. This repo is the reference build for the Claude Founders Workshop , a hands-on, five-part series that takes a small team from using Claude Code to operating it. acme-community is the… I'll go deeper on each lesson in the posts that follow, the caching mechanics, the hook patterns, and the eval harness. If you run it and something breaks, or you find it super valuable, please reach out and let me know in the comments.