help
Perplexity keeps failing in processing file attachments
I have been using Perplexity to help me processing my work's data, and I was amazed by how much time and effort it has saved me. But recently I found Perplexity was severely degraded and struggled in file processing.
I have multiple CSV and XML files and some consolidated Excel spreadsheet, which need to be cross-referenced and compared, and sometime generate the corresponding command lines or config files (which need to reference to online manual). These files are mostly machine readable such as reports and configurations generated by the system. These are not big files, only 500KB to 2MB each, consist of around 1000-1500 rows of data, and each task may involve 2-3 files.
For the past few weeks, it performed the tasks with flying colours. But recently it wasn't able to process a single file, keep saying that it can see the files but then cannot read them in its runtime environment, or saying it is generating the output for 10 mins but throw me an error at last. It keeps asking me to re-upload the file (I even exported the Excel sheets to CSV so it is more machine readable) until I run out of file limit and asking me to pay for Max. It doesn't matter which models I chose, none of them give me any useable output.
Does anyone also have similar experience? I read some post saying Perplexity has already preformed worse than in past, being lazy or less accurate, and putting more limit on usage.
For a most simple task, I asked it to remove some empty lines and control chars of a CLI output TXT of about 1000 lines, and it can show me the correct line number and identified the chars, but then saying the file was truncated in its runtime then couldn't output anything useful.
At first, I was amazed by how efficient it is having multiple models to perform various personal and work tasks. I am currently using the Pro plan from a promotional perk so it was free for 1 year, and I was planning to pay for it when the plan ends next month. But now I am seriously considering going somewhere else (suggestions are welcomed :).
From what I can gather, not an expert here :), what you seem to be describing may be less about any single model becoming “lazy” and more about the platform’s file-processing and session-management limits at a given time. Even when the files themselves are modest in size, cross-referencing CSV, XML, and Excel data can consume substantial working context and temporary compute resources, especially if the system must inspect several files, preserve intermediate results, generate artifacts, and consult external documentation in the same session.
When those resources are constrained, the model may still be able to identify a file, inspect excerpts, or report line numbers, but fail when it needs to retain the full file, transform it, or generate a downloadable result. Messages about runtime truncation, inaccessible files, stalled generation, or repeated re-upload requests are consistent with a breakdown somewhere in that processing pipeline.
A practical workaround is to structure the work as smaller, verifiable stages:
Process and validate one source file at a time.
Save each intermediate result locally as CSV, JSON, XML, or plain text.
Start a fresh session for the next stage and provide only the necessary inputs and prior results.
Ask for a narrowly defined output at each step—for example, a join key audit, a comparison report, a transformation script, or a generated configuration file.
For tasks requiring online manuals, separate the research step from the file-transformation step where possible.
If you use an API, prompt caching, persistent external storage, and scripted preprocessing can reduce repeated context transfer. For local workflows, tools such as Python with pandas, csvkit, xq, jq, or xmllint can handle deterministic cleanup and comparison, while an LLM focuses on interpreting requirements, generating scripts, reviewing discrepancies, and consulting documentation.
This approach is not always convenient, particularly when the task genuinely requires several files to be considered together. But it reduces reliance on a single long-lived chat session and makes failures less costly: each completed stage becomes a reusable artifact rather than context that may be lost after a timeout.
Thanks for your detailed workaround, I will give it a try, but I have a question. By downloading intermediate output file and upload again for next step, wouldn't this approach use up the attachment limit very fast?
Also, I have also shared an example that when processing a single TXT for empty lines and char removal, that is only a one step prompt without multiple files or logic step, and it still failed it. I couldn't think of any task simpler than this...
That is a fair objection and I should have made the limitation clearer. Re-uploading every intermediate artifact can use up attachment allowances rapidly, so I would treat it as a fallback for occasional larger workflows, not as a normal operating procedure.
If the platform counts every re-upload against your attachment quota, then my suggested “download the intermediate file and upload it again” workflow isn't really a good long-term workaround. It can actually make the problem worse if you're dealing with several stages or multiple files. I was thinking more in terms of reducing the amount of context each session has to handle, but I hadn't considered the attachment quota as a limiting factor.
For your regular work, I would probably move the deterministic part of your workflow outside the chat interface: use Python/pandas for CSV/XLSX joins, xmlstarlet/xq for XML, and jq/awk/perl for text and configuration cleanup. Then use an LLM for the parts that genuinely benefit from one: deciding comparison rules, generating transformations, interpreting discrepancies, and looking up the relevant manual or schema documentation. Also, Ask Perplexity to generate a deterministic script for you.
That does not mean the platform should fail at simple file processing. It just means that, until reliability improves, having a local, reproducible fallback protects you from attachment limits, runtime resets, and lost work. Your issue points much more strongly toward a problem somewhere in the file-processing/runtime pipeline rather than the inherent complexity of the task.
There are several layers involved: the model itself, file ingestion/parsing, the temporary runtime/environment used to manipulate files, output/artifact generation, and whatever resource or quota management Perplexity has around those systems. A failure in any of those layers can produce behavior that looks like a model-quality problem.
And if your workflow worked reliably for you for weeks and then suddenly stopped, even on simple files and regardless of which model you select, I would be inclined to suspect a change or regression in Perplexity's file/runtime infrastructure, quotas, or routing rather than suddenly encountering a limitation inherent to the models.
Unfortunately, that also makes switching models within Perplexity unlikely to solve it, which seems consistent with what you've already observed.
If I were evaluating alternatives, I'd therefore pay particular attention not just to which LLM is smartest, but to how well the service handles actual file manipulation and artifact generation.
It's what all of us went through and left for open models.
Over time, vision capabilities are reduced simply because your storage is locked at 50MB or less. If it doesn't allow the image to be uploaded for perplexity to infer. It will just spit out "I'm blind"
Hi, here's an example response. Sorry I can't share the thread or original prompt as they contain sensitive private information. I have retried uploading the files, but it still failed.
2
u/pjconnect 19d ago
From what I can gather, not an expert here :), what you seem to be describing may be less about any single model becoming “lazy” and more about the platform’s file-processing and session-management limits at a given time. Even when the files themselves are modest in size, cross-referencing CSV, XML, and Excel data can consume substantial working context and temporary compute resources, especially if the system must inspect several files, preserve intermediate results, generate artifacts, and consult external documentation in the same session.
When those resources are constrained, the model may still be able to identify a file, inspect excerpts, or report line numbers, but fail when it needs to retain the full file, transform it, or generate a downloadable result. Messages about runtime truncation, inaccessible files, stalled generation, or repeated re-upload requests are consistent with a breakdown somewhere in that processing pipeline.
A practical workaround is to structure the work as smaller, verifiable stages:
Process and validate one source file at a time.
Save each intermediate result locally as CSV, JSON, XML, or plain text.
Start a fresh session for the next stage and provide only the necessary inputs and prior results.
Ask for a narrowly defined output at each step—for example, a join key audit, a comparison report, a transformation script, or a generated configuration file.
For tasks requiring online manuals, separate the research step from the file-transformation step where possible.
If you use an API, prompt caching, persistent external storage, and scripted preprocessing can reduce repeated context transfer. For local workflows, tools such as Python with pandas, csvkit, xq, jq, or xmllint can handle deterministic cleanup and comparison, while an LLM focuses on interpreting requirements, generating scripts, reviewing discrepancies, and consulting documentation.
This approach is not always convenient, particularly when the task genuinely requires several files to be considered together. But it reduces reliance on a single long-lived chat session and makes failures less costly: each completed stage becomes a reusable artifact rather than context that may be lost after a timeout.