Running a Trading Bot on Cron With the Claude Agent SDK
How subscriptions bill, and who pays when the run crashes

You saw someone on X stuffing a Claude Code subscription into GitHub Actions, running an hourly cron to read on-chain whale trades and firing webhooks off to an exchange for order placement — in other words, letting an AI turn "you should buy" into a POST request aimed at an execution service. It looks like $20 a month buys you a 24/7 quant researcher. What nobody told you first: Anthropic's "SDK-only credit" plan was scheduled to take effect on June 15, and it was paused the same day.

This post doesn't compare which AI writes code better, and it doesn't judge your strategy. It gives you three things: how the SDK is billed, what your cron should actually run, and why the split of "Claude decides, webhook carries the signal, TVSBot places the order" is safer than letting Claude hold the API key directly. The API key is the thing that can actually move real money on your exchange — leaving that in an LLM's hands, on a cron that crashes easily, is the problem this post is trying to solve.

That "Agent SDK-only Credit" You Heard About — Paused on the Day It Was Supposed to Ship

Anthropic's support article, as of 2026-08-13, now carries an update pinned to the top. Verbatim:

In plain terms: the "SDK-only credit" that was supposed to arrive on 6/15 — the separate pool that would have carved SDK usage out of your subscription window — is gone. Right now claude, claude -p, and any Python or TypeScript script you wrote with the Agent SDK all draw from the same 5-hour window. Once you burn through it, you wait for the next window. There is no second pool giving you extra life.

If you see something online along the lines of "$20 Pro subscription comes with $20 of SDK credit," that's almost certainly the pre-6/15 version — the author didn't come back to check the follow-up. The numbers listed in the doc before it was paused are still visible on the page, but they aren't in effect. The tail of the support article reads "We're working to update the plan to better support how users build with Claude subscriptions" — no new timeline, no new details. In practice, treat it as if it doesn't exist.

You Can Run the SDK on a Subscription — But That Path Has Two Limits

A subscription can still run the Agent SDK; Anthropic explicitly allows personal use. But two limits are worth pinning down before you commit:

The Overview page is unambiguous: "Unless previously approved, Anthropic does not allow third party developers to offer claude.ai login or rate limits for their products, including agents built on the Claude Agent SDK. Use the API key authentication methods described in the Quickstart instead."

If you're packaging this as a service for others, you use an API key — pay per token you use. The Quickstart page lists five providers — Anthropic Console direct, Amazon Bedrock (env var CLAUDE_CODE_USE_BEDROCK=1), Claude Platform on AWS (CLAUDE_CODE_USE_ANTHROPIC_AWS=1), Google Vertex (CLAUDE_CODE_USE_VERTEX=1), and Microsoft Foundry (CLAUDE_CODE_USE_FOUNDRY=1). None of them is a claude.ai OAuth path.

API Key Pricing: What a Cron Job Roughly Burns Per Day

Running via API key means paying by token. Input tokens are what you send the model (system prompt, conversation history, tool results); output tokens are what the model returns. The two have different rates. Verbatim from the official pricing page as of 2026-08-13:

A single agent that "runs once an hour, reads on-chain whale trades, produces a signal, decides whether to fire an order" on Sonnet 5 works out roughly like this. These are my numbers, not Anthropic's:

This number shifts with system prompt length, tool call count, and how deep the agent thinks. For a real invoice, go to "platform.claude.com/usage" — the SDK's own reported total_cost_usd is a local estimate that can drift from the actual bill (official wording: "client-side estimates, not authoritative billing data"). The order of magnitude here tells you something: if that $20 Pro subscription had been carved into an SDK-only credit, one hourly bot would've eaten it whole — start another quant researcher in the same window and you're out immediately. Paying per token via API key gives you the predictability the subscription window doesn't.

Tokens Burned Before a Crash Are Still Billed

This is the easiest cost to underestimate. Anthropic's Cost Tracking page has a "Track costs on failed conversations" section that spells it out:

Meaning: the agent gets to its 8th tool call, the exchange returns 429 (rate limit), and it dies. The input and output tokens for the previous 7 tool calls are all on you.

There's a nastier version: process crash. The same document notes separately that when the claude subprocess crashes, the final error_during_execution result message may return usage, total_cost_usd, and modelUsage all zeroed out — the wording is "every cost field may be zeroed". But that's only the SDK-side report being broken; Anthropic's billing on the other end still deducts.

Cron Runs the "Decision," Not the "Order" — Why the Two Layers Should Be Split

This is the easiest part of the design to get wrong. When you see the learnwithmeai Hyperliquid copy-trading bot stuffing the whole flow into Claude Code + GitHub Actions, it's natural to want to copy it. But that bot is paper trading — $10,000 in virtual capital on a ledger; when it's wrong the ledger is wrong, and nothing actually gets liquidated. For real money, the two layers have to be split.

For example, TVSBot's execution service does four things before placing an order after a webhook lands. First, verify the webhook_token in the URL (a random token issued per strategy). Second, verify the secret inside the payload, compared with hmac.compare_digest for constant-time comparison. Third, run rate limits (60 per token per minute). Fourth, drop any signal with the same dedup_hash arriving within 60 seconds. You could rewrite all four inside a Claude Agent yourself, but writing them correctly is hard — the idempotency and dedup boundary cases in particular.

How Often Should Your Cron Fire? Back-Solve From Model Call Latency

What actually decides your cadence isn't "how often you want to check" — it's the round-trip latency of the model call, meaning the time from the agent asking a question to receiving the full response. A single Sonnet 5 call carrying 8k input / 2k output plus 3 tool call round-trips lands somewhere in 15–45 seconds in practice, moved by prompt caching hit rate and output token length.

Second-level strategies do not touch the Agent SDK. It's not that it can't — it's that doing so is expensive, because every call is a full LLM inference and what you actually need is sub-100ms reaction. That's the domain of a rule-based execution service. The model helps you think through the rules offline. That's where it earns its keep.

Anthropic's Own Advice for "Long-Running" Points at a Different Product

The decision table on Anthropic's Agent SDK Overview page actively pushes the "long-running or asynchronous agents" use case at a different product:

Managed Agents is currently priced at $0.08 per session-hour active runtime, with tokens billed separately (same pricing page). Anthropic doesn't say the Agent SDK can't run on cron — the Hosting the Agent SDK doc has an explicit "Long-running sessions" section, which is exactly about putting the SDK inside a container for long runs, and even provides a SessionStore so you can persist session files to S3, Redis, or Postgres. It's technically supported, but you carry the infra yourself. If you don't want to manage that, Managed Agents is the official answer, at the cost of $0.08 per hour plus tokens.

If You Insist on Letting Claude Place Orders Directly, Watch These Traps First

• Session storage has to use a durable adapter. The SDK stores sessions to local disk by default; restart the container and they're gone. Anthropic ships S3, Redis, and Postgres as reference implementations — pick one and wire it in.
• Don't fire and forget. For anything as consequential as placing an order, you have to confirm usage.output_tokens is present in the result message before continuing — during a crash that field can be 0, and you also don't know if the order went out or not.
• Bring your own idempotency key. Rerunning the agent with the same prompt doesn't produce an identical sequence of tool calls, so you have to compute a hash yourself (signal timestamp + strategy id + symbol) as the dedup key so the execution service can reject duplicates.
• The kill switch lives on the execution side, not on Claude's side. You have to be able to stop all orders with a single button, and that button cannot depend on Claude checking anything — it could be rate-limited, mid-crash, or hallucinating a very persuasive reason to keep running.
• Rate limit errors are retryable; schema errors are terminal. HTTP 429 gets retried after 5–60 seconds; tool_use failures fail outright, because they're usually a schema mismatch and retrying won't change that.

The Honest Section: We Don't Cover the Claude-Side Bill

This post walks through SDK cost, rate limits, and crash billing as if TVSBot's execution service could absorb them for you — it can't. What we cover is the segment after the webhook lands. Your Claude Agent crashing, your API key getting rate-limited, your subscription burning through its 5-hour window — those all happen before you fire the webhook. The execution service never received the signal, so there's nothing to report back to you.

We also don't publish any SLA around Agent SDK cost — every estimate above is mine, computed against the current official pricing page, and Anthropic can change it any time. TVSBot, as of August 2026, supports the order-placement APIs for Binance, OKX, Bitget, Bybit, Gate.io, BingX, and Hyperliquid — seven venues total — non-custodial (you bring your own API key, stored Fernet-encrypted), with strategy-level dry-run and kill-switch controls. But Anthropic's bill is on you to watch; we don't collect it on your behalf, and we don't pay it for you.

Common Questions