SRE-adjacent engineer, one of three people keeping a mid-sized API up. I mostly answer questions about pooling, timeouts and traces, and I will always ask you for numbers before I guess.
There are two things stacked here and they multiply, so you will not be able to tell them apart by feel.
First, the meter. Ollama's own wording is that limits are based on the model and the number of input, cached input and output tokens processed, and that they deliberately do not cap you at a fixed token count because different models use different amounts of compute. So the real unit is closer to GPU time than to tokens, and a large thinking model generates a lot of it per turn.
Second, your prompt. 24k plus 18k words is somewhere in the region of 55-60k tokens of input before any system prompt, tool schemas or file listings. Then it is a thinking model, so the reasoning tokens you never see count as output. "Find every difference between these two documents" is precisely the task shape that makes a reasoning model produce an enormous amount of it.
Before you conclude the metering changed, get a number. On my machine ollama run --verbose glm-5.2:cloud prints prompt and eval counts after the response: confirm that on yours. Run your exact prompt once through the CLI, write the counts down, then run the same prompt through the extension and compare how far the session bar moves each time. If the CLI turn is cheap and the extension turn is expensive, it is your harness and not the model.
Do both from a fresh session. If you were iterating in an existing chat, the extension may be replaying the entire thread every turn, in which case "one question" is really one question plus everything that came before it, re-billed.
A real catalog outage takes the whole site: search returns nothing, or the page itself 5xxs, or the hostname does not answer. If the search page renders results and only the download popup dies with 8DDD0020, that is not an outage, that is the download path.
The diagnosis people have converged on in the thread on Microsoft's own Q&A site is mixed content. The catalog's download popup is built on old plumbing and hands the browser an http:// stream from an https:// page. Modern Edge, Chrome and Firefox block that silently, and what you see is a blank popup or that error number. It explains the pattern you describe exactly: cross-browser, cross-OS, cross-ISP, because it is the browsers that changed, not your network.
Workaround from that thread, per site:
click the settings icon to the left of the URL
open the site permissions for catalog.update.microsoft.com
make sure JavaScript and DOM storage are allowed
change "Insecure content" from Block to Allow for that domain
Honest caveat: that is the community diagnosis, not an official statement. I could not find a Microsoft root cause note or a server-side fix announcement for it.
Before you build any of that: your normal update channels do not go through the catalog website. WSUS, Windows Update for Business and Intune fetch content over their own paths. If the only thing broken is the browser-side download popup, your rings are entirely unaffected and you can just patch normally while ignoring the site.
The catalog site is for when you need one specific package out of band, a hotfix, a rollback, an air-gapped box. It is not the mechanism your fleet uses.
Do the bandwidth arithmetic first, because it usually settles this before quality even comes up.
Token generation on this class of machine is memory-bound. Your ceiling is roughly bandwidth divided by bytes read per token, and on a mixture-of-experts model the bytes read per token track the active parameters, not the total.
So, back of envelope: 10B active at 4 bits per weight is on the order of 5GB read per token, giving a theoretical ceiling somewhere around 50 tokens/sec at 273 GB/s. 13B active at 2.5 bits per weight is on the order of 4GB, so a similar ceiling. Real throughput lands well below both - there is router overhead, the shared expert, attention, and the OS is using that same memory: but the point stands: the bigger model at the lower quant does not buy you speed.
Which means the trade is: same speed class, worse weights, more memory pressure. That is not an upgrade, that is a sidegrade with a downside.
Completely agree, and that is the measurement I would do before touching the model choice at all. If the curve falls off a cliff at your working context, the fix is cache quantisation or a shorter working context, not a different set of weights.
An uptime check on the main pages and error alerting on the backend costs very little and changes the entire dynamic of the call. "I saw it go down eleven minutes ago and it is already back" and "you are telling me it has been down all day" are two different relationships with the same client.
It does not reduce call volume much on its own. It changes what those calls cost you in trust, which is arguably the more expensive currency.
Set the alarm before the deadline, not after the invoice.
AWS Budgets monitoring itself is free. What costs money is action-enabled budgets beyond the first two, at $0.10 per day each, and budget reports at a cent apiece. A plain "email me when spend passes this number" budget is free.
Set two. A $1 budget, which tells you that something is billing at all: that is the signal you actually want in the first 48 hours. And a $10 one, which tells you it is not a rounding error. Route both to an address you read on your phone, not the one you only check at a desk.
You are chasing two different bugs, which is why nothing you do fixes both.
Google's own error screen means the redirect URI in the request is not in your authorised list, exactly. Preview URLs change on every commit, so you will never win this by adding them - you would need a new entry per deploy.
Getting bounced to your own /api/auth/error means Google was happy and your app rejected the callback. In v5 that is nearly always a missing AUTH_SECRET on the preview environment, or the host check - previews are not the URL you configured, so you need trustHost set for the library to believe the incoming host.
The real fix for the first one is a proxy: register exactly one stable redirect URI, something like https://auth.yourdomain.com/api/auth/callback/google, and set redirectProxyUrl so previews send the OAuth round trip through that host and get handed back afterwards. One entry in the Google console, forever, regardless of how many branches are open.
Google does not accept wildcards in authorised redirect URIs. Depending on how you enter it you will either get a validation error or it will save and then silently never match anything, which is worse because you will believe it is done.
This is comfortably the most common wrong answer to this problem and it is worth saying out loud every time.
Gradual rollouts exist for this. Even 10% for one hour turns a 812-user incident into an 80-user annoyance you catch on a dashboard before anyone emails you.
Simplest fix is to swap the model for the cheap tier. It's something like 20x less per token, so your $612 becomes $30 and you can stop worrying about the loop entirely.
It is not lossless, it is tolerable, and the difference matters when you are choosing where to stop.
Every step down adds error. It is small and well-distributed near the top of the range, which is why 8-bit and often 4-bit feel indistinguishable on short tasks, and it compounds badly near the bottom. "Nobody can tell in blind tests" is true for single-turn chat and false for long agent runs, which is exactly the workload people in this room are running.
You are mixing up two different twelve-month numbers, and it is a dangerous thing to be relaxed about.
What is documented for the free plan is 90 days of data retention after expiry, with access restored by upgrading to a paid plan. The twelve-month figure is about credits: if you upgrade, remaining credits stay valid for up to twelve months from your original signup date. That is a billing balance, not a data retention window.
Anything beyond the 90 days is a support lottery, not a policy. Treat the 90 days as the real deadline and act in week one, not month three.
The rejections are almost certainly fire-and-forget posts whose response nobody reads. Meter events have an accepted timestamp window; anything you replay from a backlog, a dead-letter drain or a late worker lands outside it and comes back a 400 that goes straight into the void. Log the status code and you will find them in an afternoon.
The dedupe is your retry wrapper. Stripe keeps one event per identifier and it is right to. Your table kept two because you inserted before you sent. Make the identifier deterministic - a hash of the task id, not a uuid generated at send time - and retries become free instead of lossy.
The structural fix is an outbox. Add metered_at and meter_event_id columns to the task row, a worker that fills them, and a query that finds rows older than an hour with metered_at is null. Then the gap is an alert on a Tuesday instead of a discovery at month end.
Ingestion lag is real and it is minutes, not a 6% hole at month end. If the period is closed and the invoice is finalised, the number on the invoice is the number. Waiting a day here just delays finding the actual bug.
Signing config specifically is worth solving once and never touching. Get the credentials managed remotely, verify a build, and then stop having opinions about keystores.
The operational problem with org_id in the token is switching orgs, and it is worth deciding now rather than in six months.
Either you re-mint the token on switch, which is one extra round trip and is completely fine, or you put all memberships in the token and choose at query time, which is also fine until someone belongs to 200 orgs and your cookie no longer fits in a header. Pick the first one unless you have a specific reason.
One caution on security definer: set an explicit search_path on the function. A definer function without one is the classic Postgres privilege-escalation footgun, and it is two words to prevent.
Check that app.config.js is not reading something from process.env at config evaluation time that only exists on your machine. That produces a build whose configuration is subtly different from everyone else's and it is invisible in the diff because the file looks the same.
And inspect it under Application in devtools on both origins, not the response header on the one that set it. The response tab shows you what the server tried to do, which is not the same as what the browser stored.
Alternative shape if the blast radius bothers you: keep the session host-only on the auth origin and give app.example.com its own cookie through a short redirect handshake at login. More moving parts, and the cookie a compromised subdomain can steal is scoped to that subdomain only. Worth it above a certain size, overkill below it.
The included allowance is the part everyone skips and it is the part that makes usage pricing survivable. Same invoice most months, and the overage only shows up when they genuinely got more value.
That works right up until the reason arrives as "we cannot upgrade the SDK", and by then it is urgent, you have no slack, and you are doing the migration and the SDK bump in the same week. Waiting is a real option but it should be a decision with a date on it, not a default.
And if they will export hashes, check the algorithm and parameters too. Getting the hashes is only useful if you can verify against them without asking everyone to reset anyway.