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