How Much Does It Cost to Run an AI Poker Agent?
An AI poker agent has two different budgets: the money used to run its software and the money exposed at the table. A small poker buy-in does not tell you how much inference, hosting or repeated testing will cost. This guide provides a transparent worksheet for estimating both local and hosted-model running costs, then explains how to reconcile those estimates with actual usage. All sample prices below are hypothetical inputs, not vendor quotes.
What does running an AI poker bot actually cost?
Separate development, operation and table activity. Development includes your time, experiments and any hardware you buy. Operation includes model requests or local compute, a runner, monitoring and storage. Table activity includes results and fees. Putting everything under buy-in makes it difficult to understand what changed when a new agent version becomes more expensive.
A buy-in moves funds into a playing stack. It is not automatically an expense equal to that full amount: some, all or none may remain when the seat closes. Conversely, a tiny buy-in does not cap what you might spend on an unrelated model API. Give each budget its own limit and reporting period.
For a first experiment, estimate cost per attempted decision and per completed hand. Include failed requests and fallback decisions. A provider may bill work even when your runtime discards a late response, so measuring only accepted poker actions can hide real operating spend.
| Category | Example | How to account for it |
|---|---|---|
| Model or local compute | Tokens or electricity | Operating expense |
| Runner and logs | Hosting and storage | Allocated operating expense |
| Development | Coding time or training runs | Separate project budget |
| Buy-in | Funds seated at a table | Capital allocated, not automatically lost |
| Poker outcome and rake | Settled changes in stack | Use authoritative results; avoid double-counting fees |
Start with decisions, not hands alone
A thousand hands does not imply a thousand model calls. Your agent may face several decisions in one hand, fold preflop in another, or ask a model to summarize history after the hand. A second request for self-review also counts. Define the expected number of calls explicitly before comparing model prices.
Our illustrative workload uses 1,000 hands, 2.5 decisions per hand and a 1.1 request multiplier for extra calls. That gives 2,750 billable calls. Each call averages 2,000 input tokens and 300 output tokens. These are made-up planning assumptions; replace them with measurements from your own fixtures and completed runs.
Token usage changes with observation length, tokenizer, repeated instructions and provider accounting. Some services price cached inputs or reasoning tokens differently. The simplified worksheet treats all input and output tokens uniformly. Use the provider’s current pricing and billed usage categories when reconciling a real invoice.
A worked hosted-model cost worksheet
Suppose input tokens cost $1 per million and output tokens cost $5 per million. These are hypothetical USD rates chosen for easy arithmetic, not prices for any named model. The workload produces 5.5 million input tokens and 825,000 output tokens: $5.50 for input plus $4.125 for output, or $9.625 before rounding.
Add a hypothetical $5 allocation for hosting and $0.50 for logs during the same period. Total operating cost becomes $15.125, displayed as $15.13. Dividing the unrounded total by 1,000 gives about $0.0151 per hand. This excludes poker results, rake not already reflected in those results, transfers, tax, development time and training.
The downloadable worksheet below is a dependency-free JavaScript file. It prints the calculation without contacting a provider. Edit the input object to use your own assumptions. Keeping the file alongside a test result makes the estimate reproducible, including the rates and workload you chose that day.
| Input or calculation | Value |
|---|---|
| Hands × decisions per hand × request multiplier | 1,000 × 2.5 × 1.1 = 2,750 calls |
| Input tokens × illustrative input rate | 5,500,000 × $1 / million = $5.50 |
| Output tokens × illustrative output rate | 825,000 × $5 / million = $4.125 |
| Model subtotal | $9.625 |
| Hosting plus logs | $5.50 |
| Total operating cost | $15.125, or $15.13 rounded |
node ai-poker-cost-worksheet-v1.mjsIs running a local poker AI model free?
A local model can remove a per-request provider bill, but the machine still consumes electricity and has a purchase or rental cost. Our local worksheet example assumes a measured average draw of 100 watts over 20 hours and a hypothetical electricity price of $0.25 per kilowatt-hour. The arithmetic is 0.1 kW × 20 h × $0.25 = $0.50.
That is an electricity-only example, not the full cost of a computer. Measure wall power if you want a whole-system figure; a component’s rated power is not necessarily its actual average draw. If the machine would already be running, distinguish incremental electricity from allocated total electricity. Add hardware depreciation or rental separately and state how you allocate it.
The current starter offers a local Ollama adapter for experimentation. Model loading, context length and hardware affect whether it finishes within the decision budget. A locally hosted model that regularly falls back may have a low cash bill while failing to perform the work you intended. Check the decision source in the logs before celebrating the cost.
The hidden cost of a slow AI poker agent
Cost and latency need to be measured together. MaxxQuant Poker’s current normal action clock is 25 seconds. The starter reserves a much shorter model budget so it has time to refresh state and submit. An inference that completes after the action is no longer useful may still consume compute or incur a provider charge.
Track p50 and p95 decision latency, cold-start behavior and the proportion of decisions using fallback. The p95 is the duration that 95% of measured requests finish within; a fast average can hide a troublesome slow tail. Measure end-to-end time as well as model time, including network requests and validation.
More retries are not always a solution. The runtime must respect rate limits and recover unresolved commands without duplicating them. Repeatedly asking a model to rethink a move can both raise the bill and consume the remaining clock. Compare policies on the same deadline and workload before deciding that a more expensive model is better value.
Where buy-ins, rake and poker results belong
MaxxQuant Poker currently offers fixed buy-ins of 0.004, 0.005 and 0.01 USDC. Those are table amounts, not a promise about total project cost. Verify the current buy-in shown when creating the key. The poker API uses eight internal ledger decimals, so 500000 internal units represents 0.005 USDC; do not confuse these values with on-chain token transfer units.
Current standard table rake is 2.5% of contested pot amounts, capped at one big blind, with no flop, no rake. Uncalled returns are separate. Use the actual settled hand records for accounting instead of multiplying your buy-in by the rake percentage. Pot structure, the cap and whether a flop occurs all affect the fee.
If your reported poker result already includes deducted rake, subtracting rake again overstates the expense. Keep gross transfers, ending stack, settled net result and operating costs in separate columns. A positive poker result can coexist with a negative result after compute costs, and a software test can still be useful without generating a positive return.
What happens when memory or reasoning gets longer?
In the sample workload, doubling input context from 2,000 to 4,000 tokens adds $5.50 to the model subtotal at the hypothetical input rate. Doubling output from 300 to 600 tokens adds $4.125. Increasing the request multiplier from 1.1 to 1.3 increases calls from 2,750 to 3,250. These simple changes show which assumptions drive the estimate.
Longer memory can help an agent only if it contains relevant evidence and improves the measured task. Sending the full history on every decision grows context repeatedly. A concise, auditable summary may reduce cost, but it can also discard useful details. Compare both on held-out decisions instead of optimizing token count in isolation.
Use three scenarios: a short fixture run, your expected workload and a stress case with longer hands and extra requests. Do not turn the estimate into a forecast of profit. It is a capacity-planning tool that tells you how much an experiment might consume under stated assumptions.
The first measurement to collect
Run the offline starter, then record ten or more representative decisions with your chosen policy and environment. Capture input size, output size, elapsed time, decision source and any billed usage. This small sample can expose a configuration mistake; it is not enough to establish the full distribution of production costs or poker outcomes.
Next, collect a broader sample across positions, table sizes and hand lengths. Reconcile provider usage against your own logs, including failed or late calls. Date the price inputs and retain the worksheet with the policy version. For local inference, record hardware, model version, power assumptions and cold versus warm runs.
You will then have a useful answer to what does my AI poker agent cost: a measured workload and an explicit accounting method. That is a stronger basis for the next experiment than comparing buy-ins or choosing a model because its headline token price looks small.