They could've come out and said "Hey, due to increased demands, we're reducing the limit", but instead they chose to do a rug-pull, in the guise of "off-hour" limit increase, while absolutely butchering the limit in both peak, and non-peak hours.

Additionally, they chose to gaslight the users, wait until people make a lot of noise, "investigate", and reach the conclusion that the same users that have been using their tools, with the same exact models and the same exact workflows for months, suddenly can't approximate / estimate their own usage compared to previous months.

Such a bad business etiquette, but nothing unexpected.

the "useCanUseTool.tsx" hook, is definitely something I would hate seeing in any code base I come across.

It's extremely nested, it's basically an if statement soup

`useTypeahead.tsx` is even worse, extremely nested, a ton of "if else" statements, I doubt you'd look at it and think this is sane code

  export function extractSearchToken(completionToken: {
    token: string;
    isQuoted?: boolean;
  }): string {
    if (completionToken.isQuoted) {
      // Remove @" prefix and optional closing "
      return completionToken.token.slice(2).replace(/"$/, '');
    } else if (completionToken.token.startsWith('@')) {
      return completionToken.token.substring(1);
    } else {
      return completionToken.token;
    }
  }

Why even use else if with return...

> Why even use else if with return...

What is the problem with that? How would you write that snippet? It is common in the new functional js landscape, even if it is pass-by-ref.

Using guard clauses. Way more readable and easy to work with.

  export function extractSearchToken(completionToken: {
    token: string;
    isQuoted?: boolean;
  }): string {
    if (completionToken.isQuoted) {
      return completionToken.token.slice(2).replace(/"$/, '');
    }
    if (completionToken.token.startsWith('@')) {
      return completionToken.token.substring(1);
    }
    return completionToken.token;
  }

I always write code like that. I don't like early returns. This approximates `if` statements being an expression that returns something.

> This approximates `if` statements being an expression that returns something.

Do you care to elaborate? "if (...) return ...;" looks closer to an expression for me:

  export function extractSearchToken(completionToken: { token: string; isQuoted?: boolean }): string {
    if (completionToken.isQuoted) return completionToken.token.slice(2).replace(/"$/, '');

    if (completionToken.token.startsWith('@')) return completionToken.token.substring(1);

    return completionToken.token;
  }

I’m not strongly opinionated, especially with such a short function, but in general early return makes it so you don’t need to keep the whole function body in your head to understand the logic. Often it saves you having to read the whole function body too.

But you can achieve a similar effect by keeping your functions small, in which case I think both styles are roughly equivalent.

I'm not that familiar with TypeScript/JavaScript - what would be a proper way of handling complex logic? Switch statements? Decision tables?

Here I think the logic is unnecessarily complex. isQuoted is doing work that is implicit in the token.

Fits with the origin story of Claude Code...

insert "AI is just if statements" meme

useCanUseTool.tsx looks special, maybe it'scodegen'ed or copy 'n pasted? `_c` as an import name, no comments, use of promises instead of async function. Or maybe it's just bad vibing...

Maybe, I do suspect _some_ parts are codegen or source map artifacts.

But if you take a look at the other file, for example `useTypeahead` you'd see, even if there are a few code-gen / source-map artifacts, you still see the core logic, and behavior, is just a big bowl of soup

Lol even the name is crazy

Funny how before the announcement, people who were experiencing this were being gaslighted on different platforms, to think they have a "skill" issue using Claude Code

Additionally, this was practically predicted and expected by so many people, the second the off-hours increase was announced.

Shoddy company

Its a sign that they cannot simply raise the price of existing paying customer's to avoid putting on limits - and/or - convert more free users into paying customers.

The longer this goes on the more it becomes clear Google is going to be the last one standing.

Why because 7% of people complain the loudest? I would imagine that most power users have big followings on X, Reddit, HN, etc.. but that hardly reflects the reality of what most people are experiencing.

The remaining 93% exist mostly because these 7% were loud.

Users who aren't using their quota will gradually disappear when that 7% starts being loud in the other direction.

Are you within an organization? they can control which subset of models are available to you

maybe it's related to the supply chain risk designation

No, just a regular Pro subscription. Apparently it's not just me, Github seems to have removed these models from the "Student" subscription [0] but it seems as it was also removed from regular "Pro" subscriptions as there are many reports on their discussions. [1]

[0] https://github.com/orgs/community/discussions/189268

[1] https://github.com/orgs/community/discussions

Yeah, I got the email that they removed them from the student plan:

"As part of this transition, however, some premium models, including GPT-5.4, and Claude Opus and Sonnet models, will no longer be available for self-selection under the GitHub Copilot Student Plan."

They specifically said this was primarily for student plans. I'm surprised they did this for the normal pro plans too; it's likely a mistake since the plans page[1] still says that the models will be available.

However, TBH, I've never liked Microsoft's flavor of these; they always seem lobotomized compared to using the models directly in Claude Code / Codex. I rarely use AI in VS Code because it's just bad.

[1]: https://docs.github.com/en/copilot/get-started/plans

I was looking at the Meet repository as an example, people literally don't know how to write React, without drowning in `useEffect`, `eslint-disable`, `any`. React has it's issues (and a ton of them), but writing code like this, I expect it to end up exactly like Microsoft Teams quality wise.

Honestly, at that point, it's indistinguishable from LLM slop

Why would one decide to even go with React in recent years anyway? Strangely I've seen it happen a lot too.

I'd have thought that Vue or Svelte would be a slam dunk choice. Do project managers love bloat and lag or something?

I personally don't mind React, but I do acknowledge, after using it for a couple of years, that it seems to be a magnet for issues. It's the kind of framework, where if you're not writing properly, mostly like [Thinking in React](https://react.dev/learn/thinking-in-react) (with some caveat for niche performance optimizations), you're going to have a rough time, and you're going to make life miserable for anyone that does know what they're doing

It has a weird learning curve, where you can ship something somewhat working, fairly fast, but to write it properly, with no bugs, you need to understand a lot of niche React-specific things, and their solutions (and those solutions are never useEffect https://react.dev/learn/you-might-not-need-an-effect).

At that point, I wouldn't recommend it to anyone who isn't already experienced with React. It's been an uphill battle, trying to work with anyone that is using React, without understanding how to write properly.

The reactivity model fits well in real-time applications; perhaps SolidJS is better alternative in this context, though.

I have met very few devs who know how to avoid useEffect

As impressive as it sounds, the game is riddled with people cheating

I'm not sure if React Native is much different from React itself, but a few things that made me give a side eye, when looking at this write up:

1. The instant 5 levels of providers (and additional one later) seems excessive.

2. The usage of useAnimatedReaction which seems almost like a "useEffect" kind of hook, which was sprinkled in almost every code block.

3. The imperative size calculations, does React Native not support any responsive like constructs? I recall solving the same problem by separating "history" and "tail" and having a "grower" component, without having to use any JS (purely html & css), albeit it being web and not native.

4. Personally, when I see something like the scroll code, where you have to call scroll, wait a frame, call scroll again, set a timeout, scroll again- I would have raised my eyebrows about the architecture / code flow way before that.

5. the amount of "floating" hook calls like useKeyboardAwareMessageList() useScrollMessageListFromComposerSizeUpdates() useUpdateLastMessageIndex()

that don't return anything, always makes me raise an eyebrow, usually in React Web codebases, where the users just spam useEffects and effect chains.

Not sure if it's just my ignorance in React Native, but if I had seen the equivalent in a React Web app, I would've been baffled

What does git think of the tree after you pull? Does everything seem fine to git, but jj shows a conflict?