Harlan Voss

Or sidestep the whole quota question and run glm-5.2 locally. Open weights, no meter, no five hour window.

The weights fitting is the easy half.

That 128GB is unified, the OS, the CPU side of whatever you are running, the runtime and the KV cache all live in the same pool. Load 88GB of weights and you have maybe 30-something gigabytes for everything else, and a model advertising a million-token context will happily eat all of it the first time you paste a large file in.

So "it fits" is true at load time and false about ninety seconds into a real session. Check headroom at your working context, not at idle.

Clients do not log into a second tool for you. Ever. They log in once during the handover call, agree that it is very nice, and never return.

Anything you need read has to arrive where they already live: an email with a PDF attached, or something printed that ends up in a drawer near the desk. The wiki is for you and for whoever maintains the thing after you. Building it is fine. Relying on the client to open it is how you end up back on this thread in a year.

Half of this is a contract problem wearing a documentation hat.

Define the support window, the response times, and what counts as an emergency, in writing, at signature. Not after launch, when you are negotiating from a position of guilt and they have already formed the habit of ringing you.

The reason 2am calls happen is that 2am calls are free. Documentation reduces how often somebody needs you. Only the agreement changes when they feel entitled to reach you.

This. I ramp anything over 500 across two days now. Same copy, same list quality, and open rate went from 31% on the burst send to 48% on the ramped one.

We had the identical shape of bug with the user's display name injected into the system prompt for tone. Moved it into the first user turn and hit rate went from 0 to about 94% the same afternoon. Anything per-user or per-moment belongs after the breakpoint, no exceptions.

Hourly with an out-of-hours multiplier is the only one of the three that changes client behaviour, and behaviour is your actual problem.

When 2am costs triple, an astonishing number of 2am problems turn out to be 9am problems. A retainer teaches the opposite lesson: contacting you is free and already paid for, so why wait.

The cost is that hourly is harder to sign and gives you lumpy revenue. Worth it early, less so once you have enough clients that predictability matters more than teaching each one manners.

Look at whether the requests are actually the same problem coming back. Eleven rounds of small changes usually means the direction was never approved, only tolerated. Sometimes the honest move is to stop and have a fifteen minute call about what they are trying to achieve, and one round after that call ends it.

This is the answer. Half of these requirements dissolve the moment you ask what specifically they're worried about.

Batching plus top-12 got rerank from 6.1s to 380ms. p95 is 3.4s now and I have not touched the model. The loop was doing one pair per call because that is how the example in the README was written.

Shipped the source titles streaming in ahead of the answer. Support messages about it being stuck dropped immediately, before any of the latency work landed.

Added spans and the shape was uglier than expected - rerank is 65% of p95 and prompt assembly is a surprising 300ms because of a synchronous token count call I forgot was there.

Mine has a lot of handheld b-roll, so that is probably part of it too.

Also look at the launch cohort's week-4 retention separately from every cohort after it. Launch cohorts always retain worse - curiosity signups, wrong ICP, people who will never come back - and if you blend them into your overall retention number you will panic about a problem you do not have.

Audio was PCM, and I was on CBR 25. Both fixed. Thank you.

Just stretch every day for longer, it will come.

Local corrections with a skin mask get you most of the way for one or two images. For fifty images it is not worth the time, build the profile.

Same for truncation: check the finish reason and the length rather than asking a model whether the text ends properly. People reach for judges to solve problems that an if statement solves.

The silent-gap part is what I'd chase rather than the reconnection frequency. Some apps warn you loudly when a connection has been stale for more than a couple of days and some just quietly show you a smaller number. That single behaviour is worth more than any feature list.

Held a cheap policy for four years purely to dodge the surcharge, never used it once, and eventually worked out the premiums were close to what the surcharge would have cost me anyway. If tax avoidance is your only reason, do the arithmetic with your actual numbers instead of assuming avoidance always wins.

Postmaster Tools shows my spam rate spiked to 1.4% on the outreach days. Reading that the threshold is meant to be under 0.3%, so that tracks miserably well.

Yes: sell them a paid discovery phase first, as its own small fixed price piece. Two weeks, maybe 800 of the 5k, output is a written direction with wireframes or a moodboard and a defined scope. Then quote the build against that document. You get paid for the part that is currently free and unbounded, they get a decision they can see before committing, and if it turns out you cannot work together you both find that out for 800 rather than 5000. It has never been refused when I frame it as reducing their risk rather than mine.

Roughly: I could give you a number now, but I would have to price the uncertainty into it and you would be the one paying for that. Let us spend two weeks removing the uncertainty instead. That framing sells itself.

Whatever you pick, put a hard per-user daily token counter in from day one and return a real message when it trips. Your $600 ceiling is not enforced by your architecture, it is enforced by a counter you have not written yet, and the day someone scripts against your API you will find that out.

Move it to a database if it is that slow.