You can switch to consumption-based usage and bypass this all together but it can be expensive. I run an enterprise account and my biggest users spend ~2,000 a month on claude code (not sdk or api). I tried to switch them to subscription based at $250 and they got rate limited on the first/second day of usage like you described. I considered trying to have them default to subscription and then switch to consumption when they get rate limited, but I didn't want to burden them with that yet.
However for many of our users that are CC users they actually don't hit the $250 number most months so its actually cheaper to use consumption in many use cases surprisingly.
I had a similar thought at first but then read the actual ruling and it made more sense and it all stems on the 3rd prong of the Howie Test. It states there needs to be a "reasonable expectation of profits derived from the managerial efforts of others" which a share of stock has via dividends, etc. regardless how it was acquired.
For XRP, there is no explicit rights to profits via the efforts of others via the instrument so you then have to look at the agreement made via the contract between the purchaser and the issuer.
On page 18 of the ruling it outlines this for Institutional Investors:
'''The third prong of Howey examines whether the economic reality surrounding Ripple’s Institutional Sales led the Institutional Buyers to have “a reasonable expectation of profits to be derived from the entrepreneurial or managerial efforts of others.”... Based on the totality of circumstances, the Court finds that reasonable investors, situated in the position of the Institutional Buyers, would have purchased XRP with the expectation that they would derive profits from Ripple’s efforts. '''
However for "Programmatic Buyers" on exchange the ruling said:
'''Having considered the economic reality of the Programmatic Sales, the Court concludes that the undisputed record does not establish the third Howey prong. Whereas the Institutional Buyers reasonably expected that Ripple would use the capital it received from its sales to improve the XRP ecosystem and thereby increase the price of XRP, Programmatic Buyers could not reasonably expect the same.'''
So because there is both no expectation of profits tied to the managerial efforts of others, nor from the contract made by a buyer on exchange, the court ruled the 3rd prong does not apply. Stocks fail the first part of this.
It comes up durring hiring processes. Pretty common to have someone ask, "Have you entered into any legal agreement that would prohibit you from working with us or have any conflict of interest? If so please explain."
This is a GREAT point, but hard to do in practice when deferred can be several multiples of base. I know many people who internalize large sign on bonuses and deferred comp as though they already earned the income. They are psychologically unable to accept writing this amount of money off, and force themselves to stick in situations that are at times not healthy or at least sub-optimal. Often times this is called life, and you deal with it because it is putting food on the table and providing above and beyond for your family. However a lot of times it would be better to just find something that makes you happier which is easier if you don't factor in deferred comp when thinking through personal finances.
You cannot work with a former colleague for an explicit duration in an economic capacity for a fixed period of time. This may or may not be dependent on the nature of the work being conscidered competitive (I have seen both). I have only seen these clauses referenced in deferred comp, not contractual non-competes.
Yes this is great but the way non-competes are enforced for many in the industry this won't have a huge impact because of the way deferred compensation is structured. Most people when they leave are bound to two separate forms of non-competes.
The first is what is being invalidated here, which is a contractual non-compete. The second is a non-compete clause that is a function of your deferred compensation. Here the firm pays a portion of your bonus into the fund that vests over time. Often times a condition of the vesting is that you can leave, but if you do anything competitive for a 1-2 year period following the end of employment with the firm, that deferred comp will be clawed back. For most people this is the most important. It is common for a new fund to offer the employee a make-whole agreement where they will transfer your marked to market deferred comp into the new fund knowing that your prior employer will zero out your deferred comp. This will now in theory allow employees to switch employers that are competitive and start immediately with zero downside as long as the new employer makes the employee's deferred comp whole.
Where this is the worst is for new entrepreneurs leaving these funds that want to start on their own. Even if their contractual NC is no longer valid, there is not a new employer to make their deferred comp whole. Also even in CA where NC's are in theory non-enforceable, I know multiple people whose new employers did not want to test the water with very litigious firms and had people sit out the full NC. Also what this does not address is non-association clauses which are just as restrictive and non-competitive.
Lastly NC structures in this industry change every year and vary significantly across firms so you can't paint with too broad of a brunsh. But all in all I love this change. There is a lot of passion and talent that is forced to sit idle because of NC's.
It is my understanding that you quitting big meat, doesn't affect your risk. If you are exposed to a new drug resistant pathogen that was the result of anti-biotics in cattle, chicken, pork, etc, it doesn't matter if you even eat meat.
That said am I interpreting this right? How much of a risk does the use of antibiotics in meat present to a vegetarian?
The jump of going from model -> webserver by placing the webserver in the same process as the model is enticing because you can get it to work in under an hour by adding flask/django/fastapi to the env and decorating a function. The problem is that that your model and webserver do NOT scale in the same way, and if you don't realize this fast, you are going to be trying to fit a square peg through a round hole once you have adoption trying to make it work.
All models at scale eventually need to be executed by an async queue processor which is fundamentally different from a request response REST API. For simplicity managing this outside of the process making the web request will help you debug issues when people start asking why they are getting 502 responses. If you are forced to use python for this, I would always suggest of going to celery/huey/dramatiq as an immediate next step after the REST API MVP. I hear Celery is getting better but I have ran into issues over the year so it pains me to recommend it.
Going to be very interesting to see how they glue together R2, edge workers and sqllite. They can manage replication using R2 and make the sqllite process aware of this for eventual consistency. Having edge compute with edge data on a globally consistent data model is the dream.
Seems pretty obvious OP is addressing a conservative audience that tends to be pro-free-market. For better or worse it is a VERY political topic and this argument attempts identify contradicting agendas of conservatives that take issue with this.
Accidentally transferring half a million dollars to the wrong external account is going to be an absolute mess to recover. There are ways to stop it if you catch it RIGHT away, but it will turn into a nightmare pretty quickly.
Treating this transfer of WETH as just 'money' is an overly simplified model that is going to get someone burned in the same way as this reddit user. You are interacting directly with low level APIs that are irreversible while sending a lot of money to them, without knowing what they do. This is NOT good, and believe anyone without thorough understanding of these risks and how ERC APIs work should NOT be doing this.
There is an absolute need for cleaner UX on top of this with assurance/insurance to avoid this scenario (both of which exist and are being improved regularly). In the same way you don't directly interface with SWIFT APIs when doing bank transfers, you should not interface directly with ERC20 approve/transferFrom APIs in Ethereum, unless you really know what you are doing.
Vertica was very powerful for us but the separation of compute from storage was a critical feature of SF that motivated us to switch. We evaluated EON mode but SF was too easy. But from performance were also running nightly batch processing on a 22 node Vertica cluster that was taking 6 hours per night to run on highly optimized projections. We threw the same query at SF and 8XL cluster and it finished in about 30 minutes. The biggest difference however is cost where we are spending more on SF than we otherwise would have on Vertica.
Seems very useful. As someone who has recently started rolling out solidity contracts to learn and eventually create contracts with real money behind, having something that adds to my own confidence in the security of my code is helpful. Do you plan on eventually charging for the cli used in the marketplace demo?
You can short right now but there are heavy margin requirements. But you are absolutely correct that being able to short is critical here. BTC futures are cash settled, which relies on market forces to keep the future market tied to the underlying asset. However it seems to be OK so far bc CME futures are at 18960 and gemini spot is at 18500. We saw 15% spreads when CBOE launched last week so this is a good sign.
The comparison is mainly to put their available resources into perspective. Imagine the question: 'We have the entire economic output of Bulgaria in liquid assets at our disposal, what is the optimal portfolio we can construct'? And then re-ask yourself this question every second and just make sure you account for transaction costs as you shift stuff around. Also remember this is pre-levered money so deployed capital is a lot higher.
However for many of our users that are CC users they actually don't hit the $250 number most months so its actually cheaper to use consumption in many use cases surprisingly.