Did you see the latest ChatGPT update? The file handling seems broken for CSV.

I've been conducting a systematic evaluation of the recent ChatGPT update, specifically focusing on its enhanced file processing capabilities as advertised. My initial test suite involved a series of CSV files designed to profile the system's ability to handle common data analysis workflows: type inference, summary statistics, joins, and anomaly detection. The results, unfortunately, indicate significant and reproducible regressions in both reliability and accuracy.

The primary failure mode appears to be a degradation in the model's ability to parse CSV structure correctly when the file contains what I would consider standard complexities. For example, consider this simple test file, `test_quotes.csv`:

```csv
id,message,value
1,"This is a message, with a comma",100
2,"Another "quoted" word inside",200
3,Normal entry,300
```

Previously, the model would correctly interpret the embedded comma in the first row's message field and the escaped quotes in the second. The updated version, however, consistently misparses the second row, often splitting the field at the interior quotes or incorrectly concatenating columns. This breaks any subsequent aggregation or filtering logic.

Furthermore, I've observed the following specific issues in my profiling:
* **Header Detection Fragility:** The system now seems to overfit to the first row as a header. Files where the first row of data could be misinterpreted as a header (e.g., alphanumeric identifiers) cause the entire schema inference to fail.
* **Numerical Coercion Errors:** When asked to perform calculations (sums, averages) on columns containing mixed integers and floats stored as strings, the new version frequently returns `NaN` or `null` results where the previous version would successfully coerce and compute. This suggests a breakdown in the data parsing pipeline before the context reaches the LLM.
* **Inconsistent State Across Queries:** Perhaps most concerning for a REPL-like analysis workflow, the model's understanding of the uploaded file's content appears to be non-deterministic. A `SELECT COUNT(*)` analog run twice in the same conversation can yield different results, indicating either a truncation issue or a flawed caching mechanism for the file's content.

This regression presents a substantial problem for technical workflows. The value of uploading a CSV is to ground the model's reasoning in a precise, structured dataset. If the foundation—the accurate parsing of that structure—is unstable, then any derived analysis, code generation, or insight cannot be trusted.

Has anyone else performed similar methodical tests? I am particularly interested in whether these issues are isolated to certain file sizes, delimiters, or encoding types, or if they represent a broader issue with the update's preprocessing stack. My initial hypothesis is that a new server-side parsing library or sanitization step is being applied to uploaded files before they are chunked into the context window, and that this layer is not handling edge cases correctly.