Need is a strong word, but it would drastically lower my stress levels and I could experiment more/move faster without obsessing over every tiny bit of spending.

Would it? Now you’re beholden to an investor that wants updates. People don’t want to pay for experiments but will pay for good execution on a viable business plan.

I don't think we necessarily need more dating apps, just better ones, but since online dating is currently more or less a monopoly from Match.com, all apps are pretty much the same, and they're designed to extract as much money as possible from people without even really trying to create good connections.

I think it would be nice to have some apps with a different approach.

how do you deal with the fact that some basic pages can have tens of thousand of tokens?

Right now, not much. The extension is fairly basic in that is just looks at the raw text + HTML and sends it to the LLM.

The benefit of this approach is it's very simple and easy, but the downside is it sends a lot of unnecessary tokens to the LLM. That drives up the cost, slows things down, and hurts accuracy.

I'm working on a few improvements now to improve this.

I remember there was something called readability for chrome which is just what browsers have incorporated as reader view. And mozilla even had a stand-alone version of it (1). Might be of interest to you.

[1] https://github.com/mozilla/readability

Firebase can save you a lot of time at the beginning of your project, but it have so many issues once you start to scale even just a bit, it's such a pain to work with on a real project.(safety issues, bugs, all kind of stupid limitations, your bill can go up extremely easily, it has so many shortcomings)

I'd recommend using some boilerplate from github in your favorite stack even if it might be a little bit longer to build a product with it.

Curious mind here: I have few projects running on Firebase. Haven't had any issues so far. What type of safety issues/bugs and limitations are you referring to?

> their vision is, at best, like that of a person with myopia seeing fine details as blurry

It's not that far from reality, most models sees images in very low resolution/limited colors, so not so far from this description

They didn't test that claim at all though. Vision isn't some sort of 1D sliding scale with every vision condition lying along one axis.

First of all myopia isn't 'seeing fine details as blurry' - it's nearsightedness - and whatever else this post tested it definitely didn't test depth perception.

And second - inability to see fine details is a distinct/different thing from not being able to count intersections and the other things tested here. That hypothesis, if valid, would imply that improving the resolution of the image that the model can process would improve its performance on these tasks even if reasoning abilities were the same. That - does not make sense. Plenty of the details in these images that these models are tripping up on are perfectly distinguishable at low resolutions. Counting rows and columns of blank grids is not going to improve with more resolution.

I mean, I'd argue that the phrasing of the hypothesis ("At best, like that of a person with myopia") doesn't make sense at all. I don't think a person with myopia would have any trouble with these tasks if you zoomed into the relevant area, or held the image close. I have a very strong feeling that these models would continue to suffer on these tasks if you zoomed in. Nearsighted != unable to count squares.

It seems to me they've brought up myopia only to make it more approachable to people how blurry something is, implying they believe models work with a blurry image just like a nearsighted person sees blurry images at a distance.

While myopia is common, it's not the best choice of analogy and "blurry vision" is probably clear enough.

Still, I'd only see it as a bad choice of analogy — I can't imagine anyone mistaking optical focus problems for static image processing problems — so in the usual HN recommendation, I'd treat their example in the most favourable sense.

My thoughts as well. I too would have trouble with the overlapping lines tests if all the images underwent convolution.

no one can, any company who tells you otherwise is lying to sell you a product

So you're telling me that we can't use AI to detect AI? It looks like you're an AI denier! Booooo! /s

There are multiple projects built to reverse engineer their API to avoid paying the API rates(it still makes economical sense to buy a subscription for this), it was obvious that they would have to increase their bot protections at some point.

Regular captchas are easily solvable by multimodal LLMs, we're reaching a point where what's hard for software to solve is also hard for humans.

At some point they'll probably have to charge by usage instead of a flat subscription.

I would have thought that rate limiting would be an easier solution to the problem of using chatgpt as an api.

It was rate limited since the start, the bots are respecting the rate limits, that does not mean they stop being a burden, they just create more of them.

I've worked closed to people that were interviewing SWEs, including people I would consider old, age was never the problem.

It was either:

A. This guy is worth twice our maximum budget

B. He's used to technical stacks that have absolutely nothing to do with ours

C. New grads perform better at leetcode than him(not saying that's a good metric, but that's not ageism)

D. Culture fit.

> Culture fit.

This is the biggest place where all kinds of biases slip in, including ageism. Culture is tied up in all of the protected classes, and any time that you hear "culture fit" used as a justification for turning someone down alarm bells should be going off.

The legitimate uses of "culture fit" as a filter should be itemized rather than lumped together: "he doesn't deal well with ambiguity", "she doesn't like frequent interruptions", whatever. Just talking about "culture fit" in the abstract is a lawsuit waiting to happen.

> New grads perform better at leetcode than him(not saying that's a good metric, but that's not ageism)

It often can be, as:

1. Younger folks have more recently done their degree and algorithms stuff 2. There tends to be more free time to grind leetcode at a younger age (family, responsibilities, lower energy can hamstring an older person here)

Ymmv, but I wouldn't say LC is neutral in this regard.

If your goal is to work for people that don't give a crap about you and don't respect you then yes. If you want to work people that actually believe you're more than a cell in spreadsheet then no, or at least not for the reason you mentioned.

Also I think that in a lot of cases it's more "we can't afford to pay a guy with 20 YoE" than ageism, maybe you're punching below your weight.

Recently I noticed that I get more answers for jobs that seems too hard for me than too easy.

The problem is how many jobs are there for engineers with 20 years of experience? This is related not not directly to pay.

You’d drop your experience because:

1/ very few roles.

2/ skills don’t match experience. If you’re not at principle level, this could be a flag.

2. is a bias we should avoid, going up from senior level is a choice, not a requirement or expectation. There are engineers who aren't attracted by the work at staff/principal level and it doesn't mean anything on their technical abilities to perform as an experienced senior.

This up-or-out worldview is not helpful, by definition there won't be enough spots in most companies for seniors to progress to staff, even less to principal, the funnel gets quite restricted there.

"Is RAM the current main limitation?"

(V)RAM+processing power+storage(I mean what kind of average user wants to clog half their hard drive for a subpar model that output 1 token a second?)