Why dollar-based order sizing is harder than it looks with real money

Dollar-based order sizing appears to remove complexity by letting an agent specify a simple dollar amount instead of contract units, but real money trading exposes gaps between that target and the actual position created. Leverage, lot rounding, slippage, and venue-specific margin rules mean the requested dollar value is an approximation, not a guaranteed exposure. Felix normalizes the conversion across stocks, crypto, perps, options, and prediction markets, yet the owner must still understand what the number represents and design limits accordingly.

Why does dollar-based sizing feel simple but fail under real money?

Most traders learn to think in shares, contracts, or coin amounts. When they switch to an agent that speaks in plain dollars, the abstraction feels intuitive. You tell the agent to buy five hundred dollars of an asset, and you expect five hundred dollars of exposure. That intuition works reasonably well in simple spot markets, but it breaks quickly when the same instruction routes to a perps venue, an options chain, or a prediction market with binary payoffs.

The API converts your dollar target into the native units the venue requires. It handles shares for a stock broker, lots for a perps venue, or contract counts for an options venue. What it cannot do is rewrite the underlying mechanics of those markets. A five hundred dollar order on a stock broker is roughly five hundred dollars of equity value minus fees. The same five hundred dollar order on a perps venue might be five hundred dollars of margin backing a position many times larger. On an options venue, five hundred dollars is premium, and the notional exposure is determined by the underlying price, delta, and contract multiplier. On a prediction market, five hundred dollars might buy a large bundle of shares that pay out zero or one, meaning your risk is bounded but your payoff profile is nonlinear.

Traders also forget that venues enforce minimum lot sizes and tick increments. The API rounds your dollar amount to the nearest tradable unit. If the rounding is coarse, the filled notional can diverge from the target by a meaningful percentage, especially on high-priced assets or markets with large minimum lots. If you treat the dollar value as a precise scientific measurement, you will be surprised by the variance.

How do leverage and contract size distort a plain dollar amount?

This is where the most expensive misunderstandings happen. Leverage turns a plain dollar order into a leveraged bet without changing the number you typed.

Imagine you configure an agent with a scoped key and a five hundred dollar budget cap for a perps venue. You believe the agent is risking five hundred dollars. But if the venue account is set to twenty times leverage, the agent is actually controlling ten thousand dollars of notional exposure. A five percent move in the wrong direction absorbs the entire five hundred dollars of margin. The owner intended a small position, but the venue saw a large one.

The API accepts the order in dollars and translates it to the correct contract size, yet it does not control the leverage setting in the owner’s wallet. Because Felix is non-custodial, the funds sit in a wallet you control at the venue, and the venue’s own leverage or margin mode applies. The agent cannot withdraw funds, but it can open positions that are larger than your risk appetite if the scope and limits are not aligned with the leverage available.

Options create a similar distortion. A five hundred dollar premium on a far out-of-the-money option might control fifty thousand dollars of underlying notional. The delta might be ten percent, so the initial risk is smaller, but if the underlying moves, the delta changes and the economic exposure grows. The dollar amount you sent was only the premium. The API normalized the order entry, but the risk is defined by the Greeks, not by the five hundred dollar input.

Prediction markets have their own wrinkle. If you buy five hundred dollars of shares at fifty cents, you own one thousand shares. If the event resolves to one, you receive one thousand dollars. If it resolves to zero, you lose the five hundred dollars. The dollar amount is both the cost and the maximum risk, but the expected value depends on the price, which is not the same as the notional.

To avoid this, you should treat dollar caps as spend limits, not risk limits, and size them accordingly. A perps key should have a far smaller cap than a stock key. You can read more about aligning limits with market mechanics in how to limit risk when AI agents trade through MCP tools and a single API.

Why do slippage and partial fills break the one-to-one assumption?

Paper trading and backtesting often assume you can buy exactly five hundred dollars of an asset at the current price. Live markets do not work that way.

When an agent sends a market order sized in dollars, the API converts that target into units and submits it to the venue. If the order book is thin, the fill walks through multiple price levels. The first few units fill at the ask, the next few at a higher ask, and so on. The average fill price is worse than the mark price at the time of the request. The agent receives fewer units than the idealized calculation suggested, and the effective dollar exposure is different.

Partial fills add another layer. A five hundred dollar order might only fill two hundred dollars because liquidity is exhausted at the current levels. The remaining three hundred dollars sits unfilled or is cancelled. If the agent does not inspect the fill report and simply sends another five hundred dollar order, the total intended exposure becomes seven hundred dollars, or more if the second order also slips.

This is why observability matters. The owner must review not just what the agent intended, but what the venue actually filled. Felix returns realized fill values, yet the agent logic must decide whether to retry, adjust, or stop. Prompts should instruct the agent to read the fill summary and compare it against the remaining budget before placing follow-up orders. For a guide on reading those logs, see how to evaluate trading agent logs.

Slippage is especially pronounced in prediction markets and newer crypto pairs where the spread is wide. A five hundred dollar order in a thin prediction market can move the price itself, meaning the agent pays a premium for the entire position. The dollar target is still five hundred, but the expected return of the position drops because the entry price is worse.

What changes between paper trading and live order sizing?

Paper trading is a useful sandbox. It validates that the agent can interpret signals, construct orders, and stay within budget caps. But it cannot simulate real liquidity or real margin constraints.

In paper mode, the API simulates fills against the current price. There is no slippage, no partial fill due to empty books, and no margin rejection. When you switch to live trading, the same five hundred dollar order can behave differently. A stock broker might reject the order because your buying power is tied up by other holdings. A perps venue might reject it because your margin is insufficient under isolated margin mode, even though the scoped key allows five hundred dollars. An options venue might reject it because the contract no longer meets margin requirements after a price spike.

Live trading also introduces funding rates and carry costs. A five hundred dollar notional perps position sounds small, but if the funding rate is high, the position bleeds value over hours. The dollar size of the order does not capture the cost of holding it. The API records the entry, but the venue charges the carrying cost directly against your wallet.

Because of these differences, paper trading should be treated as a logic test, not a sizing test. You should run a small live allocation with tight hard limits to observe how the venue fills, what margin it consumes, and how quickly funding or fees erode the position. Only after observing real behavior should you scale the dollar size. We discuss the transition in more detail in manual backtesting versus AI agent trading.

How should hard limits be set to match actual intent?

The owner needs to decide whether the dollar limit is a spend ceiling, a notional boundary, or a maximum loss tolerance. Felix treats it as a spend ceiling for order entry, but the owner is responsible for mapping that to actual risk.

First, use scoped keys to separate market types. A key for a stock broker might carry a two thousand dollar cap because spot equity is unlevered. A key for a perps venue might carry a two hundred dollar cap because leverage multiplies the notional. A key for options might carry an even smaller cap because premium is only one component of the total exposure.

Second, set position limits in addition to budget caps. A budget cap of five hundred dollars per order prevents a single large order, but an agent could send ten orders in sequence and build a five thousand dollar position. Position limits tell the API to block new orders once the open exposure reaches a threshold.

Third, define drawdown exits and a panic switch. If the market moves against the agent, the owner can flatten the position and revoke the key instantly. This is a safety net, not a trading strategy.

Fourth, build your signal pipeline to respect these limits before the agent even decides to trade. If the pipeline knows the hard cap is five hundred dollars, it should not generate signals that require more. You can learn more about pipeline design in how to build a market data pipeline that respects agent hard limits.

Finally, write prompts that reflect the mechanical reality. Instead of telling the agent to risk five hundred dollars on a perps trade, you might tell it to target a specific notional exposure, or to check the leverage setting and reduce the order accordingly. The API takes a dollar amount, but the agent can calculate a smaller dollar amount if it knows the leverage is high.

What does the API normalize and what is still the owner's responsibility?

Felix abstracts the unit conversion. You send a dollar amount, and the API translates it into shares, crypto units, perps contracts, options contracts, or prediction market shares. It rounds to the venue’s minimum lot size and enforces the tick increment. It reports back the fill in both native units and realized dollars.

What the API does not do is normalize risk. It does not know your leverage setting. It does not know your cross-margin collateral usage at the venue. It does not know your personal risk tolerance. It provides the infrastructure for one key and one API across five market types, but the owner must configure the scope.

The exact request schema is in the docs; the shape looks like this:

{
  "market_type": "perps",
  "symbol": "ETH",
  "dollar_amount": 500,
  "side": "buy",
  "api_key": "YOUR_KEY"
}

The fields above are illustrative. The actual endpoint and required parameters are documented at /docs. The key point is that the agent sends a plain dollar value, and the system handles the rest of the translation. Yet the owner still approves withdrawal addresses, authorizes live trading explicitly, and sets the safety controls that prevent a misinterpreted dollar amount from causing unintended losses.

Trading can lose money, including everything. No control system can guarantee a profitable outcome. The goal of the API is to make the plumbing consistent and safe, not to make the markets predictable.