Can you change the price of a limit order on Kalshi?
The Short Answer
Yes, you can change the price of a resting limit order on Kalshi, but the exchange handles it as a cancel and replace rather than a true in-place edit, so your order goes to the back of the queue at the new price. In the app that means canceling and entering a fresh order. Through the trade API it is a single amend call. Either way the decision is the same, because you priced against a book that has already moved, and the median spread on two-sided Kalshi books is 5.1 cents.
An unfilled order is not waiting. It is going stale. Cancel, modify and refresh are the three ways out, and on a two-leg position you make that call twice.
Key Takeaways
- Changing the price of a resting order costs you queue priority on any order book, Kalshi included. Only a reduction in size normally keeps your place in line.
- Median spread on two-sided Kalshi books is 5.1 cents, and by 24-hour volume it runs 8 cents under 100 contracts against 1 cent above 10,000.
- 18.1% of 5,000 live Kalshi markets had no bid at all. On a Kalshi binary, NO_ask = 100 - YES_bid, so a zero YES bid prices the NO leg at 100 cents.
- Canceling a resting Kalshi order carries no exchange fee. Fees are charged on fills, so repricing costs queue position and time rather than commission.
- Predictefy's execution service exposes build, submit, cancel, modify and refresh on one
/v1/exec/{venue}/ordersshape across 15+ venues, and every write takes anIdempotency-Key, so a retried modify cannot become a second live order.
Can you change the price of a limit order on Kalshi?
There are two paths, and which one you get depends on how you trade.
In the Kalshi app, as of September 2026, resting orders sit in an orders panel where each one can be canceled. There is no field you click to nudge the price of a live order, so changing a price means canceling and placing a fresh one. That second step deserves a new look at the book, not a reflex re-entry at your first price.
Kalshi's trade API exposes an amend operation that changes price and count on an existing order, plus a decrease operation that only lowers the resting quantity. Amend is the closest thing to an edit, but read what it does rather than what it is called: the exchange retires the old order and creates a replacement, so you get a different order id and your queue position starts over.
What happens to your order when you change the price on Kalshi?
Order books fill by price, then by time. At any level the order that arrived first fills first, and that queue position is the only thing your resting order owns.
Change the price and you are no longer that order. You are a new order at a new level, joining the back of whatever line exists there. That is how continuous limit order books work, and it is why repricing is a real cost. Reducing size usually preserves priority, because you are asking for less than you already queued for. Raising size, or moving price, does not.
Liquidity decides whether that matters. On a book trading thousands of contracts a day the lost priority is noise. On one trading forty contracts a day, you can give up an hour in line for a price that still does not clear.
Why is my Kalshi limit order not filling?
Four causes cover almost everything. Your limit is priced away from where trades are actually happening. There is no other side at all. The book moved after you priced, which is the stale order case. Or size sits in front of you at the right price with too little flow to clear it. The measurements sort those apart.
| What the book looks like | Measurement | What it means for your order |
|---|---|---|
| All two-sided Kalshi books | 5.1 cent median spread | A one cent improvement usually reaches nobody |
| Under 100 contracts of 24-hour volume | 8 cent median spread | Wide and slow, so repricing burns priority for little gain |
| Above 10,000 contracts of 24-hour volume | 1 cent median spread | Tight and fast, where a stale price is punished hardest |
| Markets with no bid at all | 18.1% of 5,000 markets | Nothing to fill against, so patience is not the fix |
| Markets priced under 5 cents | 41% had no bid | Long shots are frequently one-sided books |
| Widest book measured | KXUSCPIYEAR at 57 cents | Scalar economic markets are close to untradeable at a limit |
In the 25 to 50 cent band, 0% of markets had no bid, so a limit that never fills mid range is a spread problem. One that never fills at 3 cents often has nobody on the other side.
When is it better to cancel a Kalshi order than to reprice it?
Ask what changed. If your view of the outcome changed, cancel, because a repriced order is still an order on a trade you no longer want. If only the level is wrong, modify. If you keep repricing against a moving book, you want a refresh loop rather than a human making the same call twenty times.
| Action | What it does | When it is the right call |
|---|---|---|
| Cancel | Removes the order and frees the reserved capital | The thesis changed, the event is near resolution, or the balance is worth more elsewhere |
| Modify | Changes price or size, giving up queue priority at the new price | The trade is still right and the level is wrong by a known amount |
| Refresh | Replaces a stale order with one priced off the book as it stands now | You are working a moving market and want the order to track it |
Decide in advance how far you will chase, because a limit walked toward the offer a cent at a time is a slow market order.
How do you reprice a Kalshi order through an API?
The awkward part is not Kalshi, it is that every venue solves this differently. Polymarket's book takes cryptographically signed orders, so there is nothing to amend: you cancel and sign a new one. Write reprice logic per venue and you write it again every time you add one.
Predictefy's execution service is a separate, isolated, non-custodial service at its own origin, distinct from the reads API. Routes sit under /v1/exec/{venue}/orders/... for build, submit, cancel, modify and refresh. Orders are signed client-side, and there is no generic server-side signing route.
curl -X POST "$PREDICTEFY_EXEC/v1/exec/kalshi/orders/modify" \ -H "Authorization: Bearer pk_live_..." \ -H "Idempotency-Key: reprice-leg-a-2026-09-04-0007"
What this does
Calls the modify route for a Kalshi order. The request body carries the identifier of the resting order and the new price. Swap kalshi for another venue slug and the route shape holds: one code path reprices across 15+ venues instead of one branch per venue amend API. The Idempotency-Key is required on every write and makes the call safe to retry.
You still need the book you are repricing against. That lives on the reads API at https://data.predictefy.com, in the /api/{venue}/{verb} shape with the same bearer auth. For a reprice loop, do not poll it: the WebSocket at /v1/stream pushes updates, so you modify against the book as it is now.
How do you stop a retry from placing the same order twice?
With an idempotency key, a caller-generated identifier the service uses to recognize a request it already processed. Duplicate submission is one of the most expensive bugs in automated trading, and it rarely comes from a double click.
It comes from a request that timed out, or a response lost after the venue already accepted the order. Your code believes nothing happened. The exchange disagrees. Repricing makes it worse, because a modify that looks like it failed invites the retry that turns one order into two.
Predictefy requires an Idempotency-Key on every write, so a retried modify cannot become a second live order. Pair that with the default caps of 100 USD per order and 1,000 USD per key per rolling 24 hours and a runaway loop hits a ceiling instead of an open tab.
If a model is doing the repricing, pin the packages, because the latest tag points at a beta release.
npm install @predictefy/sdk@1.0.0-beta.3 pip install predictefy==1.0.0b2 npx -y @predictefy/mcp
What this does
Installs the pinned beta packages and runs the MIT licensed MCP server. Its documented safety constraint matters here: no tool both builds and submits an order. Build is not metered either, so a candidate reprice can be costed without spending credits.
What happens if only one leg of an arbitrage fills?
You are running a directional bet you never chose to take. A two-leg position is only a hedge while both legs exist, so once leg A fills and leg B is still resting, every second spent repricing it is time spent exposed.
Three rules keep that honest. Price both legs off books read at the same moment, because a spread built from a fresh quote and a stale one is not a spread. Set the walk limit before you submit: once repricing no longer leaves the edge you entered for, close leg A rather than chase leg B. And watch what a missing quote does to the arithmetic, because NO_ask = 100 - YES_bid means a zero YES bid puts the NO leg at 100 cents. That is not an opportunity, it is an empty book wearing a price.
Qualifying both legs against live books and repricing them through one route shape means the logic that decides to modify, cancel or refresh is the same code whichever two of the 15+ venues the pair lands on. The arbitrage API is free, so qualification costs nothing while you tune execution.
Does it cost anything to cancel or reprice an order?
On Kalshi, no exchange fee. Fees are charged on fills, so repricing costs queue priority and time rather than commission. On Predictefy's execution service, credits are charged on submit, cancel and modify, while build is not metered, so you only pay when something touches the venue. The Free plan carries 25,000 credits a month, 60 requests a minute, one API key and two streams.
Two honest limitations. fetchBalance on the hosted API intentionally returns 501 NOT_SUPPORTED, so working capital tracking has to come from your venue accounts. And stored history is proven for 11 venues rather than all 17, so confirm your venue is one of the eleven before leaning on historical spread behavior.
Frequently Asked Questions
Can you edit an open order on Polymarket?
No. Polymarket's order book takes cryptographically signed orders, and the signature covers the price and size you signed, so there is nothing to amend in place. Changing a price means canceling the resting order and signing a new one. The practical result matches Kalshi's amend anyway, since you surrender queue priority either way.
Should I cancel my order or just change the price?
Change the price if the trade is still right and only the level is wrong. Cancel if your view changed, if the event is near resolution, or if the capital is worth more elsewhere. The tiebreaker is the walk limit you set before entering: once repricing has eaten the edge you entered for, cancel.
How many Kalshi markets have no bid at all?
18.1% of 5,000 live Kalshi markets had no bid at all, so an order that never fills may have nothing on the other side. Under 5 cents that rises to 41%. In the 25 to 50 cent band it was 0%, where an unfilled limit points at the spread instead.
Is there a fee to cancel an order on Kalshi?
No. Kalshi charges trading fees on fills, so canceling a resting order costs nothing at the exchange. The real price of canceling and re-entering is queue priority, since your replacement joins the back of the line. On thin books that lost place can matter more than the cent you were chasing.
What happens if you submit the same order twice?
You end up with two live orders and double the exposure you intended. It usually comes from a retry after a timeout rather than a double click, since the venue may have accepted an order whose response never reached you. An Idempotency-Key on every write is what prevents it, and Predictefy requires one.
Does changing the price lose my place in the queue?
Yes. Books fill by price then time, so an order at a new price is a new order at the back of that level's line. Reducing size normally keeps your place, since you are asking for less than you already queued for. Increasing size, or moving the price in either direction, does not.
Can you change the number of contracts instead of the price?
Yes, and it is the cheaper change. Kalshi's API exposes a decrease operation that lowers the resting count, and reducing size generally preserves queue priority where a price change does not. If your problem is sizing rather than pricing, cut the count and keep the position in line.