daily

By Dan Walsh

Enniscorthy native Lystus Ebosele, 24, joined the popular BBC television programme Gladiators as Cyclone in January 2025 but will not return for the 2026 series.

The Sun reports exclusively that she will not appear in the upcoming fourth series, while she maintains that she quit before BBC bosses could axe her.

“I have not been axed, I have left on my own accord,” she said, and added; “I’m so sorry to all the families that have come to filming expecting me to be there and have found out about my absence on arrival to the arena with no explanation.

“It’s not fair to the fans of the show, how things have transpired. It was the correct decision and one I don’t regret at all, she concluded.

Cyclone, whose real name is Lystus Ebosele, is a 5ft 10in Irish powerlifter born in Enniscorthy to Nigerian parents. She won the junior 84kg+ world title in 2023.

Lystus, the sister of Republic of Ireland footballer Festy Ebosele, quickly won over audiences and became an international television celebrity. Festy began his career with Moyne Rangers in their native Enniscorthy.

Last year she posted: “Secret’s finally out, I am so excited to finally be able to share this with you all, I’m joining Gladiators as Cyclone!”

Stateless MCP has recaptured my interest (and inspired mcp-explorer and datasette-mcp) 31st July 2026 Tuesday was Stateless MCP day—the rollout of MCP 2.0, or the 2026-07-28 Model Context Protocol specification to use the more formal but less memorable name. This is the most significant change to the MCP spec since it first launched, and has also served to reignite my personal interest in the protocol. For background: MCP is the Model Context Protocol, which describes a standard way to expose new tools to LLM-powered agent frameworks. It was introduced by Anthropic back in November 2024, had a huge spike of interest through much of 2025, and then became somewhat eclipsed by Skills (another Anthropic invention) when it became apparent that an agent harness with access to a terminal and curl could do most of what MCP did in a more flexible way. I wrote about that in my review of 2025. I’m coming back around to MCP now. Giving an agent a shell environment with the ability to access the internet is fraught with risk, and requires a strong model that is capable of effectively driving such an environment. MCP tools are easier to audit and control, and simple enough that smaller models that run on a laptop can still drive them reasonably well. The new stateless MCP specification also greatly decreases the complexity of implementing both clients and servers for the protocol. I built three of those this week! What’s easier with stateless MCP The best demonstration of the difference between stateful and stateless MCP is in this May 21st blog post that introduced the RC for the new specification. It included a clear before-and-after example. The older stateful MCP (I’m going to call it “legacy MCP”) required two HTTP requests—the first to initialize a session and obtain a Mcp-Session-Id , and the second to actually call the tool: POST /mcp HTTP/1.1 Content-Type: application/json { "jsonrpc": "2.0", "id": 1, "method": "initialize", "params": { "protocolVersion": "2025-11-25", "capabilities": { }, "clientInfo": { "name": "my-app", "version": "1.0" } } } POST /mcp HTTP/1.1 Mcp-Session-Id: 1868a90c-3a3f-4f5b Content-Type: application/json { "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "search", "arguments": { "q": "otters" } } } The new stateless way uses a single HTTP request which looks like this: POST /mcp HTTP/1.1 MCP-Protocol-Version: 2026-07-28 Mcp-Method: tools/call Mcp-Name: search Content-Type: application/json { "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "search", "arguments": { "q": "otters" }, "_meta": { "io.modelcontextprotocol/clientInfo": { "name": "my-app", "version": "1.0" } } } } This is so much cleaner from both a client- and server-side implementation perspective. It’s also a better fit for building scalable web applications, since now you don’t need to maintain server-side state to keep track of those session IDs, or worry about routing the same session to the same backend machine. mcp-explorer I couldn’t find a great CLI tool for interactively probing an MCP server, so I had Codex help build my own. mcp-explorer is the result. It’s a stateless Python CLI tool, so you don’t even need to install it to try it out—it works with uvx like this: uvx mcp-explorer list https://agentic-mermaid.dev/mcp This queries Ade Oshineye’s agentic-mermaid.dev demo MCP. The above command returns the following list of tools: execute(code: string, timeoutMs?: integer) - Execute Mermaid SDK code Run JavaScript in an isolated sandbox; return a value. describe_sdk(family: string, detail?: string) - Describe Mermaid SDK operations Return version-matched mutation operations for one diagram family. render_svg(source: string, options?: object) - Render Mermaid as SVG Render a Mermaid source string to themeable SVG. Returns { ok, svg }. render_ascii(source: string, useAscii?: boolean, targetWidth?: integer, options?: object) - Render Mermaid as text Render a Mermaid source string to text. Returns { ok, text }. render_png(source: string, scale?: number, background?: string, fitTo?: object, options?: object) - Render Mermaid as PNG Rasterize a Mermaid source string to PNG. Returns { ok, png_base64 }. ... Then to inspect a tool: uvx mcp-explorer inspect render_svg This outputs a whole bunch of information, including the JSON schema of the inputs and outputs. To call that tool and pass arguments to it: uvx mcp-explorer call \ https://agentic-mermaid.dev/mcp \ render_svg \ -a source 'graph TD; A-->B' \ -a options '{"padding":24}' Which returns: {"ok":true,"svg":"<svg xmlns=\"http://www.w3.org/2000/svg\" width=... To get just the raw SVG try adding | jq .svg -r to that command. I got back this image: There are a few more commands in the README, but you get the general idea. I find building CLI tools like this to be a really productive way to get familiar with a specification, even if an agent writes most of the actual code. datasette-mcp The second project is datasette-mcp, a Datasette plugin which adds a /-/mcp endpoint to any Datasette instance. This is probably the fourth time I’ve tried building this plugin, but thanks to the new stateless MCP specification I finally have a version that feels good to release. It provides just three tools: list_databases() , get_database_schema(database_name) , and execute_sql(database_name, sql) . They do exactly what you would expect them to do—though execute_sql() is read-only for the moment. Wire these into an agent, or a chat tool like ChatGPT or Claude, and they’ll gain the ability to run SQL queries against your hosted Datasette instance. So far I’m running it on the Datasette mirror of my blog, at datasette.simonwillison.net/-/mcp. It took a bit of fiddling to figure out how to attach that to ChatGPT and Claude, but I got there in the end. Here’s a new TIL showing exactly how to do that. Here’s a shared Claude session where I asked it: list tables in simonwillison.net And then: what has Simon said recently about MCP? It ran 7 separate SQL queries to figure out the answer. llm-mcp-client My LLM tool is long overdue for an official MCP integration. The new alpha llm-mcp-client plugin is my attempt at exactly that: llm install llm-mcp-client llm -T 'MCP("https://datasette.simonwillison.net/-/mcp")' 'count the notes' Here’s the output (including reasoning trace, I’m using LLM 0.32rc2): Considering note count I see the question “count the notes” is probably asking me to tally up blog notes. It could also mean published notes or drafts, so there’s some ambiguity there. I’ll need to figure out the total number of notes, likely by querying the count for both published notes and drafts to get a clear answer. Let’s execute that count! There are 151 notes. And the output of llm logs for that prompt. Once this is fully baked, I’m considering bringing it directly into LLM core. I’m excited to experiment with MCP in Datasette Agent and llm-coding-agent as well. MCP is a safer way to build with agents A few months after MCP was first released, I wrote Model Context Protocol has prompt injection security problems, where I noted that the pattern of having end users mix and match tools pushed responsibility for avoiding data exfiltration attacks out to the users themselves. I hadn’t coined the Lethal Trifecta yet, but that was absolutely what I had in mind. Then general agents with arbitrary shell and curl access came along, and that’s so much harder to keep secure! Something I’ve come to appreciate about MCP is that it’s much easier to reason about agent capabilities and what might go wrong than with arbitrary command execution in an open network environment—the default for most of today’s general and coding agent tools. I plan to lean into MCP a whole lot more when I’m building sensitive applications on top of LLMs.

IP and DNS Leaks in WebKit Affecting Proxy Browsers and Apple iCloud Private Relay Table of Contents Summary# WebKit-based browsers on iOS and macOS can be built to route all web traffic through proxy servers. This is how all proxy browsers work on iOS, including iOS Tor browsers and our own browser, Psylo. Every network connection a web page makes is supposed to flow through the configured proxy, so websites only ever see the proxy’s IP address. We found three WebKit features that bypass the proxy configuration and send traffic directly from the device instead: - DNS prefetching resolves hostnames through the device’s normal DNS path, which reveals the user’s real DNS servers instead of the proxy’s. Available since iOS 26.0. - WebAuthn Related Origin Requests make the operating system’s credential service fetch a validation file directly from the device. This exposes the device’s real IP address. Available since iOS 18.0. - WebTransport opens a direct HTTP/3 connection and bypasses the proxy, which also exposes the device’s real IP address. Available since iOS 26.4. These leaks also impact Apple’s iCloud Private Relay. It must be noted that VPNs are not affected, since they tunnel the device’s entire network traffic at the system level. We’ve reached out to the Tor Project and the developers of Onion Browser on iOS about these issues. To test the leaks, you can visit our proof-of-concept website at leaks.psylo.app. Fixed in Psylo 1.3.1: Psylo now blocks dns-prefetch hints and disables WebTransport and WebAuthn by default. For websites that genuinely need these features, each one can be re-enabled through per-silo toggles. This explicit opt-in keeps the privacy trade-offs in the user’s hands. See Mitigations Introduced in Psylo 1.3.1 for details. Background# Proxy Configuration on iOS and macOS# Introduced in iOS 17 and macOS 14, WKWebsiteDataStore.proxyConfigurations allows WebKit-based browsers route all of their own web traffic through proxy servers at the application level. This API is the foundation of proxy browsers on iOS: every network connection a web page makes is supposed to flow through the configured proxy, so websites only ever see the proxy’s IP address. DNS Leak Reported by a Psylo User# This investigation started with a bug report from a Psylo user who noticed DNS leaks when visiting only certain websites, and we immediately started looking into it. Psylo routes all traffic from each silo through the Mysk Private Proxy Network (or the user’s own configured custom proxy), so DNS queries should all originate from the proxy server and never from the device. It also seemed odd that this only affected some websites, and not all. As we dug deeper, we found the source of the DNS leaks, plus two more leaks that actually reveal the device’s real IP address. All three leaks live in WebKit, where they bypass the proxy settings provided by WKWebsiteDataStore.proxyConfigurations . Since Apple’s App Store policy requires every iOS browser to use WebKit, any iOS browser that relies on this API for proxying is affected, including all iOS Tor browsers and Psylo. These leaks are also present in Apple’s iCloud Private Relay. VPNs, on the other hand, are not affected by these issues, since the device’s entire network traffic is tunneled through the VPN at the system level. iCloud Private Relay# iCloud Private Relay is Apple’s privacy feature for iCloud+ subscribers. When enabled, it proxies Safari’s (and only Safari’s) web traffic and DNS queries through a two-hop relay, designed so that no single party, not even Apple, can see both who you are and which sites you visit. As it turns out, all three leaks described in this article occur outside WebKit’s standard page-loading process, meaning Private Relay is susceptible to the same leaks. 1. DNS Prefetching# DNS prefetching lets a website ask the browser to resolve a hostname before it’s needed. So when later it needs to connect to that hostname, the lookup is already done and the connection starts faster. This is done through a <link rel="dns-prefetch"> HTML tag. When a page includes that tag, WebKit resolves the hostname through the device’s normal DNS path, regardless of any proxy set by the browser through WKWebsiteDataStore.proxyConfigurations . A page can embed unique per-visitor hostnames in these tags, then watch the queries arrive at its own authoritative DNS server from the visitor’s real network rather than the proxy’s. This was the leak behind the original user report, and it explains why only some websites triggered it: without prefetch tags on the page, WebKit doesn’t perform this DNS lookup. Private Relay doesn’t catch this one. It normally proxies Safari’s DNS queries, but these prefetch lookups skip it. The query reaches the authoritative server from the device’s real network even with Private Relay enabled. Desktop Safari has supported <link rel="dns-prefetch"> since Safari 5, but iOS ignored it until iOS 26.0 (September 2025), when WebKit enabled it in the same change that removed iOS’s older, implicit speculative DNS prefetching (bug 285744, 290327@main; browser-compat data). That resolver had been rewritten the year before, to keep hostnames out of system logs during private browsing (bug 272190, 279199@main). 2. WebAuthn Related Origin Requests# WebAuthn is the web standard behind passkeys. A passkey is normally bound to a single domain, but Related Origin Requests let an organization use one passkey across a small set of domains it owns. To make that work, when a page requests a credential whose rpId differs from its own origin, the client first fetches https://<rpId>/.well-known/webauthn , a JSON file listing which origins may use that rpId . That validation fetch doesn’t come from the browser’s network stack. WebKit hands WebAuthn ceremonies to the operating system’s credential service, which issues the HTTPS request itself, directly from the device and unaware of any proxy the host app configured. A page can set rpId to a host of its choosing, and the fetch fires even without user interaction: with mediation: "conditional" and no UI ever appears. The same reasoning applies to iCloud Private Relay. Because the fetch is issued by the operating system’s credential service rather than by Safari, it never enters Private Relay’s proxied path. The destination server sees the device’s real IP address either way. Apple announced the feature for iOS 18.0 / Safari 18.0 (September 2024) in WebKit Features in Safari 18.0. WebKit’s half of the plumbing landed earlier that year (bug 268426, 274592@main) and even shipped, inert, in iOS 17.4; the system component that performs the fetch only gained support in 18.0. 3. WebTransport# WebTransport is a low-latency alternative to WebSocket. It runs over HTTP/3 and QUIC, offers multiple independent streams plus unreliable datagram delivery, and can fall back to HTTP/2 where QUIC is unavailable. Calling new WebTransport(url) opens a QUIC connection straight from the device. WebKit builds the connection with its own network parameters and never offers it the session’s proxy, so the server sees the device’s real IP address instead of the proxy’s. Private Relay doesn’t help here either. WebKit builds the connection outside the web traffic that Private Relay proxies, so a WebTransport server learns the device’s real IP address even with Private Relay enabled. There is one exception: Onion Browser’s “Silver” security level configures WebKit with Lockdown Mode, which disables WebTransport entirely, so Onion Browser users at the Silver level are not affected by this particular leak. First traces of the API appeared in 2023 (bug 260810, 267408@main) but sat disabled until December 2025, when it was switched on for platforms with sufficient Network.framework support (bug 303453, 303860@main). It shipped publicly in iOS 26.4 (March 2026); see WebKit Features for Safari 26.4 and the Safari 26.4 Release Notes. Mitigations Introduced in Psylo 1.3.1# We’ve addressed all three leaks in Psylo 1.3.1: - Psylo blocks dns-prefetch hints, so a page can no longer make your device resolve attacker-controlled hostnames. - WebTransport is disabled by default. - WebAuthn is disabled by default. Passkeys and WebTransport have legitimate uses, so both can be re-enabled at any time through per-silo toggles. This keeps Psylo leak-free out of the box, while users who need one of these features on a given site can opt in explicitly, with a clear understanding of the trade-off.

New release of LLM adds support for reasoning traces, OpenAI Responses, server-side tools, and smarter logging 4th August 2026 I released LLM 0.32 this morning, the most significant new version of LLM since the initial launch of the project. The new version includes support for visible reasoning traces, server-side provider tools, redesigned content-addressable SQLite logs, new models, and new features enabled by the OpenAI Responses API. I also released a new version of the llm-anthropic plugin with substantial updates of its own. Headline features for LLM CLI users Running LLM against reasoning models now displays their reasoning traces to standard error, so you can see what they are “thinking” without that information being included in the standard output that you might pipe to another tool. Add -R/--hide-reasoning to turn this off. LLM includes support out-of-the-box for the GPT-5.6 model family, and the new default model used with llm "prompt" is now the inexpensive but capable GPT-5.6 Luna. LLM calls can now use server-side tools from various providers. OpenAI provide a code execution environment as a server-side tool; LLM can now run prompts that benefit from that like so: llm --tool CodeInterpreter 'Show current python and SQLite versions' OpenAI also gets a WebSearch tool. The llm-anthropic plugin adds WebSearch, WebFetch, CodeExecution, and AnthropicMCP, which looks like this: llm -m claude-sonnet-5 -T 'AnthropicMCP("https://datasette.simonwillison.net/-/mcp")' \ 'how many rows in the blog_blogmark table?' That causes Anthropic to execute MCP calls against my new datasette-mcp plugin as part of a single request/response interaction with their API. The new llm openai endpoint command provides a tool for executing prompts against any OpenAI compatible endpoint as a one-liner. These aren’t logged, which makes this a handy tool for running one-off prompts against anything that speaks the lingua franca of the LLM API world. Here’s how I use that to run prompts against Gemma 4 12B running in my localhost LM Studio API, via uvx (no LLM installation required) and mixing in the llm-tools-quickjs tool plugin for good measure: uvx --with llm-tools-quickjs \ llm openai endpoint http://localhost:1234/v1 -m google/gemma-4-12b \ -T QuickJS 'Use QuickJS to multiply 3434 * 2434' --td New features in the Python API LLM’s Python API previously required you to create a conversation and then send messages to it one at a time. This was an abstraction over the true nature of LLMs, where each request carries a complete history of the messages that came before it. That abstraction started to get in the way for some more advanced cases, so the new release introduces a model.prompt(messages=[]) parameter that can be used like this: import llm from llm import user, assistant, system model = llm.get_model("gpt-5.6-luna") response = model.prompt(messages=[ system("You are a helpful pirate."), user("What is the capital of France?"), assistant("Paris, matey."), user("And Germany?"), ]) print(response.text()) LLM previously returned an iterable sequence of strings from each prompt. This worked great when models returned a string response, but failed to predict the weird shape that models would evolve towards. Today many models return a mix of reasoning text, output strings, tool calls, and even image attachments. With LLM 0.32 you can do this instead: for event in model.prompt("Explain cats").stream_events(): if event.type == "reasoning": print(f"[thinking] {event.chunk}", end="", flush=True) elif event.type == "text": print(event.chunk, end="", flush=True) else: print(f"Other event: {event}") Combine these features and we can finally provide a robust implementation of the semi-standard OpenAI chat completions API, which I’ve now released as the llm-chat-completions-server plugin: llm install llm-chat-completions-server llm chat-completions-server --port 9000 # Server is now running on http://127.0.0.1:9000/v1 Now you can run prompts against LLM via that server, using the new llm openai endpoint command! llm openai endpoint http://127.0.0.1:9000/v1 'hello' -m gpt-5.4-mini The bigger challenge with that kind of API concerns logging. If we’re going to support the pattern where the message sequence is appended to on every request, ideally we can avoid logging all of that duplicate JSON for every turn. The solution is the new content-addressable message store, modeled after Git. You can see the new schema for that in the documentation, but the llm logs and llm logs --json commands have both been upgraded to convert that format back into something that’s easy to consume. And the rest There is a whole lot more in this release. The 0.32 release notes are pretty comprehensive, and the notes for 0.32rc2, 0.32rc, 0.32a3, 0.32a2, and 0.32a0 should fill in any gaps. Existing LLM plugins should all continue to work, but plugins that provide extra models will need to be upgraded to 0.32 in order to participate fully in the new streaming events system. There’s a guide to implementing plugins with Structured messages and streaming events in the documentation. I’ve updated some of my own plugins: - llm-anthropic 0.26 adds support for the Claude 5 family of models, plus WebSearch ,WebFetch ,CodeExecution , andAnthropicMCP server-side tools. - llm-gemini and llm-openrouter and llm-mistral are nearly there, releases coming soon. I guess LLM is an agent framework now Quite a few of the lower-level tools changes in this release were driven by the needs of Datasette Agent. When I started work on LLM, the term “agent” had such a vague definition that I refused to use it. In September 2025 I came around to the idea that "An LLM agent runs tools in a loop to achieve a goal" is well established enough now that I could stop avoiding the term entirely. Tool chains can now pause for human approval and resume from a stored message history—both needed by Datasette Agent. Looking at LLM today it’s beginning to look very agent-shaped to me. There’s something neat about having a CLI utility that can mix and match different tools from different sources with different models all as a one-liner, and that includes a Python library powerful enough to build systems like Datasette Agent and llm-coding-agent. Maybe the next version of LLM will bake the concept of an “agent” into the core library. I’m still trying to figure out what that would look like.

4th August 2026 Includes new features enabled by LLM 0.32: - New models: claude-fable-5 ,claude-sonnet-5 , andclaude-opus-5 . #75, #76- Added server-side tools for WebSearch ,WebFetch ,CodeExecution , andAnthropicMCP , available through LLM's-T interface or Pythontools= . The previous-o web_search* options have been removed in favor of-T WebSearch . #79- Upgraded to llm>=0.32. Reasoning, tool calls, tool results, and server-side tool results now stream as typed events. Reasoning for llm CLI prompts now displays to standard error unless you pass--hide-reasoning/-R .- Simplified extended thinking to thinking andthinking_effort (low ,medium ,high ,xhigh , ormax ). Claude 5 models think by default;-o thinking 0 disables thinking for Sonnet 5 and Opus 5, while Fable 5 always thinks.-R/--hide-reasoning now omits reasoning from responses and logs. Thethinking_budget ,thinking_display , andthinking_adaptive options have been removed. #80 Recent articles - New release of LLM adds support for reasoning traces, OpenAI Responses, server-side tools, and smarter logging - 4th August 2026 - Stateless MCP has recaptured my interest (and inspired mcp-explorer and datasette-mcp) - 31st July 2026 - OpenAI’s accidental cyberattack against Hugging Face is science fiction that happened - 22nd July 2026

4th August 2026 Recent articles - New release of LLM adds support for reasoning traces, OpenAI Responses, server-side tools, and smarter logging - 4th August 2026 - Stateless MCP has recaptured my interest (and inspired mcp-explorer and datasette-mcp) - 31st July 2026 - OpenAI’s accidental cyberattack against Hugging Face is science fiction that happened - 22nd July 2026

Next week, a team of scientists will take to the skies off Ireland’s west coast to observe one of nature’s most spectacular phenomena: a total solar eclipse. The mission on Wednesday, August 12th, aims to provide a rare opportunity to examine the Sun’s outer atmosphere, or corona, and gain new insights into how the Sun’s magnetic field shapes and influences it. Researchers from Ireland and Italy will fly an advanced solar telescope aboard an Irish Air Corps Airbus C295 aircraft to study the Sun’s atmosphere during the total solar eclipse. The eclipse’s path of totality will pass approximately 350km west of Ireland. At the heart of the expedition is a new telescope called E-CorMag, developed by the Italian National Institute for Astrophysics. Although it sits far above the visible surface of the Sun, the corona can reach temperatures of around two million degrees Celsius: hundreds of times hotter than the surface below. Scientists still do not fully understand why this happens. E-CorMag has been designed to help answer that question by measuring the magnetic field of the corona. These magnetic fields are thought to play a major role in shaping the Sun’s atmosphere and releasing huge amounts of energy into space. During a total solar eclipse, the Moon blocks out the Sun’s bright disc, briefly revealing the faint, glowing corona around it. For just a few minutes, scientists get a natural window into a part of the Sun that is usually hidden from view. During the observation, the aircraft’s bubble window will be opened, giving the telescope a clear view of the eclipsed Sun. This means the instrument can observe without looking through standard aircraft windows, which can blur or distort the images. Flying also gives the science team a major advantage: the aircraft can be positioned to spend as much time as possible in the Moon’s shadow, while also reducing the risk of clouds blocking the view from the ground.

By Dan Walsh

His Holiness Pope Leo XIV has appointed Bishop Gerard Nash, (67), to minister simultaneously as Bishop of Ferns and as Bishop of Ossory. 

On 25 January 2026 Pope Leo XIV appointed Bishop Ger Nash, Bishop of Ferns, as the Apostolic Administrator of the Diocese of Ossory. 

An Apostolic Administrator is appointed to temporarily govern a diocese when warranted by special circumstances.  An Apostolic Administrator governs in the name of the Holy Father.  

The two dioceses concerned are now united in persona episcopi, and will be pastorally administered by one bishop, Bishop Nash.

In a statement, Bishop Nash said; I am deeply honoured to have been asked by Pope Leo to become Bishop of Ossory in addition to my existing pastoral role in the Diocese of Ferns. 

“From the earliest days of my appointment as Apostolic Administrator we began a consultation to explore the possibilities for what brings most hope for the future of the church, in both Dioceses.
“This appointment today is simply the continuation of a journey as the two Dioceses will work together to create a community where our relationship with God will deepen and provide fertile soil for the preaching of the Gospel.  This is an opportunity for us to do great things together. 
“The challenge of being one Bishop for two Dioceses is a mirror of the experience of many priests in modern Ireland as they take on responsibility for more than one parish.  The re-imagining of roles and the re- organisation of familiar tasks is true whether it is for a parish or a Diocese and the ultimate test for all change within the Church is whether it builds up the Kingdom of God. 

“In both Ferns and Ossory, there is a history of developing and training lay people over many years, but it has achieved new focus and energy with the recruitment and training of Lay Pastoral Workers in both Dioceses.  It was a great benefit for us here in Ossory that we have already begun the process of discernment and recruitment for those who will begin their studies in Maynooth in September.

“One of the possible collaborations between both Dioceses will be around vocations to priesthood and religious life.  Both Dioceses are working hard at this very important task and already some very good prospects for the Diocesan priesthood are emerging. 

In conclusion, Bishop Nash said; “I am deeply grateful to the people in the parishes of the Diocese of Ossory for their welcome over the past few months but in particular I want to thank the priests and the Diocesan  Staff for their collaboration and their welcome at a personal level.  I also thank the Apostolic Nuncio, Archbishop Montemayor who has been generous with his time and his wisdom in my discussions with him.”

The Diocese of Ossory has a Catholic population of 83,595.  The diocese comprises 42 parishes, 35 priests in active ministry, and covers the areas of most of County Kilkenny, six parishes in County Laois, and one parish in County Offaly. 

On June 11^th 2021, Pope Francis appointed Bishop Nash as Bishop of Ferns.

Pi, Minimal and Performant Pi’s Minimalism Is Its Advantage AI has made code cheap, and as a result many companies are building bigger tools in pursuit of better performance. Larger prompts, more orchestration, more layers, more complexity. This also makes these tools intrinsically more expensive to use. Pi takes the opposite approach. Pi is the coding harness that chooses minimalism on purpose. It comes out of the box with only 4 tools, and its system prompt and tool definitions come in below 1,000 tokens. The idea being that most work can be done with the basics, and if you want more, build it. Evidence increasingly suggests that Pi’s design is not just cleaner; it’s cheaper and more performant. Users are finding that vanilla Pi produces industry leading results, even before adding on extensions to match user specific workflows and needs. As we'll see in case studies of Databricks and Shopify, Pi produced ideal outcomes for both. Case Studies Databricks Study: Cost Per Task Databricks recently shared their findings “Benchmarking Coding Agents on Databricks’ Multi-Million Line Codebase.” The goal of their research was to understand which coding agents offer the best performance on real-world coding tasks, and how task-performance varies with price. To avoid bias from external benchmarks that have become oversaturated, they created their own based on tasks their team of engineers regularly performs. The results match what we would expect, but what many in the industry may have been surprised to learn. In their words, “...the harness a model is called from dramatically impacts cost and quality,” and, “in many cases, simple harnesses like Pi performed best on our workloads.” When combined with Opus 4.8, xhigh, Pi had the highest overall pass-rate, at a significantly lower cost than both Claude Code and Codex. Minimal harness, measurable effect Pi shines because it doesn’t try to wrap the model in a bunch of defaults and instructions that get lost in the instruction hierarchy. Instead, Pi stays out of the model’s way, and the team is able to add what they actually need for their workflow. Databricks’ study is insightful because it separates model from harness. They reported that when they ran the same model with the same thinking effort through different harnesses, “the cost per task differed significantly (more than 2x in some cases), while quality remained the same”. We call this Pi’s “context discipline”. “Pi sent about 3x less context per turn. It managed context better, keeping a tighter working set and finishing the tasks in fewer runs.” We agree that one must take into account end-to-end engineering economics, and not just price per token. And this is also true at the model level; we have observed, for instance, that running complex workflows on Haiku 4.5 was often more expensive than Sonnet 4.6, especially when code execution was involved, simply because the agent required more turns to complete the task successfully. Now we see this at the harness level too; stronger, more expensive models with a performant harness can be cheaper than the converse. Shopify builds Pi Autoresearch: Extensible beats bloat Minimalism is part of Pi’s core philosophy. What makes this work is that minimal does not mean inflexible. In fact, it is the first widely used agentic infrastructure created for extensibility and self-editability. Another insightful external validation of Pi’s design comes from Shopify. In this post from Shopify Engineering, David Cortés describes building pi-autoresearch directly as a Pi extension, by simply asking “Pi, [to] create an extension for Autoresearch...”. Pi reads its own extension documentation and starts building a new workflow from there. Autoresearch is an autonomous loop for optimization with coding agents. When you ask for a change, it runs experiments to find out what works and what causes regressions. For as long as the target is measurable, it can throw out these regressions and keep self-improving. For Shopify and others, the Autoresearch extension quickly became a serious internal productivity tool. Shopify reported cases including unit tests running “300 times faster,” React component mounting “20% faster,” reduced build times across multiple projects, and even improvements to pnpm performance. The important point here is that Pi doesn’t ship any of these tools out of the box. Instead, it makes it ridiculously simple for you to build them. Instead of assuming the vendor knows your workflow and trying to ship every tool under the sun, Pi assumes you know best, and gifts you extensibility to wield and craft your own workflow. Why minimal wins now About a year ago, an argument could be made for native harnesses having a structural advantage over all others, because models were built around them. However, this argument has gotten weaker. Frontier models are now generally very competent at understanding a terminal (or terminal-style) coding environment, and acting within it. Anthropic recently cutting down Claude Code’s system prompt by 80% is a clear sign of this. So the question is becoming less about how native the harness is, and more about how it handles context to avoid redundancy and act with clean primitives. Models need a clean interface to the environment, and a harness that does not waste context. Pi provides this: less prompt overhead and repeated context, cheaper runs, fewer unnecessary abstractions. Because it is extensible, you do not lose power, but gain selectivity. You add complexity only when it “earns its keep”. We are also seeing local models developing fast, and at Earendil we find them very promising. Pi’s context discipline is especially an asset here. Local models usually have lower context windows, and prefill can take a long time, so preserving a stable prompt prefix matters. Context discipline means we do not change the context without the user explicitly asking for it, avoiding minute-long re-prefilling. Combined with the minimal default system prompt and tool set, this makes pi an ideal harness for local models. Pi is proving that it can manage it all. To be cheaper, minimal, and more performant.