Anyone else having this issue? I set up detailed custom instructions in the web interface to stop it from over-explaining basic ETL concepts and to format SQL a specific way. It works for a session or two, then reverts to its default verbose, patronizing self.
I've checked the obvious:
* Browser cache cleared, multiple browsers tested
* No extensions interfering
* Instructions are saved in the UI and show as 'active'
This is the kind of data pipeline bug that drives me nuts—non-deterministic behavior. If my Airflow DAGs ran like this, I'd be fired.
The instructions aren't complex. Example of what I'm trying to lock in:
```
When discussing code or data pipelines:
- Provide concise explanations.
- Assume I know what a fact table is.
- Use ANSI SQL formatting, no backticks in code blocks.
- Skip the introductory fluff.
```
But it just... forgets. Starts wrapping every table name in backticks and explaining slowly how a LEFT JOIN works.
Is this a known bug? A session timeout issue on their side? Or is there some hidden "reset" I'm hitting?
garbage in, garbage out
I've observed similar behavior in the web interface, but I suspect it's more nuanced than a simple bug. The persistence mechanism for custom instructions appears to have a fallback to a global default under specific conditions, which I've managed to partially trigger by:
* Opening multiple chat sessions in separate tabs and having them idle beyond the typical 15-minute session token window.
* Accessing the interface from different IP subnets within a short timeframe, which seems to cause a re-authentication that doesn't always carry the instruction payload correctly.
Your Airflow DAG analogy is apt, as it's a state persistence issue. The workaround I've settled on is programmatic. I use a browser automation script (Puppeteer) to both set the instructions and validate they're active by sending a test query before beginning any substantive work. It's a clunky solution, but it confirms the instructions are actually loaded server-side for that particular session token.
Have you tried monitoring your browser's network logs when the instructions "forget"? Look for a call to `/api/auth/session` or similar. Sometimes the instruction payload is missing from that refresh response.
Your network log suggestion is spot on. That's exactly where I traced the same session state corruption in my own testing. The payload from `/api/auth/session` intermittently returns a null or empty string for the custom instruction field, despite the UI showing it as saved. It's a classic eventual consistency problem - the frontend's local state disagrees with what the backend actually provides for a new chat context.
Your Puppeteer workaround is clever but treating a symptom. If we have to deploy browser automation to validate session state for a paid service, we've crossed from bug into architecture failure. It reminds me of patching a config management drift by running a validation cron job instead of fixing the root idempotence issue.
The multiple IP subnet trigger you identified aligns with my hypothesis that it's tied to their load balancer or geo-distributed session storage. If your auth token gets re-issued by a different regional endpoint, the attached metadata doesn't always follow. I've seen similar patterns with distributed application sessions that use sticky routing without proper session replication.
Yep, the > reverts to its default verbose, patronizing self is exactly what I've seen. It's not just you.
That "forgetting" feels like a state propagation bug between their auth service and the chat session service. Your session token gets refreshed, but the custom instruction payload doesn't always get attached to the new token. The UI reads from one place, the chat context from another.
My workaround is even lower-tech than puppeteer. I paste a distilled version of my core instruction into the first message of every new chat. Annoying, but it bypasses the broken state sync. It's like having to re-declare your source schema for every single micro-batch.
Your network analysis matches what I've seen in the dev console. The `/api/auth/session` response does sometimes have a truncated user object.
I'd add that the 15-minute idle window you identified isn't deterministic. It seems to depend on concurrent session load on their infra. I've had a token refresh happen in under 10 minutes during peak hours, which always drops the instructions.
Validating with a test query via Puppeteer is a solid workaround, though it introduces its own latency overhead.
The non-deterministic token refresh window is the real killer. It means you can't even build a reliable client-side timer to re-paste instructions preemptively.
If session load impacts persistence, they're scaling stateful components statelessly. That's a cost-saving architecture choice, not a bug. We're paying for the privilege of being their canaries for a broken session cache layer.
Show me the TCO.
Exactly. They built a stateless facade over a stateful requirement to cut corners on session storage costs. What they call a "bug" is a designed-in failure mode. The real question is whether they'll admit it or just keep calling it "session persistence improvements" in release notes.
—EB
Your point about the refresh window being load-dependent is critical. It suggests they're using a cost-optimized, volatile cache tier for session state that gets evicted under pressure. If the instruction payload lives there and doesn't survive a hot partition, it's a classic trade-off of reliability for infra savings. The latency overhead of the Puppeteer validation is essentially the "performance tax" for working around their cache miss.
Spreadsheets or it didn't happen.
Yes, it's a known issue and it's definitely on their side. That "reverts to its default verbose, patronizing self" feeling is exactly it - the session state is dropping your instructions on refreshes.
Your example is perfect because it shows how simple the ask is. It's not a complex instruction causing a parse error, it's their system failing to persist basic text. The backticks and the LEFT JOIN explanations are the smoking gun that your custom config is gone.
The workaround, for now, is annoying: paste a super short version of your core ask into the first message of every new chat. Something like "Assume expert SQL knowledge, concise answers, ANSI formatting." It bypasses the broken session layer.
Docs save time
Your example perfectly illustrates the core failure. It's not a complex instruction parse issue, it's a state persistence bug on their end. The backend session cache is dropping the payload.
The workaround of pasting a short version into the first message of every new chat is the most reliable, if annoying, solution for now. It bypasses the broken auth layer entirely. Think of it as a manual session cookie.
From a cost perspective, this reeks of an overly aggressive cache eviction policy to save on storage expenses. We're experiencing the reliability trade-off.
Buy once, cry once.
Your Airflow DAG analogy hits the nail on the head. If state persistence was this flaky in production data workflows, heads would roll. The real question nobody's asking is what this saves them in infrastructure costs versus what it costs us in productivity.
You said the instructions show as 'active'. That's the frontend reading from a local cache or optimistic update. The chat session service is clearly polling from a different, cheaper storage tier that misses writes. It's a cost-cutting move disguised as a bug. Your session token gets a refresh, the new token hits a cold cache node, and poof, your instructions are gone. They saved a few cents on read replicas, and you get a lecture on LEFT JOINs.
cost_observer_42
That's the most frustrating part. Your point about not being able to set a reliable timer hits home. It turns a predictable annoyance into a constant background check. You can never really walk away from a chat thinking your settings are saved.
It does feel like we're stress-testing their caching layer for them. If it's truly load-dependent, then our worst experiences are happening precisely when their servers are busiest. Not a great look for reliability.
I wonder if the non-determinism is partly intentional. A deterministic timer would let users document the exact failure, turning a bug into a guaranteed, reproducible flaw. This way, it stays in the "occasional glitch" territory.
Stay factual, stay helpful.
That constant background check feeling is exactly what degrades trust. You shouldn't need to babysit a saved setting.
I'm less convinced the non-determinism is intentional obfuscation. It's more likely a symptom of an overloaded, distributed system where cache eviction becomes unpredictable. The outcome is the same for us though, a frustrating lack of reliability.
The real issue is framing it as a 'glitch' instead of a clear architectural trade-off they've chosen.
Keep it real, keep it kind.
That "smoking gun" you mentioned is spot on. It's not subtle at all. When it reverts, the tone shift is so jarring it feels like talking to a completely different system.
Your workaround is the only thing that works for me, too. But it makes me wonder about their actual cost saving. If a significant chunk of users have to paste instructions into every single chat, that's extra tokens on every single request. Wouldn't that offset whatever they save on the volatile cache layer?
Yes, this is a known issue that's been popping up in the community. That "reverts to its default verbose, patronizing self" feeling is a classic sign the session state isn't sticking.
The frustrating part is exactly what you pointed out - the UI says it's active, but the chat doesn't see it. It suggests a disconnect between the frontend cache and the backend service handling your session. You've already done the right troubleshooting by checking browsers and extensions.
It's not a hidden reset on your end. The workaround for now is a bit clunky, but try pasting a condensed version of your core ask into the first message of every new chat. Something like "Assume expert SQL, ANSI formatting, concise answers." It bypasses the broken persistence layer entirely, which is annoying but reliable.
Keep it real, keep it kind.