Estimate Monthly AI Spend for a Two-Person Startup

Fare watch EN2026-10-25

A two-person startup can use AI for coding, customer support, and product features before either founder knows the monthly bill. To estimate that bill, open a spreadsheet and separate the work into measurable units. This walkthrough produces a working budget you can update after your first week of usage.

1. Separate development work from product traffic

Create two rows: internal development and customer-facing requests. Development includes coding assistants, debugging, and experiments. Product traffic includes every AI request your application makes for users.

Add columns for monthly units, input tokens per unit, output tokens per unit, input price, output price, and estimated cost. Keep any fixed AI subscriptions in a separate row so your total includes both subscriptions and usage charges.

2. Count a realistic month of activity

Start with a normal working month, not your busiest imaginable week. Suppose both founders use a coding assistant for 12 sessions per working day, across 22 days:

Development: 2 people × 12 sessions × 22 days = 528 sessions.
Product: 100 active users × 30 requests per month = 3,000 requests.

Define a session consistently: one bounded task, such as fixing a failing test. A session can contain several model calls. Its token estimate must cover all those calls, including tool follow-ups. For product traffic, count backend calls separately if one user action triggers multiple requests.

3. Measure tokens from representative tasks

Run five to ten ordinary coding tasks and several representative product requests. Record the input and output usage reported by your provider or client logs. Use the average for your first estimate, and note unusually large tasks separately.

For this worked example, assume each development session totals 18,000 input tokens and 3,000 output tokens. Each product request uses 2,000 input tokens and 500 output tokens. These are planning assumptions, not typical usage guarantees.

Input includes instructions, conversation history, retrieved documents, and tool results sent back to the model. Repeated context can make a short conversation surprisingly expensive.

4. Apply separate input and output prices

Copy current prices for your chosen model and billing route into the sheet. Record the date and currency. For illustration only, use $3 per million input tokens and $15 per million output tokens for development, and $0.50 input and $2 output for product requests. These are hypothetical rates, not RelayVano prices.

Calculate each row as: input tokens ÷ 1,000,000 × input rate, plus output tokens ÷ 1,000,000 × output rate.

Development: 9.504 million input tokens and 1.584 million output tokens cost $52.27.
Product: 6 million input tokens and 1.5 million output tokens cost $6.00.
Estimated monthly usage: $58.27 before other charges.

5. Account for caching, retries, and extra tools

Check whether your selected route bills cached input, cache writes, reasoning tokens, search, or other tools separately. Apply the relevant published rates where those categories appear. Avoid counting cached tokens twice if your usage report already separates them.

Inspect retries and agent loops, too. A failed application request may still involve billable model work. If your measured session totals already include retries, leave them included rather than adding the same allowance again. Add applicable taxes, currency conversion fees, and fixed subscriptions separately.

6. Set a budget with room for uncertainty

Add a 25% planning buffer to the $58.27 usage estimate: $14.57, giving $72.84. Round that to a $75 monthly usage budget, then add your separate fixed costs and fees. The buffer is an assumption to revisit once you have real data.

For a shared pay-as-you-go route, consider RelayVano, which works with Claude Code, Codex, Gemini CLI, and OpenAI-compatible SDKs through https://api.relayvano.com. Sign up to test your actual workflows and replace the sample rates with current pricing.

7. Recalculate after one working week

Compare actual spending with your spreadsheet every Friday. Project development usage across working days and product usage across calendar days. Investigate changes in cost per session or request before assuming traffic alone explains the increase. Update the two workload rows, keep the assumptions dated, and set spending alerts wherever your billing tools support them.