Ines

Matches my account exactly. The effort control was on Instant while the default model dropdown said Sol. Two controls, one of them wins, and it is not the one with the model name on it.

The framing that made this stop feeling spooky for me: "default model" means "where a new chat starts", not "what every answer in it is produced by". Once you stop reading it as a guarantee, the behaviour is consistent.

Practically, I keep one project with the effort pinned high for the work where the answer matters, and let everything else start wherever it wants. That also means the expensive setting is scoped to the place I chose it, instead of applying to "what is the flag for tar again".

Open the project rather than a loose chat, and set the thinking level from inside it. It sticks for chats started in that project and does not touch your default elsewhere.

The reason nobody finds it is that the control looks identical to the global one, so it reads as the same setting rather than a scoped override. Worth confirming on your own account by starting one chat in the project and one outside it and comparing the label on the replies, because I would not trust my description of a UI that has moved twice this year.

Other way round. invalid_grant is about the authorization code: already used, expired, or exchanged with a different redirect than it was issued for. A client secret that is expired, malformed, signed with the wrong key or carrying the wrong claims comes back as invalid_client.

This is worth getting right because the wrong version costs you an hour. Decoding the exp of the secret you have configured takes about ten seconds and rules the whole class in or out before you start editing identifiers that were working yesterday. Change nothing until you have read that number.

Get the raw error body out of the token exchange and stop reasoning about your SDK's wrapper. Most auth libraries collapse several distinct failures into one generic "sign in failed" that tells you nothing.

Once you have the raw body, the question usually answers itself: a 503 or a timeout is theirs, an OAuth error object with a specific code is yours. Log the raw body permanently if you do not already, because you will want it the next time too and the next time will also be at a bad moment.

I just went through this and the change that worked for me felt stupidly small, so I will over-explain it.

My first email pitched. Three sentences on what the tool does, a link, and a request for a call. Zero replies out of about 90. I rewrote it so the entire body was one question about how they currently handle the thing, no link at all, no product name in the body, product name only in my signature. Same list, next 90 sends, seven replies and four of them turned into conversations.

My theory is that a link in a cold first email tells the reader this is a campaign, and a question tells them it is a person. Also two of the seven replies were people telling me their actual process, which was more useful than any of the calls.

Most of that 70% is not mysterious, it is mechanical. Links opened from email clients, chat apps and PDFs arrive with no referrer at all, so anything you send by newsletter or drop into a Discord lands in the same bucket as someone typing your domain. Browser referrer policies strip the rest down to the bare domain or nothing.

The fix is tagging every link you control with campaign parameters. Email links, community posts, your profile links, the footer of a PDF - all tagged. That converts dark traffic into named traffic without any new tooling.

One rule people get wrong: tag inbound links only, never links between your own pages. Putting campaign parameters on internal links starts a new session and overwrites the original source, which quietly poisons the data you are trying to collect.

One addition: put the same hours on the contact page, not just in the autoresponder. Then expectations are set before they write, and you stop getting the follow-up email two hours later asking if you saw the first one.

There is a cheap way to answer your actual question. Email the non-connectors. Not a drip campaign, a plain personal message from your own address asking what stopped them, sent to thirty of them by hand.

Expect maybe three to six replies out of thirty. In my experience the replies split roughly into thirds: I was just looking, I could not work out how, and I did not want to give you that access. Those three groups need three completely different responses and you cannot design for all of them at once. Whichever third is biggest tells you what to build.

6.5% at month 4 on a $19 self-serve product sold to individuals is unremarkable. The 3% benchmark you keep reading is for products sold to companies, where the buyer is not the user and cancelling requires someone to do paperwork. Different physics entirely.

But blended monthly churn is close to useless at your size and here is why: your churn number is dominated by whoever signed up most recently, and recent signups always churn hardest. Nothing about your product changed, your mix did.

What you want is retention by signup cohort. Rows are the month someone signed up, columns are months since. Something like:

cohort   m1   m2   m3   m4
mar     100%  71%  63%  59%
apr     100%  74%  66%
may     100%  69%

The question is not "is 6.5% good". It is "does the curve flatten". If each cohort loses a third in month 1 and then stabilises around 60%, you have a healthy product with a bad onboarding. If the curve keeps sloping down at month 6, you have a product that people finish using and there is no amount of onboarding work that fixes it.

You have four months of data. You can build this in a single SQL query and it will tell you more than every benchmark article combined.

The rewrite question deserves a real answer rather than the reflex 'never rewrite'. Ask what fraction of the code is your logic versus glue. If a side project is 80% framework wiring and 20% the thing that makes it yours, scaffolding fresh and porting the 20% genuinely can be faster than an upgrade path through three majors. I've done it, it took a weekend, and the old repo stayed as reference.

If it's a real product with users and data, absolutely not. Upgrade incrementally. The difference is whether anyone is depending on it right now.

That explains why it is always the same container: it is the one whose start is slowest because it waits on a database. Presumably it comes up after the proxy every single time.

Engineering answers aside, you also have a pricing problem. "$9/mo, unlimited semantic search over unlimited notes" is a promise where your cost scales with usage and your revenue does not. That is fine at 640 users and fatal at 6,400.

You do not need usage-based billing tomorrow. You need a limit that is generous enough that 95% never see it and real enough that the tail cannot ruin you. Something like 2,000 indexed notes on the $9 plan. Ship it for new signups, grandfather everyone existing, and now your worst case is bounded.

Did this migration two months ago with 33 people on the old price. Sixty days notice, two emails, and two people cancelled.

The email that worked was short and had no apology in it. First line said what is changing and when, in numbers - your plan goes from 12 to 19 on 1 March. Second paragraph, one sentence on why, which for me was honest: support and hosting per account roughly doubled since I set that price. Third, the options - stay monthly at the new price, lock twelve months at the old price by switching to annual before the date, or export everything and leave with no hard feelings, here is the link. Fourth, a direct reply-to-me line.

Most of the replies I got were people asking to be moved to annual immediately.

The thing nobody's said: you may well have built a good feature. Bulk import with an approval step isn't exotic, and one ops lead describing it in that much detail means the shape of the problem is real even if that company flaked.

Take the same spec to five other logistics ops people this month. If three of them light up, you didn't lose a quarter, you got a free requirements document. If nobody cares, then yes, you lost a quarter: but now you know which it is instead of guessing.

Stay flat, but stop being flat silently.

At 40 customers you can do this with a spreadsheet and thirty minutes a month. Add a hard-ish cap to the $29 plan - say 500 documents. Track the count (a single counter column, not an events table). When someone goes over, you email them personally and put them on a $99 plan you invoice manually.

That gets you the entire economic benefit of usage-based pricing with about four hours of work instead of six weeks. It also teaches you what the right meter and the right price actually are, which you currently do not know. The number of people who build beautiful metering on the wrong unit is enormous - you meter documents, then discover customers think in "clients" or "projects" and your invoice is unreadable to them.

Build the real system when manual invoicing genuinely hurts. For me that was around 120 customers and by then I knew exactly what to build.

Book a standing 25 minute meeting, same slot every fortnight, and send an agenda the night before. Ad hoc requests fall off the list of a person with 40 emails a day. A recurring calendar entry does not.

Post outcomes, not plans. That one change keeps most of the benefit and removes most of the exposure.

What the audience actually rewards is the story of something happening - a number moved, a thing broke and got fixed, a customer said something surprising. None of that requires telling anyone what is in your next sprint. Roadmaps are the least interesting thing you post and the only thing worth copying.

I moved to shipping first, posting after, and engagement went up. Turns out people find a finished thing with a result attached more compelling than a promise, which in hindsight is obvious.

You can schedule the launch in advance rather than staying up to submit it, which removes the only genuinely timezone-dependent part of the process. Everything after that is you being awake and responsive, and you are awake at 09:01.

The preparation that actually paid off for me: assets finished a week early, the first comment written and edited while calm, and a short list of people told a few days beforehand that it was happening on a specific date. Not asked for anything. Just told.

The real cost is not the 20%, it is that annual hides churn for a year. Your monthly cohort tells you within six weeks whether a change worked. Annual customers cannot vote for twelve months, and when they do vote it is one loud binary event.

If you go annual, keep enough monthly customers to preserve that signal. Do not push everyone to annual just because the cash is nice.

Change what you count. Words per day punishes exactly the work that matters at this stage. I switched to counting sessions: did I sit down for 90 uninterrupted minutes with the document open and no browser? Four of those a week moved the thesis more than any word target ever did.

Make the list finite and written. At the end of the next meeting, out loud, say: "So the remaining items are A, B and C, and once those are done we're at defense." Then email a summary to everyone within 24 hours and ask them to correct anything you got wrong. Silence becomes agreement. The reason the requests never stop is that nobody has ever had to commit to a stopping point in writing, and each individual ask feels small to the person making it.

Then say it anyway, in the minutes, in your own voice. You are not asking for permission to summarise the meeting. If the same member later adds item D you can reply to your own email and ask whether D replaces C or is in addition, which quietly makes the cost visible.

12 that you have read carefully beats 500 generated by a model that you have never read. I have audited synthetic eval sets where roughly a third of the reference answers were wrong, which means the harness was actively punishing correct behaviour.