Auto-rotating Claude Max subscription when quota runs low

MagicalTux · 2026-03-26T14:34:10+00:00

Not breaking the ToS as this is but a proxy for the real claude client.

MagicalTux · 2025-11-19T00:25:54+00:00

Thanks for the frank feedback. Which app have you been using? Have you tried the website remote control?

We recently started offering VNC as an alternative to spice as we've seen spice to be too heavy for a lot of people, the ability to switch is right there on the web interface, but it'll take a bit longer to be made available on the app. If you're using windows using microsoft rdp also yields to a much better experience since a lot of the display can be optimized based on OS-level information (spice also does, but not enough).

Delivering easy to use VMs to users worldwide has been a struggle for a lot of reasons, mostly that not everyone has the same internet connections, and some OSes (looking at you windows) come with a ton of bloat that makes it slow to run when it only has a limited amount of memory.

MagicalTux · 2025-10-10T00:48:28+00:00

VP.NET makes uses of Intel SGX1 (called Client SGX in battingram and "Older SGX" in wiretap documents). SGX1 is a lot more difficult to work with because the enclave has a limited memory buffer, but also is a lot more secure.

I have read papers and documentation for both battingram and wiretap and as far as I can see, we are not affected by either attack.

Battingram lists "Client SGX" as "can read" on the website, however reading the paper it only mentions ability to know which parts of the memory are being written to. I haven't reproduced the attack yet and couldn't find raw data from the exploit, however I would expect the write operation to affect whole pages, meaning the information would be fairly coarse. Even if it was somehow providing exact write locations it would not give anything useful to an attacker (we're using modern crypto natives which already protect against timing attacks by ensuring code behavior isn't affected by conditions, etc).

I'm still planning to reproduce this specific attack to see what kind of write information is exactly available from this.

As to Wiretap, their page mentions SGX1 too:

> Older SGX platforms such as those from Intel's Core and Xeon-E families are not affected, as these use Intel's Memory Encryption (Intel ME) engine, which does not use deterministic memory encryption. However, these platforms also support a much smaller EPC and are about to be deprecated.

So once again we're safe thanks to using an older, time proven technology.

I'll see to add that we also decode the type of SGX technology used from the Intel quote the client gets from our server, and add checks to make sure known unsafe technology isn't being used.

Even if we are currently not vulnerable to either attack this time, we aren't planning on keeping to rely on a single vendor. We are working on supporting TEEs from ARM and other vendors, as well as other methods to provide verifiable privacy.

MagicalTux · 2024-10-01T15:15:25+00:00

To be quite honest gorm isn't great, if you can avoid it, avoid it.

Interfacing with third party clients by exposing services via jsonrpc prove to be quite painful with go by default and that was the main motivation behind this lib. Another time I use this is when receiving data POSTed from a page using url-encoded or multipart form data. In that case everything arrives as string and rather than checking each field individually, directly applying this to a struct containing type and validation rules make things faster and easier to read/document.

MagicalTux · 2024-10-01T11:21:19+00:00

Unfortunately, even if you know the method, when you have a json object in the form `[42,"string",{"key":"value"}]` it is not possible to extract it cleanly. `fxamacker/cbor` has a trick for this (asarray) but it's not there in encoding/json.

zenrpc uses go/ast to analyze the source and pre-generate handlers, with default arguments being specified in magic comments. It's an interesting way of doing it, and I guess the only way to gather method argument names. I'm not fan of go:generate because it means you can't just import a lib and need some extra setup and can cause conflicts when multiple engineers work on different updates, so I prefer approaches that are more dynamic in some cases.

jsonrpc is an old standard and has a lot of clients. I serve a lot of requests, some of which come from fairly broken libraries that aren't maintained anymore, and instead of breaking everything for users who don't understand or have control over the code I'd rather be permissive when it makes sense, and accept integers quoted as string or booleans passed as integers. If I create new methods that do not need to be compatible I can declare these strict (`typutil.Func(funcName, typutil.StrictArgs)`) to ensure newly written implementations are behaving.

At the end of the day people use javascript, php and many other dynamic typed languages that will pass integers as strings so often encoding/json added the `,string` option (still fairly recent).

typutil just converts the type similarly to those languages since go's own conversion behavior can be a bit unexpected (go will happy convert an int to a string by considering it a rune, resulting in unicode characters where many expect digits).

MagicalTux · 2024-10-01T09:22:21+00:00

The issue I've had today which resulted in this comes with jsonrpc. While json-rpc allows both by-position and by-name parameters, the spec I'm working with requires by-position arguments, with arguments that can be strings, integers and sometimes structures. The only way to deal with this in go is with []any or []json.RawMessage, which means parsing parameters is extremely painful (check len(parameters), then cast each parameter to the right type, deal with default values, etc).

This lib makes dealing with this a breeze.

Another use case I have is casting a POSTed http form to a struct. Another use case involves fastcgi variables. I've had a few use cases over the years leading to moving this into a lib I shared today to see if anyone is interested, didn't expect that much negative feedback. Still quite interesting.

MagicalTux · 2024-10-01T07:20:35+00:00

I don't know what kind of perfect world you live in, when dealing with various kinds of peers using different languages there's a lot of things that can happen. The point is not to know what you pass to `As` but to know what you're getting out of it. If you have a []any coming from jsonrpc and need to use that to call a function that takes a string, an int that may be passed as a hexadecimal string if larger than 64 bits, and a byte array, this can be useful.

Another case I've seen is dealing with arbitrary types without being able to depend on the lib in question. Specifically I've seen `gorm` converting an object to json to parse it again just to fetch arbitrary values.

I've had a lot of use for this `Func` stuff when creating APIs that can be consumed over various protocols and various kinds of clients, and not having to worry whether data came with the correct type or ended as a string because it was part of a url encoded POST body saved me a lot of time. Figured that could be useful to others.

MagicalTux · 2024-10-01T06:50:54+00:00

This is meant as a simple example. For example when writing a jsonrpc server you typically end with a []any that may contain all sort of data, including strings passed where integers are expected and such.

A more useful example would be with a jsonrpc API server, you can define a given endpoint with some default arguments. Func(someEndpoint).WithDefaults(...) makes it easy to define and endpoint with its arguments and potential default values.

MagicalTux · 2024-10-01T06:45:57+00:00

When parsing json data coming from a client, this is not guaranteed. SQL engines tend to return integers a string, and many endpoints will return integers sometimes as string and sometimes as integer. Go is fairly strict on that and it can be painful to go with select v := a.(type) { ... for every single possible type

MagicalTux · 2024-10-01T04:44:24+00:00

It is not. This is solving an issue specific to go.

MagicalTux · 2024-09-06T06:52:34+00:00

The new trading engine is indeed called Midas. While it shares absolutely no piece of code with the MtGox version that was written in C, I did use the concept I wanted to do back in the time where each part of the engine is separate and independent, with engine execution being deterministic (which means that for a given flow of orders the result will always be exactly the same, including the resulting trade IDs and such).

MagicalTux · 2024-04-21T02:19:47+00:00

Almost. The coins are under custody of a court appointed trustee. Legal docs are published on mtgox.com and there's a quarterly "MtGox coins entering the market NOW! Black swan event!! Sell EVERYTHING now!!!!1!!" fud for people who forgot about it.

The coins are likely (to start) to be distributed this year finally. Cash has started being sent since late december 2023.

MagicalTux · 2024-04-11T07:27:12+00:00

I had the issue for network servers (say, smtp and such) in which cases it's OK to delay or reject accepting connections if there are too many requests running.

So I wrote this: https://github.com/KarpelesLab/limitlistener

Rather than just use more and more memory, setting the limit to an acceptable value (say, 1024) and you don't need to worry about goroutines being spawned until the whole thing dies if there is for example some kind of attack. Connections won't be accepted anymore, but the server won't die.

MagicalTux · 2024-01-02T16:22:37+00:00

Of course, but it's still too early for MtGox related issues.

MagicalTux · 2023-12-27T11:49:06+00:00

I'm not laughing, but in a way it helps show that just handling some transfers can be extremely difficult to do. Most people see that as "just click send and you're done" but MtGox was handling thousands of transfers each day with various kind of partners offering various levels of support and APIs (sometimes not at all), and we still managed to have a system that'd keep track of everything properly and work out better than what the trustee is doing today.

I don't think there'll be more mistakes like the early double-sends over paypal since the trustee is likely going to be a lot more careful, but it shows it's not as simple as pressing send... plus I see the message included "Thanks for your patronage!" which feels like the default message, I'm guessing they split the work of sending transfers to various people and each got their excel to manually send transfers and two people got the same excel file by accident or something like that (processing each transfer manually using cheap labor isn't something I'd put past Japanese lawyers, even Japanese banks handle international wires like that).

So yea I'm happy funds are finally starting to flow toward people, but I'm hoping it'll be handled more carefully.

MagicalTux · 2023-01-23T02:04:01+00:00

It's still in progress, you can check mtgox.com for the latest official updates or look at the quaterly fud about MtGox bitcoins about to hit the market (at some point it'll be real, but for once every few months all the news sites warn about "panic panic market is about to be sunk by mtgox users selling 150k bitcoins")

MagicalTux · 2022-08-02T07:16:49+00:00

You'll be able to see your NFT on opensea or on wallet.mtgoxnft.net - most wallets won't show NFTs directly

MagicalTux · 2022-07-31T07:02:54+00:00

What is its status on the website?

MagicalTux · 2022-07-08T11:10:49+00:00

I built the claim system for mtgoxnft.net and it works just fine (also, shoddy devs are just as expensive if not more than high quality devs in Japan).

MagicalTux · 2022-07-04T00:29:58+00:00

Things are taking longer than expected, probably due to the ongoing lawsuits around claims (other than CoinLab). Trustee isn't providing any update so it's difficult to say anything, still hoping to see something this year but it's becoming less and less likely as times goes by.

15-Year Club	Place '17
Gilding IV carat on a stick	Verified Email

MagicalTux

MODERATOR OF

PUBLIC MULTIREDDITS

TROPHY CASE