聊天记录
共 209 条，显示第 1-50 条
The leaderboard entirely broke for me when I created my first subaccounts. Other stuff is still wonky. Maybe they just have not gotten to these things yet. I haven’t reported any of these bugs to them because it is not clear if they already know and Kalshi doesn’t have a good process for handling bug reports anyway. The leaderboard was also broken back when they split and then merged exchanges to support elections. I think it is just low priority to them, which is understandable.
The leaderboard entirely broke for me when I created my first subaccounts. Other stuff is still wonky. Maybe they just have not gotten to these things yet. I haven’t reported any of these bugs to them because it is not clear if they already know and Kalshi doesn’t have a good process for handling bug reports anyway. The leaderboard was also broken back when they split and then merged exchanges to support elections. I think it is just low priority to them, which is understandable.
I have seen more WS disconnects and other network IO problems today than usual.
I have seen more WS disconnects and other network IO problems today than usual.
Someone could compile a list of Kalshi graveyard features, ideas that appealed to someone in Kalshi leadership for 15 minutes. They made an MVP and an announcement and then got distracted by the next shiny thing and didn't leave any adult responsible for it.
Someone could compile a list of Kalshi graveyard features, ideas that appealed to someone in Kalshi leadership for 15 minutes. They made an MVP and an announcement and then got distracted by the next shiny thing and didn't leave any adult responsible for it.
There might be some constraint in the Kalshi back end that hits before you hit a URL length limit, but last time I poked at this, I found that was not the case.
There might be some constraint in the Kalshi back end that hits before you hit a URL length limit, but last time I poked at this, I found that was not the case.
The limiting constraint will be how long your URL can be and this is constrained by middleware such as CloudFront. When they were using CloudFront, that was what limited number of tickers in a query string (the maximum CloudFront URL length is 8,192 bytes). I don't know what the limit might be with the new load balancer configuration.
The limiting constraint will be how long your URL can be and this is constrained by middleware such as CloudFront. When they were using CloudFront, that was what limited number of tickers in a query string (the maximum CloudFront URL length is 8,192 bytes). I don't know what the limit might be with the new load balancer configuration.
It has been making a single interest payment to subaccount 0. But all of the “Credit” entries (interest, incentive, bounty) show up in all subaccounts.
It has been making a single interest payment to subaccount 0. But all of the “Credit” entries (interest, incentive, bounty) show up in all subaccounts.
(At least, it has been documented. I have not tried it yet. It is possible the documentation does not match the implementation.)
(At least, it has been documented. I have not tried it yet. It is possible the documentation does not match the implementation.)
They already have subaccount restriction per key: https://docs.kalshi.com/api-reference/api-keys/create-api-key#body-subaccount
They already have subaccount restriction per key: https://docs.kalshi.com/api-reference/api-keys/create-api-key#body-subaccount
Is anyone else seeing problems with subscribing to `market_lifecycle_v2` or `trade` channels? I subscribe to various channels at startup and sometimes I never get the `subscribed` response or any messages for those channels. I don't think I had this problem before.
Is anyone else seeing problems with subscribing to `market_lifecycle_v2` or `trade` channels? I subscribe to various channels at startup and sometimes I never get the `subscribed` response or any messages for those channels. I don't think I had this problem before.
The documentation is just out of date.
The documentation is just out of date.
re. deprecating batch operations: An additional use case to consider beyond ordering of batch creates is clients who want to cancel all outstanding resting orders immediately. My system has assertions that, if triggered, will result in canceling all resting orders. I also have a big red button on my web dashboard for this. I expect that many API users have something similar in that we want to cancel all resting orders, so we partition the order IDs into batches and call the batch delete endpoint multiple times. In emergency situations like this, do you want us to have to call a delete endpoint for every order ID?
re. deprecating batch operations: An additional use case to consider beyond ordering of batch creates is clients who want to cancel all outstanding resting orders immediately. My system has assertions that, if triggered, will result in canceling all resting orders. I also have a big red button on my web dashboard for this. I expect that many API users have something similar in that we want to cancel all resting orders, so we partition the order IDs into batches and call the batch delete endpoint multiple times. In emergency situations like this, do you want us to have to call a delete endpoint for every order ID?
At 2026-07-08T20:12:29.974366Z, my system received an `orderbook_delta` without first receiving an `orderbook_snapshot`. This is very surprising. That assertion never triggered before.
At 2026-07-08T20:12:29.974366Z, my system received an `orderbook_delta` without first receiving an `orderbook_snapshot`. This is very surprising. That assertion never triggered before.
https://discord.com/channels/871819895443189862/927686720990892032/1508899706296860742
https://discord.com/channels/871819895443189862/927686720990892032/1508899706296860742
Yes. On May 13, for example, orderbooks were invalid. The message from Kalshi was that we should not expect orderbooks to be valid.
Yes. On May 13, for example, orderbooks were invalid. The message from Kalshi was that we should not expect orderbooks to be valid.
Yes, I think this is a reasonable expectation. Having to deal with order books being entirely invalid is a different story, but I realize that dealing with investor expectations means being less honest about things.
Yes, I think this is a reasonable expectation. Having to deal with order books being entirely invalid is a different story, but I realize that dealing with investor expectations means being less honest about things.
no
no
Correct. Kalshi does not pause trading even when they know that the order books are nonsense and invalid.
Correct. Kalshi does not pause trading even when they know that the order books are nonsense and invalid.
Hahahaha. No.
Hahahaha. No.
Not anymore, no.
Not anymore, no.
Treating all `start` and `end` as inclusive works if there are only three ranges. `start` and `end` cannot be inclusive for adjoining ranges.
Treating all `start` and `end` as inclusive works if there are only three ranges. `start` and `end` cannot be inclusive for adjoining ranges.
Agreed. I currently have an assertion in place that should crash if my assumption proves wrong.
Agreed. I currently have an assertion in place that should crash if my assumption proves wrong.
I am amused that I keep encountering retail shops with signs talking about a shortage of pennies. I thought the government decided to stop making pennies because nobody used them.
I am amused that I keep encountering retail shops with signs talking about a shortage of pennies. I thought the government decided to stop making pennies because nobody used them.
> The source of truth for a market’s valid prices remains the price_ranges array on the market object
But `price_ranges` still seems underspecified to me without a bound type on the `start` and `end`.
> The source of truth for a market’s valid prices remains the price_ranges array on the market object
But `price_ranges` still seems underspecified to me without a bound type on the `start` and `end`.
For my system, `value` is seconds. I capture `user_data_timestamp` and compare it to my NTP clock.
For my system, `value` is seconds. I capture `user_data_timestamp` and compare it to my NTP clock.
You should not expect the REST data to be consistent until the latest difference between the user data timestamp and the current time. LOL, indeed, as the kids say.
You should not expect the REST data to be consistent until the latest difference between the user data timestamp and the current time. LOL, indeed, as the kids say.
Seems pretty good to me lately:
```select * from performance_metric where name='KalshiUserDataTimestampAge' order by timestamp desc limit 20
name|value|timestamp
KalshiUserDataTimestampAge|0.097226997|1774902623992427
KalshiUserDataTimestampAge|0.061221057|1774902608861482
KalshiUserDataTimestampAge|0.045842825|1774902593751724
KalshiUserDataTimestampAge|0.032496992|1774902577488431
KalshiUserDataTimestampAge|0.056566414|1774902560001591
KalshiUserDataTimestampAge|0.062418379|1774902468115376
KalshiUserDataTimestampAge|0.090488454|1774902452845908
KalshiUserDataTimestampAge|0.103652282|1774902347004317
KalshiUserDataTimestampAge|0.131838069|1774902331912142
KalshiUserDataTimestampAge|0.161286923|1774899765359736
KalshiUserDataTimestampAge|0.123257642|1774899750224505
KalshiUserDataTimestampAge|0.048711014|1774899735156124
KalshiUserDataTimestampAge|0.049383044|1774899719609340
KalshiUserDataTimestampAge|0.064319321|1774899703974550
KalshiUserDataTimestampAge|0.087006098|1774899688895211
KalshiUserDataTimestampAge|0.060041015|1774899623205659
KalshiUserDataTimestampAge|0.079946661|1774899608011498
KalshiUserDataTimestampAge|0.057685518|1774899592905565
KalshiUserDataTimestampAge|0.05471152|1774899577598883
KalshiUserDataTimestampAge|0.073111515|1774899562456576
```
Seems pretty good to me lately:
```select * from performance_metric where name='KalshiUserDataTimestampAge' order by timestamp desc limit 20
name|value|timestamp
KalshiUserDataTimestampAge|0.097226997|1774902623992427
KalshiUserDataTimestampAge|0.061221057|1774902608861482
KalshiUserDataTimestampAge|0.045842825|1774902593751724
KalshiUserDataTimestampAge|0.032496992|1774902577488431
KalshiUserDataTimestampAge|0.056566414|1774902560001591
KalshiUserDataTimestampAge|0.062418379|1774902468115376
KalshiUserDataTimestampAge|0.090488454|1774902452845908
KalshiUserDataTimestampAge|0.103652282|1774902347004317
KalshiUserDataTimestampAge|0.131838069|1774902331912142
KalshiUserDataTimestampAge|0.161286923|1774899765359736
KalshiUserDataTimestampAge|0.123257642|1774899750224505
KalshiUserDataTimestampAge|0.048711014|1774899735156124
KalshiUserDataTimestampAge|0.049383044|1774899719609340
KalshiUserDataTimestampAge|0.064319321|1774899703974550
KalshiUserDataTimestampAge|0.087006098|1774899688895211
KalshiUserDataTimestampAge|0.060041015|1774899623205659
KalshiUserDataTimestampAge|0.079946661|1774899608011498
KalshiUserDataTimestampAge|0.057685518|1774899592905565
KalshiUserDataTimestampAge|0.05471152|1774899577598883
KalshiUserDataTimestampAge|0.073111515|1774899562456576
```
Kalshi has made clear that when order books are untrustworthy, API traders should stop trading if they depend on order books.
Kalshi has made clear that when order books are untrustworthy, API traders should stop trading if they depend on order books.
Yes. The REST API is eventually consistent. The user data timestamp tells you when it was last updated.
Yes. The REST API is eventually consistent. The user data timestamp tells you when it was last updated.
The idea is that it is always outdated and it tells you how out of date it is. Are you seeing more latency than usual?
The idea is that it is always outdated and it tells you how out of date it is. Are you seeing more latency than usual?
Non-KX-prefixed markets created in 2026:
CONTROLH
CONTROLS
ECMOV
FEDHIKE
GOVPARTYRI
MOON
POPVOTEMOV
RSENATESEATS
SENATEMT
Non-KX-prefixed markets created in 2026:
CONTROLH
CONTROLS
ECMOV
FEDHIKE
GOVPARTYRI
MOON
POPVOTEMOV
RSENATESEATS
SENATEMT
It appears they are creating new markets without a KX prefix if they should belong to a series without a KX prefix. For example, POPVOTEMOV-28NOV07-REP900T10000 was created at 2026-05-20T15:25:22.748357Z.
It appears they are creating new markets without a KX prefix if they should belong to a series without a KX prefix. For example, POPVOTEMOV-28NOV07-REP900T10000 was created at 2026-05-20T15:25:22.748357Z.
My production system only runs one WS connection, so I have not seen that. But I am tracking down a problem right now where I sometimes do not get `market_lifecycle_v2`, which is weird.
My production system only runs one WS connection, so I have not seen that. But I am tracking down a problem right now where I sometimes do not get `market_lifecycle_v2`, which is weird.
FYI: <@378727998121181184> reported that markets in this event had bogus `custom_strike` properties.
FYI: <@378727998121181184> reported that markets in this event had bogus `custom_strike` properties.
Looks robust! It can handle Unicode.
Looks robust! It can handle Unicode.
They have a bug bounty program.
They have a bug bounty program.
Cool. Put some JavaScript or SQL in there and see what happens.
Cool. Put some JavaScript or SQL in there and see what happens.
Look at the `collateral_return_type` property on the event object.
Look at the `collateral_return_type` property on the event object.
This is cool. Looks like we will be able to restrict keys to subaccounts.
```diff
@@ -4112,6 +4205,12 @@ components:
description: List of scopes granted to this API key.
items:
$ref: '#/components/schemas/ApiKeyScope'
+ subaccount:
+ type: integer
+ nullable: true
+ minimum: 0
+ maximum: 63
+ description: If set, the API key is restricted to this single sub-account and may only read and trade on it. Absent/null means the key is unrestricted.
GetApiKeysResponse:
type: object
required:
@@ -4139,6 +4238,11 @@ components:
description: List of scopes to grant to the API key. If the broad `write` parent scope is included, `read` must also be included. Child scopes may be granted without the broad parent scope. Defaults to full access (`read`, `write`) if not provided.
items:
$ref: '#/components/schemas/ApiKeyScope'
+ subaccount:
+ type: integer
+ minimum: 0
+ maximum: 63
+ description: If set, restricts the API key to a single sub-account (0-63) that you own. A restricted key may only read and trade on that sub-account; it cannot act on other sub-accounts, transfer funds between sub-accounts, or create sub-accounts. Omit to leave the key unrestricted.
CreateApiKeyResponse:
type: object
required:
@@ -4160,6 +4264,11 @@ components:
description: List of scopes to grant to the API key. If the broad `write` parent scope is included, `read` must also be included. Child scopes may be granted without the broad parent scope. Defaults to full access (`read`, `write`) if not provided.
items:
$ref: '#/components/schemas/ApiKeyScope'
+ subaccount:
+ type: integer
+ minimum: 0
+ maximum: 63
+ description: If set, restricts the API key to a single sub-account (0-63) that you own. A restricted key may only read and trade on that sub-account; it cannot act on other sub-accounts, transfer funds between sub-accounts, or create sub-accounts. Omit to leave the key unrestricted.
GenerateApiKeyResponse:
type: object
required:
```
This is cool. Looks like we will be able to restrict keys to subaccounts.
```diff
@@ -4112,6 +4205,12 @@ components:
description: List of scopes granted to this API key.
items:
$ref: '#/components/schemas/ApiKeyScope'
+ subaccount:
+ type: integer
+ nullable: true
+ minimum: 0
+ maximum: 63
+ description: If set, the API key is restricted to this single sub-account and may only read and trade on it. Absent/null means the key is unrestricted.
GetApiKeysResponse:
type: object
required:
@@ -4139,6 +4238,11 @@ components:
description: List of scopes to grant to the API key. If the broad `write` parent scope is included, `read` must also be included. Child scopes may be granted without the broad parent scope. Defaults to full access (`read`, `write`) if not provided.
items:
$ref: '#/components/schemas/ApiKeyScope'
+ subaccount:
+ type: integer
+ minimum: 0
+ maximum: 63
+ description: If set, restricts the API key to a single sub-account (0-63) that you own. A restricted key may only read and trade on that sub-account; it cannot act on other sub-accounts, transfer funds between sub-accounts, or create sub-accounts. Omit to leave the key unrestricted.
CreateApiKeyResponse:
type: object
required:
@@ -4160,6 +4264,11 @@ components:
description: List of scopes to grant to the API key. If the broad `write` parent scope is included, `read` must also be included. Child scopes may be granted without the broad parent scope. Defaults to full access (`read`, `write`) if not provided.
items:
$ref: '#/components/schemas/ApiKeyScope'
+ subaccount:
+ type: integer
+ minimum: 0
+ maximum: 63
+ description: If set, restricts the API key to a single sub-account (0-63) that you own. A restricted key may only read and trade on that sub-account; it cannot act on other sub-accounts, transfer funds between sub-accounts, or create sub-accounts. Omit to leave the key unrestricted.
GenerateApiKeyResponse:
type: object
required:
```
Just FYI: That contradicts documented and observed behavior.
Just FYI: That contradicts documented and observed behavior.
I have reported several incorrect strike values to Kalshi. Sometimes they fix them.
I have reported several incorrect strike values to Kalshi. Sometimes they fix them.
<@1294044400065839177> Can you clarify what is meant by the "The maximum batch size scales with your tier’s write budget" for batch cancel orders? I find that if I set my maximum number of orders per batch to `write.refillRate / tokenCost` (where `tokenCost` is 2 for delete), I get a `too_many_orders_in_batch` error. If I set it to `write.refillRate / 10` (substituting the default token cost), I do not get that error. Does Batch Cancel not use the token cost for calculating the maximum number of orders per batch?
<@1294044400065839177> Can you clarify what is meant by the "The maximum batch size scales with your tier’s write budget" for batch cancel orders? I find that if I set my maximum number of orders per batch to `write.refillRate / tokenCost` (where `tokenCost` is 2 for delete), I get a `too_many_orders_in_batch` error. If I set it to `write.refillRate / 10` (substituting the default token cost), I do not get that error. Does Batch Cancel not use the token cost for calculating the maximum number of orders per batch?
Are you sure you are on production versus demo?
Are you sure you are on production versus demo?
My logs show good latency around that time.
My logs show good latency around that time.
This made me realize it is using the deprecated hostname. Fixing that now...
This made me realize it is using the deprecated hostname. Fixing that now...
It has been a bit since I looked at this. If I remember right, `/exchange/status` returns a 200 during the maintenance window that says the exchange is not available, so would not show as an outage.
It has been a bit since I looked at this. If I remember right, `/exchange/status` returns a 200 during the maintenance window that says the exchange is not available, so would not show as an outage.
user_data_timestamp has been bouncing around a bit today, but nothing crazy:
```
name|value|timestamp
KalshiUserDataTimestampAge|0.097226997|1774902623992427
KalshiUserDataTimestampAge|0.061221057|1774902608861482
KalshiUserDataTimestampAge|0.045842825|1774902593751724
KalshiUserDataTimestampAge|0.032496992|1774902577488431
KalshiUserDataTimestampAge|0.056566414|1774902560001591
KalshiUserDataTimestampAge|0.062418379|1774902468115376
KalshiUserDataTimestampAge|0.090488454|1774902452845908
KalshiUserDataTimestampAge|0.103652282|1774902347004317
KalshiUserDataTimestampAge|0.131838069|1774902331912142
KalshiUserDataTimestampAge|0.161286923|1774899765359736
KalshiUserDataTimestampAge|0.123257642|1774899750224505
KalshiUserDataTimestampAge|0.048711014|1774899735156124
KalshiUserDataTimestampAge|0.049383044|1774899719609340
KalshiUserDataTimestampAge|0.064319321|1774899703974550
KalshiUserDataTimestampAge|0.087006098|1774899688895211
KalshiUserDataTimestampAge|0.060041015|1774899623205659
KalshiUserDataTimestampAge|0.079946661|1774899608011498
KalshiUserDataTimestampAge|0.057685518|1774899592905565
KalshiUserDataTimestampAge|0.05471152|1774899577598883
```
user_data_timestamp has been bouncing around a bit today, but nothing crazy:
```
name|value|timestamp
KalshiUserDataTimestampAge|0.097226997|1774902623992427
KalshiUserDataTimestampAge|0.061221057|1774902608861482
KalshiUserDataTimestampAge|0.045842825|1774902593751724
KalshiUserDataTimestampAge|0.032496992|1774902577488431
KalshiUserDataTimestampAge|0.056566414|1774902560001591
KalshiUserDataTimestampAge|0.062418379|1774902468115376
KalshiUserDataTimestampAge|0.090488454|1774902452845908
KalshiUserDataTimestampAge|0.103652282|1774902347004317
KalshiUserDataTimestampAge|0.131838069|1774902331912142
KalshiUserDataTimestampAge|0.161286923|1774899765359736
KalshiUserDataTimestampAge|0.123257642|1774899750224505
KalshiUserDataTimestampAge|0.048711014|1774899735156124
KalshiUserDataTimestampAge|0.049383044|1774899719609340
KalshiUserDataTimestampAge|0.064319321|1774899703974550
KalshiUserDataTimestampAge|0.087006098|1774899688895211
KalshiUserDataTimestampAge|0.060041015|1774899623205659
KalshiUserDataTimestampAge|0.079946661|1774899608011498
KalshiUserDataTimestampAge|0.057685518|1774899592905565
KalshiUserDataTimestampAge|0.05471152|1774899577598883
```
This only checks the simplest things. The API has been very reliable compared to the past.
https://stats.uptimerobot.com/53rOQGUdnx
This only checks the simplest things. The API has been very reliable compared to the past.
https://stats.uptimerobot.com/53rOQGUdnx
If the intent is "remove the seconds from 'write budget'", that might make sense, but doesn't seem to correspond to what some users report.
If the intent is "remove the seconds from 'write budget'", that might make sense, but doesn't seem to correspond to what some users report.
https://docs.kalshi.com/getting_started/rate_limits currently has:
```
Tier |Read budget|Write budget
---------|-----------|------------
|Basic |200 |100
|Advanced|300 |300
|Expert |600 |600
```
Batch create/cancel would be write operations. Batch create would be 10 tokens per order, right? Batch cancel would be 2 tokens per order? I don't see how one gets to 20 orders being the max.
https://docs.kalshi.com/getting_started/rate_limits currently has:
```
Tier |Read budget|Write budget
---------|-----------|------------
|Basic |200 |100
|Advanced|300 |300
|Expert |600 |600
```
Batch create/cancel would be write operations. Batch create would be 10 tokens per order, right? Batch cancel would be 2 tokens per order? I don't see how one gets to 20 orders being the max.
A batch always takes one second? Still not clear to me. What token per second limit would result in 21 orders returning `too_many_orders_in_batch`?
A batch always takes one second? Still not clear to me. What token per second limit would result in 21 orders returning `too_many_orders_in_batch`?
Kalshi