Kalshiwe will see
we will see
james参与话题 16消息总数 132
该用户的聊天记录定位。
聊天记录
共 132 条，显示第 101-132 条single order batch use would be ~equivalent to single order use
single order batch use would be ~equivalent to single order use
yes
yes
can you give an example of how the ordering would impact execution? feel free to dm
can you give an example of how the ordering would impact execution? feel free to dm
but in a slow way
but in a slow way
it does
it does
well if you're waiting for each one to come back to you yeah
well if you're waiting for each one to come back to you yeah
It is probably slightly less efficient for us on the api gateway service itself, but we don't really care about api gateway efficiency because that's trivially easy to scale
It is probably slightly less efficient for us on the api gateway service itself, but we don't really care about api gateway efficiency because that's trivially easy to scale
I think >50% chance we remove batch endpoints in the coming weeks - just a heads up. (given that it's actually worse latency-wise than the regular endpoints, and it isn't cheaper rate limit wise either)
I think >50% chance we remove batch endpoints in the coming weeks - just a heads up. (given that it's actually worse latency-wise than the regular endpoints, and it isn't cheaper rate limit wise either)
hmm interesting. ok ill need to think about this a little bit more
hmm interesting. ok ill need to think about this a little bit more
Yeah, it neither minimizes latency nor is there a decreased cost so just trying to understand the existing use case (if any)
Yeah, it neither minimizes latency nor is there a decreased cost so just trying to understand the existing use case (if any)
question: those of you that use batch place/batch cancel - why? why not just use the regular place/cancel?
question: those of you that use batch place/batch cancel - why? why not just use the regular place/cancel?
it is not possible
it is not possible
Less than 10% of current requests are to v1 endpoints, so we will be bumping v1 rate limit costs to 10x on thursday. Then probably deprecate next Monday/Thursday tbd.
Less than 10% of current requests are to v1 endpoints, so we will be bumping v1 rate limit costs to 10x on thursday. Then probably deprecate next Monday/Thursday tbd.
when claude convinces users that the bug is on Kalshi's side 🙁
when claude convinces users that the bug is on Kalshi's side 🙁
yep! that's right. also should note that when we compute resting order cost we net against actual positions rather than resting orders in other markets in the same event, bc there's no guarantee that the other resting orders will execute
yep! that's right. also should note that when we compute resting order cost we net against actual positions rather than resting orders in other markets in the same event, bc there's no guarantee that the other resting orders will execute
we don't know how much we need to reduce by (or which orders we need to reduce) a priori and mecnet/directnet calculations are expensive in the hot loop
we don't know how much we need to reduce by (or which orders we need to reduce) a priori and mecnet/directnet calculations are expensive in the hot loop
correct, but as soon as it starts to fill they'll be cancelled
correct, but as soon as it starts to fill they'll be cancelled
market
market
yes, for that market, but you can use the same capital in a different market too
yes, for that market, but you can use the same capital in a different market too
yes exactly - you need to be able to cover any resting orders, but the "contract" we kinda have set up right now is that any orders on a single market will all be able to fill. we make no guarantees across markets
yes exactly - you need to be able to cover any resting orders, but the "contract" we kinda have set up right now is that any orders on a single market will all be able to fill. we make no guarantees across markets
probably not; there's many ways we could potentially do this and checking after every reduction is expensive. you're better set up to manage order sizing and decide what behavior you want
probably not; there's many ways we could potentially do this and checking after every reduction is expensive. you're better set up to manage order sizing and decide what behavior you want
resting orders don't tie up capital
resting orders don't tie up capital
its a lot easier if Kalshi's overall volume is high
its a lot easier if Kalshi's overall volume is high
yeah it automatically gets unblocked as time goes on
yeah it automatically gets unblocked as time goes on
cost of the old endpoints is now 5x the cost of the new endpoints! please plan accordingly
cost of the old endpoints is now 5x the cost of the new endpoints! please plan accordingly
yeah, would be 0
yeah, would be 0
to avoid needing to mantain it for people doing very very few requests
to avoid needing to mantain it for people doing very very few requests
yep! although we're going to get increasingly aggressive so when its sufficiently expensive we'll prob just cut it off
yep! although we're going to get increasingly aggressive so when its sufficiently expensive we'll prob just cut it off
🙂 (just to be clear, how we're doing it now? or would you change it in some way?)
🙂 (just to be clear, how we're doing it now? or would you change it in some way?)
updadting the getting started page as well, didn't realize that was still using the old endpoints
updadting the getting started page as well, didn't realize that was still using the old endpoints
hi all, will be bumping v1 costs again shortly.
hi all, will be bumping v1 costs again shortly.
← 上一页
第 3 / 3 页