该用户的聊天记录定位。
Noticing on the GetFills and GetHistoricalFills endpoints that client_order_id is no longer delivered with the response. Is that indeed the case?
Noticing on the GetFills and GetHistoricalFills endpoints that client_order_id is no longer delivered with the response. Is that indeed the case?
Had the same issue. Seems like there is a flaw in the burst logic being implemented. I did a calc and deduced that they are measuring the effective lambda based on only cost intensity/budget, which implies a minimal spacing interval between write requests. That's imposing a hard throttle on order submission frequency where you should have some batch headroom. But that's just a wild guess. Have no idea what's goes on under the hood....
Had the same issue. Seems like there is a flaw in the burst logic being implemented. I did a calc and deduced that they are measuring the effective lambda based on only cost intensity/budget, which implies a minimal spacing interval between write requests. That's imposing a hard throttle on order submission frequency where you should have some batch headroom. But that's just a wild guess. Have no idea what's goes on under the hood....
I see above.... this is a push to v2 issue
I see above.... this is a push to v2 issue
Second question is on new rate limit calculus which some other have pointed out... exception 429 - rate limit exceeded seems to be popping up now for even trivial sequential order placement (e.g. 2 in a batch or close transmission). 1st order accepted. 2nd order rejected. Per order cost is 10 tokens. Total cost is thus 20 tokens for 2 sequential orders. Per second write budget B is based on tier. Call that B/second. Effective rate is B/20 in this case. Even at the lowest tier B=100 the effective rate should be 100/20=5. So two sequential orders shouldn't be failing even for basic tier. What seems to be happening is that the rate limit is computed as total cost/B = min_time_spacing. At the basic tier for 2 orders 20/100 = 200ms spacing. Obviously you can submit faster at higher tiers. Point is, it doesn't seem that the burst allowance is being implemented (basic tier should be bale to submit 10 orders per second). But could also be an issue with legacy Create Order vs Create Order v2.... any color?
Second question is on new rate limit calculus which some other have pointed out... exception 429 - rate limit exceeded seems to be popping up now for even trivial sequential order placement (e.g. 2 in a batch or close transmission). 1st order accepted. 2nd order rejected. Per order cost is 10 tokens. Total cost is thus 20 tokens for 2 sequential orders. Per second write budget B is based on tier. Call that B/second. Effective rate is B/20 in this case. Even at the lowest tier B=100 the effective rate should be 100/20=5. So two sequential orders shouldn't be failing even for basic tier. What seems to be happening is that the rate limit is computed as total cost/B = min_time_spacing. At the basic tier for 2 orders 20/100 = 200ms spacing. Obviously you can submit faster at higher tiers. Point is, it doesn't seem that the burst allowance is being implemented (basic tier should be bale to submit 10 orders per second). But could also be an issue with legacy Create Order vs Create Order v2.... any color?
Couple of V2 questions on the event-order endpoint changes... 1) Create Order v2 now has price as required. I assume this means that market orders should be submitted as guaranteed marketable limit orders with buy price = 1 and sell price = 0. Make sense?
Couple of V2 questions on the event-order endpoint changes... 1) Create Order v2 now has price as required. I assume this means that market orders should be submitted as guaranteed marketable limit orders with buy price = 1 and sell price = 0. Make sense?
Kalshi