> But I would love an option (emphasis on option) to see the text side by side with the page images. ... That way, I could "confirm" or "fact check" the faithfulness of the OCR.
You can already do that on Wikisource. For example, here's p. 658 from the entry on "Molecule":
Also OP: I noticed some fidelity issues in your version (at https://britannica11.org/article/18-0684-s2/molecule). For example parts of the math formula under the line that ends with "the molecules of other kinds" ([1]) are missing (compare [2]). Also, in your version fn. 1 of this article is attached to "as they have always done" ([3]) but it should actually be attached to "Atom" on p. 654 ([4]):
That's cool about the WikiSource parallel text+image page view, TIL. Thanks!
As an example flow (since it took a minute to figure out): we can start at https://en.wikisource.org/wiki/1911_Encyclopædia_Britannica then click to navigate/browse volume > section > topic to get to a text page, then click Source tab, then click a Page Number (maybe hunt around for the correct page number), and see the parallel view, text + image. With previous and next page buttons available, retaining the parallel text + image view.
5. Notice the left margin contains hyperlinks like [105] whwere 105 is the page number nd links directl;y to the side-by side view of page 105. Click the [105] link on the left (for example), to get to https://en.wikisource.org/wiki/Page%3AEB1911_-_Volume_02.djv... which shows the text-and-image side by side (for that page).
This flow avoids the hunting-for-the-right page step, by using the direct links.
There's also a side-by-side option now. On any article, clicking the little scan button above the double-navigation arrows in the right margin will open the scan at whatever page you're viewing, and it will scroll as you scroll the text.
I had a question about reporting conventions. In the paragraph where Altman is said to have told Murati that his allies were "going all out" to damage her reputation, the claim is attributed to "someone with knowledge of the conversation" but the attribution is tucked inconspicuously into the middle of the sentence (rather than say leading upfront ("According to someone with knowledge of the conversation, Altman...")) and Altman's non-recollection appears only parenthetically.
As a reader, am I supposed to infer anything about evidentiary weight from these stylistic choices? When a single anonymous source's testimony is presented in a "declarative" narrative style like here (with the attribution in a less prominent position), should we read that as reflecting high confidence on your end (perhaps from additional corroboration not fully spelled out)? And does the fact that Altman’s non-recollection appears in parentheses carry any epistemic signal (e.g. that you assign it less evidentiary weight)? Or is that mostly a matter of (say) prose rhythm?
Do long sessions also burn through token budgets much faster?
If the chat client is resending the whole conversation each turn, then once you're deep into a session every request already includes tens of thousands of tokens of prior context. So a message at 70k tokens into a conversation is much "heavier" than one at 2k (at least in terms of input tokens). Yes?
That's correct. Input caching helps, but even then at e.g. 800k tokens with all of them cached, the API price is $0.50 * 0.8 = $0.40 per request, which adds up really fast. A "request" can be e.g. a single tool call response, so you can easily end up making many $0.40 requests per minute.
It essentially depends on how many back-and-forth calls are required. If the model returns a request for multiple calls at once, then the reply can contain all responses and you only pay once.
If the model requests tool calls one-by-one (e.g. because it needs to see the response from the previous call before deciding on the next) then you have to pay for each back-and-forth.
If you look at popular coding harnesses, they all use careful prompting to try to encourage models to do the former as much as possible. For example opencode shouts "USING THE BATCH TOOL WILL MAKE THE USER HAPPY" [1] and even tells the model it did a good job when it uses it [2].
Not necessarily, take a look at ex OpenApi Responses resource, you can get multiple tool calls in one response and of course reply with multiple results.
> I guess it's hard for me to edit things that I don't see right in front of me or aren't super simple changes (like name changes). Or at least, basic things I can reason about (such as finding by regex then deleting by textobject or something).
This is actually what's nice about tools like ast-grep. The pattern language reads almost like the code itself so you can see the transformation right in front of you (at least for small-scale cases) and reason about it. TypeScript examples:
The $X, $A etc. are metavariables that match any AST node and if the same metavariable appears twice (e.g. $X = $X ?? $Y), it requires both occurrences to bind to the same code so `x = x ?? y` will match but `x = y ?? z` won't. You can do way more sophisticated stuff via yaml rules but those are less visually intuitive.
Sadly coding agents are still pretty bad at writing ast-grep patterns probably due to sparse training data. Hopefully that improves. The tool itself is solid!
If your editor of choice supports an extension (vscode does for example) it's a very easy on-ramp for a better search/replace than regex offers. It's syntax-aware so you don't need care about whitespace, indentation etc. Very easy to dip your toes in where a regex would get complex fast, or require multiple passes.
I converted a codebase from commonjs to esm trivially with a few commands right after first installing it. Super useful.
I hope LLMs eventually start operating at this level rather than raw text. And likewise for them to leverage the language server to take advantage of built in refactorings etc
I don't know which editors support this but there's also, for lack of a better word, context aware grep. For example, search and replace foo with bar but only inside strings, or only inside comments, or only variables, or only methods, not class names (maybe ast-grep does this).
> Do websites want to prevent automated tooling, as indicated by everyone putting everything behind Cloudfare and CAPTCHAs since forever, or do websites want you to be able to automate things? Because I don't see how you can have both.
> Since tool calls are handled in JavaScript, a browsing context (i.e. a browser tab or a webview) must be opened. There is no support for agents or assistive tools to call tools "headlessly," meaning without visible browser UI.
That really just increases the processing power required to automate it. VM running Chrome to a virtual frame buffer, point agent at frame buffer, automate session. It's clunky, but probably not that much more memory intensive than current browser automation. You could probably ditch the frame buffer as well, except for giving the browser something to write out to. It can probably be /dev/null.
Claude Code by default auto-deletes local chat/session logs after 30 days, so the claim that this tool can recover "any file Claude Code ever read/edited/wrote" is only true within that retention window unless you've explicitly changed the settings ("cleanupPeriodDays", see [1])
Speaking as someone who's derived a lot of value from these logs, it's a bit shocking that the default is to wipe them automatically!
Yes, as soon as I noticed that I changed that setting to 9999 days. Luckily enough I still was in that 30 day window. But true, the retention window is a factor for chances of recovery indeed.
> ... we observe extreme inequality in attention distribution. The Gini coefficient of 0.89 places HN among the most unequal attention economies documented in the literature. For comparison, Zhu & Lerman (2016) reported Gini co-efficients of 0.68–0.86 across Twitter metrics. ... The bottom 80% of posts [on HN] receive less than 10% of total upvotes. (https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5910263)
This could probably be explained by HN's unique exposure mechanism. Every post starts on /newest and unless it gets picked up by the smaller group of users who browse /newest, it never reaches the front page where the main audience is. In most forums/subreddits by contrast a new post (unless it gets flagged as spam) usually gets some baseline exposure with the main audience before it sinks. On HN the main audience is downstream of an early gate and missing that gate is close to being effectively invisible. IMO this fact alone could probably explain why "attention inequality" seems more extreme on HN.
reply