How to start trading with dollar-based order sizing in 2026

Felix normalizes every order into a plain US dollar amount, so you do not need to translate human intent into venue-specific contract math. You tell the agent to buy one hundred dollars of an asset, and the API computes the correct number of shares, coins, or contracts at that venue. This works across stocks, crypto, perps, options, and prediction markets from a single key. The goal is to remove manual translation errors and let the agent reason about risk in the same currency you do.

What does dollar-based order sizing actually mean?

In traditional automated trading, an agent must know the native unit of every venue. A stock might trade in whole shares or fractional shares depending on the broker. A crypto asset might require eight decimal places. A perpetual futures contract might have a notional value that changes with the underlying price. An option contract usually controls a fixed number of shares, but the multiplier can vary by venue. A prediction market might price outcomes between zero and one dollar, yet trade in discrete share counts. If you ask a naive agent to buy five hundred dollars worth of each, it must perform five different conversions before it can even draft an order.

Even a simple task like rebalancing a portfolio becomes fragile when the agent must remember that one venue allows notional orders while another requires integer lots. A single mistake in decimal placement can turn a intended five hundred dollar trade into a fifty thousand dollar trade, or reduce it to five dollars. Dollar sizing removes this class of error by making the API the only component that touches native units.

Dollar-based sizing flips this responsibility. You send a number in US dollars. The API holds the mapping tables for each venue: contract multipliers, tick sizes, minimum order sizes, lot increments, and price precision. It computes the native quantity that most closely matches your dollar intent, rounds it to the venue's rules, and submits the order. The agent does not hold this logic.

The agent does not need to know whether a venue supports notional orders, quantity steps, or odd lots. It treats the problem as portfolio allocation in a single currency. The API translates that allocation into the mechanical details of order entry. This separation of concerns means that a strategy author can write prompts in plain financial language rather than in venue-specific configuration code.

Why do agents need dollar sizing across multiple market types?

Agents that trade more than one asset class face a combinatorial complexity problem. Suppose your strategy wants to allocate five percent of available capital to a short-term momentum signal. Without dollar normalization, the prompt must say: if the signal is on a stock, compute shares; if it is on a crypto token, compute decimals; if it is on a perp, compute contracts using the current notional; if it is on an option, compute contracts using the multiplier; if it is on a prediction market, compute shares using the midpoint price. That is not strategy logic. It is plumbing.

Strategy authors should not need to maintain exchange rulebooks. They should express intent in terms of capital allocation, and the infrastructure should handle the rest.

By pushing this plumbing into the API, the strategy logic stays clean. The agent reads a price, computes a dollar target, and sends it. The same risk sentence works everywhere: do not exceed one thousand dollars per position. The same portfolio rebalance command works everywhere: reduce exposure by two hundred dollars. This is especially useful when you manage a multi-market portfolio with one agentic API. The agent does not need to maintain a library of venue rules that drift every time a venue changes its minimum order size or contract terms.

How do you set a budget cap and position limit in dollars?

Safety controls in Felix are expressed in the same currency as the orders. When you create a scoped key, you define a budget cap in dollars per day, week, or month. The system tracks committed and executed dollars against that cap. If an agent tries to send an order that would breach the cap, the API blocks it before the order reaches a venue.

Position limits work the same way. You can state that no single position may exceed five thousand dollars of notional exposure. The API monitors open positions across all connected venues and rejects orders that would push a position over the limit. These are hard constraints, not suggestions. The agent cannot override them by rewriting its prompt. They are enforced at the key level, which sits outside the agent's reasoning loop.

This design is central to how you limit risk when AI agents trade through MCP tools and a single API. For leveraged markets like perpetual futures, the same dollar limits apply to notional exposure, so the agent cannot use margin to sneak around a cap. You can read more about how these hard limits work in practice in our guide on how an AI agent trades perpetual futures within hard limits it cannot cross.

What happens when the agent reaches a market with different contract math?

The API acts as a translation layer with strict validation. When a dollar order arrives, the system looks up the current market price, the venue's contract multiplier, the minimum order size, and the tick size. It then calculates the native quantity and rounds it down to the nearest valid increment. If the resulting order is below the venue's minimum, the request is rejected and the agent receives an error. If the price is stale beyond a configured threshold, the request can be held for a fresh quote or rejected outright.

If the market moves between the time the agent sends the dollar amount and the time the order fills, the actual notional may differ slightly. You can configure a slippage tolerance in percentage or dollar terms. If the fill would exceed this tolerance, the order can be cancelled or held depending on your setting. This prevents an agent from accidentally accepting a far worse price simply because it expressed intent in dollars rather than limit prices.

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

{
  "market": "example-market-identifier",
  "side": "buy",
  "dollar_amount": 500,
  "time_in_force": "day"
}

The response includes the executed native quantity, the average fill price, and the actual dollar notional, so your logs remain auditable. The agent does not need to parse the response to update its risk model. It can rely on the dollar values it sent, because the API guarantees that the executed notional will not exceed the specified dollar amount unless you explicitly configure slippage tolerance.

How do you test dollar sizing before going live?

Paper trading uses the same normalization engine as live trading. This means you can test edge cases safely. Try a fifty dollar order on a high-priced stock to see if it triggers a fractional share or is rejected by a whole-share venue. Try a fifty dollar order on a crypto pair with a high minimum lot size. Try a fifty dollar order on an option that trades in five-hundred-dollar notional increments. The paper environment returns the same errors and fills the same way live trading would, but no capital moves.

Use this phase to calibrate your agent's default order sizes. If you discover that many of your intended trades fall below venue minimums, raise the agent's floor rather than letting it retry repeatedly. Once the behavior is predictable, you authorize a live key. Live trading requires explicit owner approval of that key, and the budget caps you set in paper mode carry over unless you change them.

If you connect the agent through an MCP tool like Claude or Cursor, the paper trading environment responds to the same tool calls as live trading. You can run a full back-and-forth conversation where the agent proposes trades, the system returns paper fills, and you inspect the dollar notional of each simulated position. This is the safest way to verify that the agent understands its budget cap before you grant live access.

How does dollar sizing fit into a broader risk system?

Dollar-based sizing solves the input problem, but it does not solve the exit problem. Every entry sized in dollars needs a corresponding exit plan. You can automate stop-losses and take-profits in the same currency: sell if the position drops below four hundred dollars of value, or sell if it rises above six hundred. These rules are enforced by the infrastructure, not by the agent's memory. If the agent loses its context or behaves unexpectedly, the exit plan still runs.

You should also configure a panic switch. This flattens all positions and revokes the key. Because the API knows the dollar size of every position, it can compute the exact flattening orders instantly. The kill switch does not depend on the agent to cooperate.

You can think of dollar sizing as the language that the owner and the agent share, while the API translates that language into the dialect each venue understands. The owner says risk ten dollars, the agent understands ten dollars, and the venue receives the correct number of shares or contracts. Nothing is lost in translation.

Remember that trading can lose money, including everything. Standardized sizing makes it easier to reason about exposure, but it does not reduce market risk. You can build a complete checklist for automating exits in our article on how to automate exit plans and take-profit rules for an AI trading agent.