Web clipper is great. just tried the reader mode on this chatgpt transcript, it only shows 1 page of it. Is the purpose of reader mode to enable interactive annotation before saving to notes?
In my experience it really depends on what sort of pdfs you are trying to extract (ie what the content is).
For regular pdfs that have been produced in a “normal way” (ie using latex or a modern application with a “save to pdf” function) will contain the text and for those I’ve had a lot of success on general pdfs using pypdf.
“Image” Pdfs that have been produced via a scan so don’t actually contain a text transcript require actual OCR. At the moment my personal rag pipeline is doing this using a local Gemma4 model (you could use something else).
Either way I do an audit post-ingest where I select a random set of pages and also get the local gemma model to try those same set and compare. The symptoms to look out for here will depend a lot on what you’re trying to extract but I’m extracting maths mostly so I get the model to check extraction of symbols, equations etc. One thing I have consistently found useful is to look for “mojibake” (scrambled text caused by decoding in an unintended character encoding) as this almost always catches pdfs that have just extracted as pure garbage. I added this step because I was ingesting a lot of old maths pdfs which have specialist notation that wasn’t always getting correctly ingested and as they were image pdfs it was coming in as pure garbage. So the fix here is to use a specialist ocr service (I have been using “mathpix” which has been great and isn’t too expensive if you don’t want to do too much).
The other thing that can cause problems is things like tables (eg if you were trying to ingest a lot of pdfs like financials of companies etc). Those can cause problems for both the ocr and the pure text extraction methods. I don’t have a current recommendation for that because I haven’t done it recently enough and the state of the art has moved a lot. It’s something to be aware of that will require special treatment though.
> regular pdfs that have been produced in a “normal way” (ie using latex or a modern application with a “save to pdf” function) will contain the text
Producing "normal PDFs" that way actually requires specific LaTeX options to be enabled in my experience. Without that, PDF viewers have to perform all kinds of ugly hacks to even figure out what Unicode codepoint a given glyph is supposed to represent! PDFs are much more of a vector format than a layouting program than most people seem to realize.
> One thing I have consistently found useful is to look for “mojibake” (scrambled text caused by decoding in an unintended character encoding)
This is exactly the problem with PDFs: It's not regular mojibake (i.e. interpreting a string of text in the wrong charset), but rather some PDF processor's failed attempt at mapping glyphs back to codepoints without an explicit mapping table being present in the PDF, which is something that the creator actively has to do.
> “Image” Pdfs that have been produced via a scan so don’t actually contain a text transcript require actual OCR.
For the reason above and others, in my experience, OCR actually works significantly better than trying to "semantically parse" the PDF.
Hmm. Not sure what I'm doing that's special but both latex pdfs I produce and others that I read generally work just fine with pypdf, and I really am not adding any flags at all (my makefile says I just go
> The cmap package provides character map tables, which make PDF files generated by pdfLATEX both searchable and copy-able in acrobat reader and other compliant PDF viewers.
I have a standing instruction for any documents that can't natively be read by a given AI to first be converted into .md using https://github.com/microsoft/markitdown which I've found to work really well
In the broadest sense, I don't think we're there yet. I asked an SoC vendor to provide their chip documentation in Markdown. They refused. So, I went ahead and tried to do myself with AI.
I tried various AI tools and the results ranged from absolute garbage to something-but-not-something-but-not-quite.
I went ahead and did a section of a huge PDF by hand, just to see if what I was asking for was even feasible. After more than several hours of painstaking work spread across multiple days, I got several chapters to look identical to the source PDF in some Markdown renderers. I had to use some HTML for the more complex tables. I converted some diagrams to Markdown and some to images linked to from the Markdown.
I use it with Delphi. Claude Code with Opus 4.7 works fine. It can use FPC in Delphi mode so that it can test itself. I'm doing greenfield and not an old project though.
From my reading, the official docs don’t support the strong
claim that frontier LLMs are explicitly RL-trained to “be lazy”
or conserve tokens as claimed in this thread. What they do document
is adaptive / hidden reasoning compute: OpenAI says reasoning
models allocate internal reasoning tokens and reasoning.effort
controls how many are used
(https://developers.openai.com/api/docs/guides/reasoning), and
Anthropic says adaptive thinking decides whether/how much to use
extended thinking based on request complexity, with effort as
soft guidance and max_tokens as the hard cap
(https://docs.anthropic.com/en/docs/build-with-claude/adaptiv...
hinking). So prompt wording may change how the same budget is
spent, but it can’t exceed the hard token cap.
Also, the “encouragement helps” anecdote seems real in the
AlphaEvolve workflow, but I can't see that forpublic
models. Gómez-Serrano says this in Quanta
(https://www.quantamagazine.org/the-ai-revolution-in-math-has...
rived-20260413/), and the released AlphaEvolve notebooks really
do contain prompts like “Good luck, I believe in you...”
(https://github.com/google-deepmind/alphaevolve_repository_of...
oblems, e.g.
https://github.com/google-deepmind/alphaevolve_repository_of...
blems/blob/main/experiments/finite_field_kakeya_problem/finite_f
ield_kakeya.ipynb). But those prompts also bundled strong
structural hints (“find a general solution”, “better
constructions are possible”), so from my reading the evidence
is: prompt phrasing matters, especially in an internal search
stack, but not “pep talks are a universal reasoning hack.”
> Anthropic says adaptive thinking decides whether/how much to use extended thinking based on request complexity, with effort as soft guidance and max_tokens as the hard cap
Nothing I said contradicts this.
Here is the first attempt of what I'm testing. [0] Haiku can get the correct answer to `floor( (1234567 * 8901234) / 12345 )` or
Given this Haiku will give a correct answer 77.8% of the time. Add one digit or remove a digit, it is very highly predictable also.
That is the WHOLE point. The models are predictable!
Given that prompt Sonnet at 37-digit × 37-digit (~10³⁷) never quits a predictable percentage of the time!
And, Opus at 80-digit × 80-digit simply quits after 9 seconds and 333 tokens!
This is the amazing thing people are not discussing. The models are very predictable.
The AI companies are not posting this information because it shows how unreliable the models are, however, I think there is great virtue that the models are consistently unreliable.
looks like you've done some thorough testing. Have you found that prompting reliably reduces premature quitting?
And have you found that reducing premature quitting results in more accuracy?
Because these are probabilistic machines, they solve the same problem at a predictable rate. Even with different variables, the success rate stays consistent.
I only noticed the premature quitting issue recently and haven't tested it much yet. It's getting expensive to run Sonnet on hard multiplication problems. I let it run to 200k tokens and it still grinds without quitting.
But Opus has a different problem. Ask it to solve a Rubik's Cube and it will run for hours and never solve it. So there are definitely prompts that make it run forever. But if you tell it to break down multiplication using algorithms, it behaves differently. It can take really complicated calculus problems and break them into simpler ones. I can't stump it that way.
Here's the interesting thing. Even when Opus solves modular expressions by breaking them down like calculus, it still fails at a predictable rate. There's a constant failure rate no matter what you do at any level of complexity.
Models have a baseline failure rate that prompting can't change. You can change how they fail -- token burn or quitting early -- but the underlying limit stays the same.
The P≠NP conjecture in CS says checking a solution is easier than finding one. Verifying a Sudoku is fast; solving it
from scratch is hard. But Brandolini's Law says the opposite: refuting bullshit costs way more than producing it.
Not actually contradictory. Verification is cheap when there's a spec to check against. 'Valid Sudoku?' is mechanical.
But 'good paper?' has no spec. That's judgment, not verification.
producing BS can be equated to generating statements without caring for their truth value. Generating them is easy. Refuting them requires one to find a proof or a contradiction which is a lot of work, and is equal to "solving" the statement. As an analogy, refuting BS is like solving satisfiability, whereas generating BS is like generating propositions.
It's not contradictory because solving and producing bullshit are very different things.
Generating less than 81 random numbers between 1 and 9 is probably also cheaper than verifying correctness of a sudoku.
Skill issue.
I'm far more interactive when reading with LLMs. I try things out instead of passively reading. I fact check actively. I ask dumb questions that I'd be embarrassed to ask otherwise.
There's a famous satirical study that "proved" parachutes don't work by having people jump from grounded planes. This study proves AI rots your brain by measuring people using it the dumbest way possible.
