Not 100% in the first year (where I live). By the time it’s depreciated, it’s time to replace. Subscriptions are 100% deductible in the year you pay them.
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.
> take up to hours at a time to run, so Claude is « monitoring » tasks most of the tim
How is Claude monitoring them for hours? Claude runs out of context and extremely long sessions are prohibitively expensive even according to Anthropic (after they dispense with the marketing bullshit of long running tasks)?
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.
A single session running for multiple hours is prohibitively expensive, as per Anthropic. Regardless of whether it just waits for a prompt or does something.
Is the high expense coming from cache misses? If their workload does need to wait for a long time before it can continue, I wonder would starting new sessions and having to re-read the contexts and results anyway be any cheaper.
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.
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)
There are so many neat use cases like this one that I'm skeptical of the AI-is-a-dot-com-bubble naysayers. Not to mention that, unlike in 2000, technical-adjacent people can now get a reasonable approximation of their ideas running quickly.
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.
architecture matters more. at least for now, you should watch (not babysit) your agent, because it will slop up your architecture while you're not looking.
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.
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.
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).
The long horizon ones are also interesting on Polymarket because the vast majority don't have APY. As a result, prices should be discounted, but sum-to-1 doesn't allow for it. I'd expect a negative skew to the performance of traders willing to take those inflated prices (relative to what the odds DCF imply they should be). But there's also no upside for makers, so liquidity is pretty thin.
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, 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.
I don't know. Buffett had a good example of, if you organized a national coin flipping contest in the US, you would have people that won 25+ coin tosses in a row. Are these people good at calling coin tosses or is it just chance? You cannot reliably and long term predict if Bitcoin will go up or down within 5 minutes, or something similar. You can cheat maybe somehow, but that's not within the rules of the game.
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)
reply