> almost as if it was trained to spit out as complex of sentences as it can.
It probably was, at least inadvertently.
Very easy to imagine that one of the post-training step (RLHF, DPO etc) reinforced the "sounds clever" behaviour.
Admittedly the documentation is woefully out of date, but I think the premise of the article is how the session data are increasingly move away from the control of the user and more to the control of the model provider.
The questions that the article poses are, and this is the way fyai addresses them:
Inspection: Can the user see what the model saw, what tools did, and what agents told each other?
fyai> Full session log, tool calls, agent invocation, along with their durable state is stored locally in the durable arena and are available for inspection.
Export: Is the session self-contained, apart from ordinary artifacts that can also be downloaded?
fyai> The session is completely self-contained, no artifacts are stored anywhere besides the arena. Not only that sessions are export-able, import-able and transferable to other fyai sessions.
Replay: Can another implementation reconstruct a semantically equivalent context?
fyai> Full canonical and provider dumps can be generated. There is a standard schema, and the format is just YAML. Other tools are free to ingest it, and replay it.
Audit: Can a human explain why the system took an action after the fact?
fyai> Complete conversation logs, mcp session logs, authentication logs + full wire logs are available via fyai log.
Deletion: Can the user identify and remove every server-side copy on which the session depends?
fyai> Obviously fyai cannot help there. But as a business model, FYAI can work with a completely stateless, inference provider where absolutely no logs are kept, beside the ephemeral KV caches of the active sessions.
The rest of the article deals with the woes of the encrypted session content (reasoning and compaction). fyai fully supports their use, but, it is completely capable of operating without their use - you merely pay the cost of not hitting the cache of the provider.
The article then offers action points for portable inference.
This is how fyai answers:
1. The local event log is canonical. Server storage may mirror or accelerate it, but the client can reconstruct the session without dereferencing server IDs.
fyai> This is exactly the model that fyai provides. No server IDs are needed besides reconstructing the provider session that is hitting the cache.
2. Storage is explicit. store: false should be easy, documented, and preferably the default. Features that require retention should say so at the point of use.
fyai> fyai provides a --transient option, where no content is committed to durable storage; the operation only works on a transient RAM arena that is overlaid and then discard at the end of the operation.
3. No opaque item is the sole carrier of meaning. Encrypted reasoning, compaction, and tool signatures may be included for same-provider quality, but each has a readable, provider-neutral handoff representation.
fyai> Opaque items are the providence of the provider meta stream and is not required for operation; merely for cache optimization.
4. Hosted tools have full-fidelity logs. Record exact inputs, outputs, evidence, filtering, provenance, timestamps, and content hashes — not only a polished answer and citations.
fyai> The arena records all operations of the main conversation, tool calls _and_ their agent invocations. There is not context loss what-so-ever, by design.
5. Subagent communication is auditable. Persist the exact readable task, messages, results, lineage, model, and tool permissions for every agent.
fyai> All agent communication, and agent tool calls are inspectable because it is stored, again by design.
6. Compaction is inspectable. Return a readable summary, the instructions used to create it, and enough lineage to understand what was discarded.
fyai> Compaction is configurable; you can configure the agent to only use model summary compaction which is generating a text answer, which is stored durably.
7. Artifacts are exportable. Files, container outputs, search snapshots, and generated media can be downloaded into a content-addressed local archive.
fyai> All artifacts are local; Nothing is executed on a hidden provider server.
In conclusion, I think fyai address the points of the article quite well, don't you think?
At a very high level mathematics is basically 100% text/symbolic rewriting. You start from some set of postulate assumed true and you do your thing to get a new different set of equivalent assertions in a form that is more useful.
I don’t know if LLMs will kill the working-mathematicians but at least seem like that it doesn’t seem absurd to imagine LLMs will be good at math…
My experience may not be entirely representative because to be entirely honest I’m not exactly a great researcher and there are brilliant PhD students. That said it indeed was my experience that in the pre-PhD / early PhD period ( or even longer … ) your advisor proposes (gives) you pretty low hanging stuff that he mostly already knows how to solve, at least at a high level, with the expectation that it will teach you to use the mathematical tools you need.
It's very hard those days to think of companies/people more arrogant than Anthropic/Dario, which is quite the achievement as the bar is very high.
If that arrogance was well placed at least you could somewhat excuse it, but the fact that it is so overtly hypocritical and based on false premises just makes it so much worse.
Interesting, it doesn't seem intuitive at all to me.
My (wrong?) understanding was that there was a positive correlation between how "good" a tokenizer is in terms of compression and the downstream model performance. Guess not.
Most of the cost (to the government) for Windows is "support" (in a very general sense) and that cost isn't disappearing with Linux.
Especially since it is easier to find badly underpaid (and not particularly competent) Windows sysadmins than it is to find badly underpaid Linux admins.
Ok but the license fees are, what, 50 quid? times say, 3k or 30k people? A 150k or 1.5m injection into the linux ecosystem to develop those would pay for a _lot_ of developers and a _lot_ of developer time.
From what I heard about NGI-zero, another government sponsorship project (1), the problem so far is primarily finding the projects that need sponsorship.
That doesn't seem correct. Almost all of the projects installed on a standard Linux distro need funding. I just stopped applying to NLnet after getting nothing but rejections.
Are you implying that need for support would go away?
If anything the demand would be artificially high at the start of a mass migration, and then presumably level out to something similar to what we see today with Windows.
Not a thing any longer, for the most part. People know how to open a browser on any operating system these days. Go to the menu, run it. Get bored and click the X on the top bar. Source: nearby kids. A few times I've said... "this is Cinnamon, or KDE, or... Windows."
> for the same reason math problems require one to show their working.
We don't put our transitional proofs in papers, only the final best one we have. So that analogy doesn't work.
For every proof in a paper there is probably 100 non-working / ugly sketches or just snippets of proofs that exist somewhere in a notebook or erased on a blackboard.
M5 device are cool but they do have that, as ugly as it is useful, functional diagram printed on the back...
reply