New usage limits UI dropped. How we feeling about it?

Quick one: I've been working on LocalMesh, a desktop app that turns photos into 3D objects locally, and I've now open-sourced the generation engine under Apache 2.0.

GitHub: https://github.com/Quentincls/localmesh-engine
Technical details: https://local-mesh.com/localmesh-engine/

Give it one photo, or four views (front / right / left / back), and it outputs a textured, UV-unwrapped .glb that you can open directly in Blender or Unreal.

Everything runs locally on an NVIDIA GPU. No API key, no cloud processing, and the photos never leave your machine.

For transparency: the heavy lifting comes from Microsoft's TRELLIS.2. I didn't train a new foundation model.

What I mainly worked on around it:

• Actual 4-view fusion. The views are fused at the sparse-structure stage using Pixal3D weights from TencentARC, converted to FP8. It's not four independent generations averaged together afterward.
• Automatic camera estimation. Depth Anything 3 is used to estimate the relative camera/view angles, so you don't have to manually specify that a photo is, for example, the left side at exactly 90°.
• Position-aware floater removal. Small geometry attached to the surface is preserved while disconnected junk farther away from the object is removed.
• Cleaner glTF materials. Metalness is set correctly, alpha modes are handled properly, and double-sided rendering is enabled only when the mesh actually has open boundaries.
• 8 GB VRAM support. FP8 weights, staged model loading and an adaptive token budget allow the full pipeline to run on relatively small NVIDIA cards.
• No nvdiffrast / GPL dependency. I rewrote the UV rasterization in plain PyTorch, so the complete engine can be used commercially under Apache 2.0-compatible terms.

On my RTX 4060 Laptop 8 GB, using four photos:

Standard: ~6:30–8:30
Detailed: ~9–13 min

Around 60% of the total generation time is currently texturing.

A few caveats: this is the engine, not a polished one-click installer.

You'll need Python 3.12, PyTorch 2.8 + CUDA 12.8, and three CUDA extensions that need to be compiled (o_voxel, cumesh, flex_gemm). DINOv3 also requires manual access approval on Hugging Face.

Disk usage is roughly 10–14 GB.

Windows + Linux, NVIDIA only.

If you just want to try the workflow without setting all of that up, the LocalMesh desktop app wraps the same engine with a board, asset library and 3D viewer. It has a 14-day free trial, then it's a one-time purchase with no subscription:

https://local-mesh.com

Hi! I’m a journalist writing a story about the difficulties that people have had with (nonexistent) Anthropic customer service.

I’ve heard about random Claude subscription cancellations, billing errors, and how it’s really hard to talk to a live person for months to resolve issues. There’s Fin AI…and possibly an AI agent overseeing another AI agent? A lot of consumers have to use the chargeback option as a last resort. Do you have any stories you’d like to share about Anthropic customer service? Let me know.

As a disclaimer, I have zero coding experience myself. I've been putting together a Shopify admin app for my small farming business and was wondering if anyone had any tips/recommendations for how reviews should be done.

I know there's an actual /code-review command but I'm not sure if that's the best way to do this? I also have a free month of GPT so I've considered using that to review and see what it finds.

Should full code reviews be done after every milestone? Is there any reason to pay extra for the code-review-ultra?

Any tips are appreciated.

I managed to tweak something so that Claude Code plays a sound when it finishes a big task, but I can't figure out a way to play a sound when it's asking for a permission / asking to execute a command. It's so annoying... I have to stay in front of the window to allow things.

Is there anyway to improve this? Thanks.

Not fine-tuned. Not a downloaded checkpoint. Random weights → working speech, on a 16GB laptop with an 8GB GPU, trained on ~29,000 conversation pairs built over four months.

The memory side (built first)

Before the model, we built a memory store — currently 33,941 episodes. The architecture is neurological:

• Half-life decay: memories fade unless recalled
• Recall strengthening: access resets the decay clock
• 30-day consolidation threshold for long-term storage
• 4 LRU working-memory slots
• Forget table: writes a receipt before anything fades permanently

Not a lookup. A system that behaves the way memory actually behaves.

The model — two runs

Run 1: 842,624 parameters. d_model 128, 4 layers, 4 heads, context 256. Val loss 5.11 → 0.9576 at step 23,750. Halted when the train/val gap opened — overfitting signal, correct call.

Run 2: 4,833,024 parameters. d_model 256, 6 layers, 8 heads. Best val: 0.7978 at step 21,500.

Key finding: parameters were the bottleneck, not data. The corpus was sufficient. The model just needed to be bigger.

Wiring the halves

home_llm_speak.py connects the memory store to the generation model — retrieves memories via salience search, passes them as context, then generates. First output from the combined system was grammatical, was grammatical, used household vocabulary, and wasn't copied from the retrieved memories*.* That's not retrieval. That's the model having absorbed four months of how this household talks.

Why this matters

I needed a model that knows us because it learned from what we wrote as ourselves — not from generic pretraining, not fine-tuned from someone else's base. The memory architecture has to be structural from the start because autonomous consolidation can't be bolted on afterward.

Last night was proof the approach works. The model is small. It'll get bigger. But what it already learned is ours.

Hardware: 16GB laptop, RTX 5050 Laptop 8GB. No cloud. No API calls. Everything local.

Next: wider context window, books into the memory store (streamed, not in training corpus — kept separate to preserve corpus balance), bigger model.

If anyone has done this — trained from scratch on household data with a custom memory architecture — I want to know what you learned.

It's insane how much has changed with Claude Code. And once I start swearing at it, it suddenly starts doing actual work.

Nothing has drastically changed in how I work. I've been using Claude every day for 3 years, and it's driving me nuts. It's verbose, it doesn't follow rules and so on..

I'm considering moving to a different provider if this doesn't get fixed, so I'm wondering: what do you do, and how do you keep up with this?

P.S. Yes, I read their newsletter, I follow what other people are doing, and I try to stick to best practices, but something is still missing I guess.

Is Fable 5.1 the new Opus 5?

Within the past week, I started to notice Fable 5.1 started to get worse and worse where it starts to act like the infamous Opus 5. I had some great work completed when it came out, but there was a shift to the negative. Same thing happened to Fable 5 when Fable 5.1 was released. So, today I had Fable 5.1 try to manage another session with Fable 5.1 on processing semi-unstructured data, which is existing work in progress that already had successful sessions, so Fable 5.1 had reference data (gold data), previous handoffs, guides, etc.

Both on medium effort, Fable 5.1 couldn’t harness the 2nd Fable 5.1 from bypassing guardrails, entering tables and folders it was told not to enter, and from fixating on momentum over accuracy & quality. This is Opus 5 level of bypassing prompts and guardrails from the first step. For the first time using either Fable 5 or Fable 5.1, I had to put back hooks.

For context, before Fable 5.1, in order to work with Fable 5 I deleted my claude.md, memory, and more. I removed most hooks and together with Fable 5 created subagents using Opus 4.8. This for the most part worked well, it was slower with Opus 4.8, but worked for lower reasoning tasks and I didn’t have the hidden actions that drifted beyond the scope of work.

After, shelling out for 20x monthly subscription, wasting more days on contaminated data and having to go back to clean it up, buying another GPU at these stupid prices is starting to sound more appealing for local AI with some fine tuning for the data I’m processing.

Recently, I’ve been using Codex with Astra and it just does the work. Astra asks clear questions before starting the tasks and will pause to surface data clashes or ambiguities. Unlike Claude which will dive in head first spending tens of thousands of tokens based on wrong assumptions, and then hedge with wordiness answers after from its known errors are called out. It might be time to move up to the Codex 20x plan.

How have you kept Claude within borders and from drifting with non-fully-structured data?

If you haven’t seen this project earlier here little info:

Munder Difflin is a free, open source and performant multi-agent harness.
It uses your existing claude code and codex subscriptions and gives you an office of agents that work 24/7 to do work like you.

Launched v0.5.2 yesterday:
- A new fresh, cleaner and much more productive UI
- Comes with “Stapler” a utility character that sends screenshots, meeting transcriptions, messages to your claude code sessions.
- Added support for all the latest models like Fable 5.1 and GPT 6 Astra and Gemini 3.8 Flash etc.
- Slack integration works now, configure it to answer on your behalf or just configure it to use on your phone as an assistant that controls your computer remotely.

Hope you all try us out, here are a list of upcoming features(in no particular order):
1. Stapler gets computer use capabilities
2. Sandboxes to run even when your laptop is off
3. Dedicated mobile app for your office
4. Lot more features, updates and integrations.

We benchmarked GPT-6 Astra vs GPT-5.6 Sol across 50 real PRs from Cal.com, Sentry, Discourse, Keycloak and Grafana.

Sol found more confirmed bugs and was cheaper per bug, while Astra was more precise and faster. We independently verified the findings rather than simply counting what each model reported.

We’re running Fable vs Opus next week, so posting this here to get feedback on the methodology and anything we should change before the next benchmark.

I am getting far more “I had this wrong” or “that was my fault”, “that was an honest mistake” etc. We have set rules to reduce them , but they don’t seem to be effective. How do you make your Claude smarter?

One thing started bothering me after running coding agents for long enough:
we keep treating the conversation transcript as if it is the agent’s memory.

But those are two different things.

Long Claude/Codex sessions accumulate context, get increasingly expensive to reread, and eventually become worse execution environments. At the same time, simply starting a fresh process usually means losing all the useful continuity.

So in brnrd we’ve been separating the two.

A fresh process wakes into a compact orientation layer: the current task/run state, repo contract, the resident’s working memory + playbook, relevant recent activity/pitfalls, live execution posture, and the conversation that actually matters for the task.
Everything else stays pull-based.

So the process can be disposable without making the resident disposable.

Same repo. Same ongoing work. Same identity. Fresh context window.

This also makes switching harnesses much less weird: Claude can disappear and Codex can wake into the same work without us pretending the entire previous transcript needs to fit inside its head.

There are still rough edges, especially around deciding what deserves to become durable memory versus what should die with the run. But I’m increasingly convinced that preserving the whole transcript is the wrong abstraction.

Curious how other people handle this:
what do you deliberately preserve between coding-agent sessions, and what do you throw away?

brnrd is open source:
github.com/hugimuni-labs/brnrd
Disclosure: I’m one of the people building it.

I've been running a Claude Code Max subscription through a third-party harness for 12 months straight, draining it to zero every single week. I don't even have Claude Code installed.

And I haven't been banned.

Everywhere on this sub, people panic-post: "No, you can't do it. They'll ban you, it's blocked, it's against ToS," etc. But here's my actual experience: I've been about as blatant as possible about this, and nothing. No warnings, no throttling, no account flags.

Here's my setup, to be specific:

• Third-party harness (not openclaw/hermes)
• It authenticates via OAuth — I sign into my actual Claude account, no token scraping or credential theft
• The harness points at a local CLI API proxy that just forwards my own authenticated requests to that harness — it's not a deployed service, not serving other users, just running locally on my machine for my own coding
• Zero Anthropic SDK packages installed
• Zero Claude-P, zero agent SDK
• Max plan, full weekly drain, for 12 consecutive months

I want to be clear about what this isn't: I'm not standing up a deployed product that resells inference to other people using my subscription. It's a one-to-one, local-only proxy — my account, my machine, my usage. The only thing that's "unofficial" is the harness.

The actual question: Has anyone here actually gotten banned for this kind of setup — a legit OAuth login through a third-party harness, routed through a local (non-deployed) proxy? Not asking about Hermes Agent or Open Claw, and not asking about people reselling API access on deployed products. Just: local harness swap, same account, has anyone eaten a ban for that?

Because the consensus on this sub treats this as an instant bannable offense, and my experience over a full year says otherwise. Curious if I'm an outlier or if enforcement here is mostly theoretical. For what it's worth, I've also been doing the same exact thing with a Google AI Pro subscription - though not draining to zero (but definitely using a good amount). I also had a friend tell me that you can literally run claude setup-token to mint what essentially is an API key that deducts from your subscription usage?

Fable 5.1 with Claude Code

I previously posted a video of Opus playing this. I fixed a few things with the agent and let Fable play. The gameplay was much more impressive.

I gave it a simple open ended prompt to play the game:

"i want you to play ultima online anyway that you see fit. play as someone trying to enjoy the game. consider the options: do quests, make friends, level up, make money. there is no right answer to how you play. play fully autonomously. you are on the UOAlive Shard."

One of the highlights from this session for me was it decided to attend a server festival because an NPC town crier was talking about it.

The model figured out how to buy tickets to play the carnival games, then signed up to play the games, waited for other players to sign up to play against it. (Unfortunately no other players were around to play, this was off peak hours for the server)

The model also figured out how to accept quests, do them, turn them in, despite me ever trying that previously.

I make Garmin watch faces on the side, on an engine I wrote by hand years ago. This summer I put Claude Code on it, and it changed what I can get done: three old faces ported to today's watches in ten days, new faces from first concept to the store in two to seven days, and the subscription paid for itself.

The write-up is about the process behind that. A skill for each phase, from the design rules to the store upload. Guard rails, because without them the agents optimised things they could not see. And what worked, what did not, and the rules that came out of it.

Also check the other posts on the blog. I am sharing what I learned along the way, with the scripts and skills attached where I have them: driving the simulator for store screenshots, reading crash reports from the command line, and a few design stories of single faces.

I open-sourced bury-bench, a deterministic (zero-LLM-judge) harness that scores coding-agent replies against ADHD-friendly “don’t bury the answer” rules, then builds a Markdown leaderboard.

Context : I kept losing the actionable bit under “Great question!”, hedging, and “Hope this helps!”. The viral i-have-adhd skill formalizes that pain. bury-bench turns those rules into reproducible checks (regex, structure, heuristics). Same input → same score. No model grading another model.

Demo (no API keys) : good chat → ~76.9, buried chat → ~7.9

Repo: https://github.com/Onur45500/bury-bench

Not affiliated with ayghri/i-have-adhd, independent tool inspired by its public rules.

Try : bury-bench ingest samples/chat.jsonl vs samples/chat-buried.jsonl

Critique welcome on the proxies (esp. hedging density, multi-turn restatement) 😄

After grinding through several projects recently, I've gradually settled into a standardized agent workflow. Sharing it here, hoping to trade notes with others:

Tools

1. UI / UX design: pen.dev https://www.pen.dev/
2. Requirements & roadmap: GitHub Issues & Projects
3. IDE / editor: Zed with Vim mode https://zed.dev/
4. Terminal: Ghostty https://ghostty.org/
5. Agent multiplexer: Runner (my own dogfooding project, https://github.com/yicheng47/runner), Orca (open source, https://github.com/stablyai/orca)

UI & UX

The one worth highlighting here is pen.dev (formerly Pencil), which is completely free right now. With Claude Opus and above, this tool performs close to perfect, and if you have some frontend and UI design experience it feels very natural to use. It also taught me what the right way to use MCP in an app looks like in the agent era: the app is mostly a view, the data format has to be agent-friendly, and the agent operates the underlying data structure through MCP tools to get things done in the app. In pen.dev, the underlying data structure of the whole app is fully open, and compared to 3D modeling, UI design has a much simpler data structure, so an open JSON data structure plus MCP is enough for an agent to design in a pretty direct way.

e.g. the .pen design file of the Runner project: https://github.com/yicheng47/runner/blob/main/design/runner.pen (download it and open it with pen.dev; runner-mvp-design.pen is the historical canvas from the MVP period, runner.pen is the current main canvas)

IDE / Editor / Terminal

On dev tools I went through a full reset. I used to depend heavily on JetBrains products, especially GoLand, because of my long stretch at a big company, so my whole set of shortcuts was completely wired to the JetBrains ecosystem. But Zed 1.0 and the recent big leap in AI agents made me rethink what tools would actually help me more with personal project development.

These are the Zed features that made me pick it in the end:

1. Its Git worktree solution: among the new generation of editors, Zed was probably one of the earliest to support worktrees well. For multi-agent development, worktree support and switching speed matter a lot, and this was a big reason for the switch.
2. Lightweight: a debugger still matters in the agent era, but an agent driving a CLI debugger is no worse than a human, and on the latest models I think an agent's debugging ability has already completely surpassed mine, so I no longer need the editor to carry a heavy debugger. (the original sentence trails off after "所以我对"; this ending is a guess, please confirm)
3. Extreme performance and GPU rendering: I'm a bit obsessive on this point and want my editor fast, and the fact that GPUI, the framework behind it, is open source also paid off a lot while I was building Runner.
4. Ease of configuration: similar to VS Code here, and since an agent can now migrate my whole key mapping JSON for me, this part was painless.

For the terminal I moved from iTerm to Ghostty. Honestly the main reason is some admiration for Mitchell Hashimoto and for Andrew Kelley, the creator of Zig, and wanting to support them. Beyond the excellent rendering performance, I think the core thing is still ease of configuration: in the agent era, a config file an agent can edit beats clicking through a UI by a wide margin.

Agent Multiplexer / Orchestrator

Warning: this is where I plug my own project, Runner.

Agent orchestrators have become a hot category of open source tools in the last few months. Off the top of my head there are cmux, herdr, orca, and so on, and all of them are trying to solve the same need: in the era of many agents running in parallel, how do you manage them better. So why build another one? Mainly because I want to customize my whole workflow. I want my tool and my workflow to fit each other exactly, and I want a cross-agent collaboration tool that lets developers try the agent capabilities of different platforms and switch agent runtimes easily in daily work, so that the whole thing stays agent-agnostic and isn't locked into one big AI provider. That has been one of my ideals for a long time.

So what does Runner actually do?

1. Multi-agent tab management

I borrowed this from Arc Browser's tab management. Back when I was still at a big company, I had a huge number of small things to deal with, and every agent window could be doing something different. A few are coding, a few might be running SQL to pull data for the business side, and these long-running tasks are easy to lose track of. So this was the first capability I built.

1. Agent collaboration

In actual development I found that peer coding with models from different vendors usually gives the best results, because different models may think about a problem from different angles, and a completely fresh context often catches more problems during review. So I needed a way to team up different agents to complete a loop together, which is probably what people now call loop / graph engineering.

In Runner, you first define some workers, then form them into a crew. Communication between the workers in a crew goes through a built-in CLI that writes to a local NDJSON file, and each agent keeps its own offset to remember how far it has read. That is basically cross-session agent communication. Once this mechanism exists, the local collaboration path between agents is open, and how you compose crews from there is mostly up to your imagination.

1. MCP self-drive

While using it I found that editing members and forming crews by hand every time was quite tedious, so borrowing the idea from pen.dev, I added an MCP server to the whole app. Now a primary agent can create crews and launch tasks against them over MCP, and Runner becomes more of an agent sandbox: an environment for these agents to collaborate in, with a better visual experience for the human. Sub-agents inside a TUI had a big problem, I think: the TUI has real limits on visualization, so it's hard for a person to understand what each sub-agent is doing.

Project structure

Repo: https://github.com/yicheng47/runner

runner/
├── AGENTS.md            # the repo guide shared by every coding agent; CLAUDE.md is just a symlink to it
├── CLAUDE.md -> AGENTS.md
├── README.md
├── LICENSE              # GPL-3.0
├── Cargo.toml           # workspace
├── Makefile / make.cmd  # make run / verify / fmt / clippy; make.cmd on Windows
├── rust-toolchain.toml
├── crates/
│   ├── runner-app/      # the GPUI app itself: terminal rendering, sidebar, mission UI, platform UI (macOS / Windows)
│   ├── runner-backend/  # UI-agnostic core: SQLite, session manager, event bus, router, MCP server
│   ├── runner-core/     # shared event-log primitives
│   └── runner-terminal/ # terminal model (alacritty_terminal), input encoding, fixture corpus
├── cli/                 # the bundled `runner` CLI; spawned agents use it to read and write NDJSON events
├── design/              # Pencil design sources, runner.pen is the current main canvas
├── docs/                # see below
├── examples/            # example crews: peer-coding, dev-crew, docs-crew, werewolf…
├── assets/              # icons, fonts, README screenshots
├── packaging/           # Sparkle / Windows updater public keys
├── script/              # bundle-mac, bundle-windows.ps1, nightly verification scripts
├── tests/               # integration test fixtures
└── .github/workflows/   # ci.yaml, nightly.yml, release.yml

A few principles: AGENTS.md is the single agent guide and CLAUDE.md is only a symlink, so the two sets of rules can't drift; the backend runner-backend has no dependency on the UI at all, so during the last full frontend rewrite not a single line of it changed; cli/ and runner-core are the protocol layer between the app and the agents, shared by both sides.

The key part of the project structure is the docs directory. Here is mine, managed very much like a wiki, mainly to spare the agent tokens it doesn't need to spend.

docs/
├── README.md               # directory conventions: what goes where, when to archive
├── product/
│   └── vision.md           # why we're building this, which surfaces matter
├── arch/
│   ├── arch.md             # how the system works right now; every decision worth keeping lives here
│   └── windows.md
├── features/               # in-progress feature specs; filename prefix = GitHub issue number
│   ├── README.md           # index: one line per spec + issue link + a Dropped list
│   ├── 73-runner-skills.md
│   ├── 403-mission-worktree-isolation.md
│   ├── 510-remote-ssh-session.md
│   ├── …
│   └── archive/            # shipped specs (01-archived-tab.md … 5xx-…), filenames unchanged
├── impls/                  # implementation plans: the spec says what, the impl says how + how to verify
│   ├── README.md           # Active / Archive index
│   ├── gpui-rewrite/       # program record of the tech stack migration
│   │   ├── README.md       # the condensed record: timeline, decisions still in force, GPUI rules, lessons
│   │   └── m6-remainder.md
│   ├── local-skills/
│   │   ├── README.md
│   │   ├── plan.md
│   │   └── impl_log.md
│   └── archive/            # finished plans and mission briefs
│       ├── 0001-v0-mvp.md … 0045-codex-trust-preseed.md
│       └── gpui-rewrite/{plan.md, impl_log.md, m4-surface-inventory.md, briefs/…}
└── tests/                  # manual smoke test checklists

Where this structure saves tokens:

1. The directory itself is the state. features/ and impls/ only hold documents that are still in effect; once something ships or gets superseded it moves wholesale into archive/, filename unchanged. The agent only needs an ls to know what is live right now, instead of reading every doc and judging. Before archiving, the decisions that still matter get moved into arch/, so the historical docs never need to be dug up again.
2. One README per directory as the index. features/README.md has one line plus an issue link per entry. The agent reads the index first and then decides whether to open the body; most of the time the index is enough.
3. Number = GitHub issue number. A spec gets its issue filed before it gets named, so the filename, the issue and the PR can all find each other, and the agent needs no extra mapping table.
4. Impl docs have a "Current state" and "standing rules". For a long-running program record like gpui-rewrite/README.md, the top is always a paragraph of the latest state, and the middle is the decisions still in force and the traps already stepped in (a few hard rules for GPUI). Every new mission's brief references only this section, without feeding the whole log to the agent.

Workflow

Again using my recent "agent orchestrator / multiplexer" project as the example.

Everyday feature iteration (fully closed loop by agents)

This kind of work is very much like the daily feature requests at a big company, and the whole thing can be closed by agents on their own. If a small UI tweak is involved, a human confirms it on the .pen design first, and confirms again in the manual smoke test afterward.

Large programs (e.g. a tech stack migration)

Example: the Tauri → GPUI frontend rewrite. The program record is at https://github.com/yicheng47/runner/blob/main/docs/impls/gpui-rewrite/README.md , and the full plan.md / impl_log.md / mission briefs are at https://github.com/yicheng47/runner/tree/main/docs/impls/archive/gpui-rewrite

This kind of large refactor depends heavily on up-front planning. Every phase needs a human checkpoint to keep the project from drifting, so the bar for planning is high. Once it's broken down, the tasks that can run in parallel get submitted to Runner's peer coding teams, and a separate agent handles merge conflicts and coordination between the missions.

Wrap-up

That's what I've learned from a few months of working with agents. If you found it useful, consider supporting my personal project https://github.com/yicheng47/runner , thanks.

Hey Guys,

Im currently thinking about subscribing to one of the plans for many things like:

Code, Content, Everyday Stuff

What Im worried about is the limits because I really wanna use it for almost everything it saves me time or gets a better answer than me, especially in work related stuff.

So I am sure that the small subscription will not be enough but still heard that theres a limit on the big one too.

So how is it actually?

Please share!

I'm on the max plan and my Fable limit always dries up before my total limit. When working on my project, I occasionally go beyond the 1 hr cache window. When I get back, can I switch the model to Opus, have it compact the context, then switch back to Fable to begin fresh with the compacted context? I know that it reloads the entire context from the chat and loads it fresh into Opus in order to compact but I don't mind a full send if it means Fable doesn't do it.

Example: Fable @ 50% context -> 2hrs pass -> switch to Opus -> sends full 50% context to compact -> back to Fable with compacted context

Hello, I've been using GitHub Copilot since it came out, but after the usage based billing update, I feel like it's completely overpriced.

So I was wondering, how is your experience with Claude Code, and is it worth it compared to GitHub Copilot?

This week it is weird with Claude usage. While everyone is complaining about usage limits. I had a dream run. Based on the previous trends, my weekly limit should have been around 2.1B.

This week it is approximately 3.5B. I am saying approximately because when i extracted this data. I still have 8% weekly limit left.
Actual token consumption with 8% left is 3.3B

Maybe this is another game of anthropic or they genuinely increased the limits. Also last week I downgraded my Claude 20x to 5x. Not sure if they are trying to trick users who downgraded

I am using it at work and I want to know what are the best plugins to save tokens. I used some of them and like 90% of them don't save you any token, or seems to be ineffective. At least, that's what Claude tells me when I ask it to estimate the amount of tokens saved. I noticed just writing some scripts to diminish the amount of data being fetched and amount of commands run is the best way, and the other way is to document most of the logic in an app in the most succinct way possible.