vcf

Prohibitively expensive is all relative. Pre-Fable, I was getting fine on the 5x plan for 1-2 concurrent long-running tasks plus interactive work (I do a lot of coding for work, but it is not my full work day). I don’t think a cache miss every hour on Opus hurts that much, even at 500-600k context. It would be nice if they got /clear working on remote-control.

It launches these tasks in the background. It became really good at it a couple of months ago, now it sets monitors on timer (not something I instructed, so I assumed it’s part of the system prompt for this kind of tasks) and then just wait for the next prompt, for the background process to be done, or for a monitor to trigger a checkup.

I used to have some hooks for local notification, but lately I find that claude is pretty good at notifying through the app with remote control (but definitely not perfect)

I run a lot of data science-type analyses that can take up to hours at a time to run, so Claude is « monitoring » tasks most of the time. I have it on remote-control so I get notified when a task is done or need clarification, but most importantly whenever I have a new idea, I can just ask Claude to queue it up. Most of the time my hardware is the bottleneck, not the subscription quotas.

I almost never went back to read the history, but now I often have Claude go through the history when I wonder how we got to a certain point. It can point me to the relevant issues as well. Squashing is fine, up to a point.

Similar for me, I don’t want to babysit agents . I’m sticking with Python for the libraries (data science ecosystem), but I find that imposing ty and a few reasonable ruff rules (imposed with pre-commit so the agent can fix things automatically) improves agent-generated code a lot.

I agree that the style is somewhat generic, but for things like new release announcements, I find that the common structure allows me to skim through much faster. I value that and am happy with that tradeoff.

Me too, I rarely hit limits anymore on the $100 Max, except for the brief period with Fable

At my university, students with verified disabilities are allowed to use a university-provided laptop (properly locked-down, with allowed tools such as screen readers). But these are special cases. Computers for everyone would be costly and impractical given exams are punctual but all roughly over the same week or so.

It's simpler when looking at prediction markets because of bounded payoffs and the zero-sum nature, so these are pure trading gains.

In equity markets, you have both the trading and investment components to account for. Market makers like Citadel don't invest; they aim to exit positions as quickly as possible to minimize risk and capital requirements. Long-term investors commit capital to risky assets and are compensated with a risk premium (expected to be positive, but it can turn out to be negative). Usually, the "cost" of liquidity paid by long-term investors is tiny related to the overall expected returns. In prediction markets, you don't have that.

Yes. It's not only that, as we also find very successful traders who take directional bets on elections and sports. But among the most successful traders, a large fraction are acting as market makers. Note that acting like one is not enough. We also find many traders acting as market makers among the least successful, yet they don't lose as much as the top winners do.

Thanks! No, we haven't looked at the capital "locked" in these markets (which is important considering there is no margin trading, at least not yet). Most markets have a short horizon, but some have very long ones. It gets very complicated very quickly because it's not always the case that you open a position and then close it (you get partial fills, users closing partial positions, etc.). Taking that into consideration would make liquidity providers look even better than they do in our study. Not having their capital locked allows liquidity providers to trade more and earn more per trade on average. Trading on margin would allow liquidity takers to lose more money more quickly (this is an educated guess; you never know what the outcome of a new policy would be until you implement it).

That's true, but you can invest in your infrastructure and data sources to be faster than most traders, which allows you to provide liquidity with a smaller spread (and snipe the slower traders that try to provide liquidity)

not AI slop, simply a copy paste if the abstract of the paper. journals in our field limit the allowed number of words, so the style can feel « unnatural » even when human-written

Yes, when you submit for publication. In our field, you rarely see one for pre-prints, unless you have one to disclose.

Yes, but the alternative (that some people are very good at forecasting) is also plausible. It's also useful to have a good prediction model and timely data sources when providing liquidity. We also find that some of the "biggest losers" also provide liquidity; they just aren't as good at it.

Yes, power laws are everywhere. The exact shape of each distribution varies, however, and little is known empirically about the distribution of trading profits in financial markets.

We don't know the exact benchmark, but your insight is correct. We provide a simulation similar to what you have in mind towards the end of the paper, but you can generate almost any distribution you want by fine-tuning a simulation...

Because it's not required and not common practice in our field at this stage. But none of us (I'm one of the authors) is affiliated with or has a financial interest in any prediction market platform.

Not meant to sound like AI, but most academic journals limit abstracts to 100 words, so they rarely feel natural...

I agree: insiders are hard to study because they are finite and short-lived. We're pretty confident there are insiders out there trading on Polymarket; however, our conclusion is that they don't account for a significant fraction of the total trading gains on the platform.

We have a grad student working on matching markets across venues. Not a trivial task at scale, but we hope to look at that eventually.

We study trading gains and losses on Polymarket, the largest prediction market. Using 588 million trades ($67 billion in volume), we show that the gains are highly concentrated: the top 1% of users capture 76.5% of profits. Successful traders provide liquidity using limit orders that resolve favorably relative to realized outcomes while unsuccessful traders take liquidity using market orders. Monthly performance is weakly persistent, however, this may represent sample selection rather than skill. A detailed analysis of the trading behavior of the most successful accounts suggests that "insider'' trading is unlikely to explain the performance of the largest winners.

Full dataset available at https://huggingface.co/datasets/vgregoire/polymarket-users

Interesting read. Regarding the relationship between volume and accuracy, there need not be one in limit-order-book markets like Kalshi and Polymarkets. In theory, as long as quotes are accurate and adjust quickly to new information, there is no need (and no incentive) to trade since prices are efficient. This is the case in US equity markets: most price discovery occurs through quote updates, not through trades.

Studying prediction markets is one of my current research areas. In my latest paper (preprint at https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6443103), we find that on Polymarkets, markets are, on average, quite accurate and unbiased. We did see a similar non-pattern between trade volume and accuracy, past a certain threshold.

Thanks! I will look into these bugs, it’s a PIA because you can only debug those while there is a live game… Same with auto-refresh, it should work but for some reason it’s inconsistent.

I took the lazy way out and use a dependency for that. I’ll look into it and see if I can either push a fix upstream or reimplement myself.

One repo per project. It makes it easier when I want to share or make public. I have 100+ repos in my account and I don’t find that cumbersome.

Thanks, fixed!

Not player stats, only team stats. I'll have to see if player-level stats are available in the API.

I had the same thought, went ahead when I found an existing Python module to access the API.

Different sports have different ways to present the data. But most importantly, the data availability differs a lot between leagues, so there’s a benefit to having separate tools. I, for one, would not want to maintain an app for all sports.