Five weeks since the [September roundup](/blog/whats-new-september-2026/), and eighteen minor versions, [v0.32.0](https://github.com/everruns/everruns/releases/tag/v0.32.0) through [v0.49.0](https://github.com/everruns/everruns/releases/tag/v0.49.0). September was about the shape of Everruns: a library as well as a platform. October was mostly about running agents: keeping long turns alive, and giving other software a narrow way to call them.

The largest change is underneath: the core durable engine moved from a workflow-based to an actor-based architecture, which made turns survive crashes, deploys and slow tools. On top of that, agents got an API of their own, agents can work with MCP servers that have thousands of tools, sandboxes are configured once as templates and reused, and credentials and outbound traffic are now scoped per organization and audited. Self-hosting Everruns now takes one command.

![A diagram of what shipped in October, grouped into eight themed cards: Execution (durable execution on the actor model, crash-safe tool calls, long tool calls off the worker, drained deploys), Calling agents (Agent API, A2A 1.0 and AG-UI 1.0, voice channels, Slack DMs and files), Building agents (Agents home, change history, GitHub sync), Seeing the work (Session Trace, coordinator threads, monitoring and tracing), Tools (MCP at scale, Tools in Shell, one web search tool, Knowledge), Sandboxes (templates and fleet view, desktops and recordings, snapshot builder), Credentials and network (scoped credentials, egress policy and proxy), and Running it yourself (everruns docker up, Helm chart, system doctor).](/_astro/feature-map.CwecJLOC.svg)

A note on timing: everything up to v0.49.0 (October 25) is released. A few items from the last days of the month are merged on `main` and ship in the next release; they are marked _next release_ below.

## Execution

### Durable execution on the actor model

We completed the move of the core durable engine from a workflow-based to an actor-based architecture. Until v0.48.0, a turn was a durable workflow: each step (take input, call the model, run tools) was its own task on a queue, any worker could claim it, and the state was checkpointed after every step. That is a reasonable design and it held up, but it put a queue hop and a checkpoint between every step, and it made some things awkward: a cancel could race with the next step, and steering a running turn meant sending signals into a workflow.

Now it follows the actor model ([v0.48.0](https://github.com/everruns/everruns/releases/tag/v0.48.0)): each session has an inbox and an event log, and only one worker at a time acts on it. Storing a message marks the session runnable in the same database transaction. One worker leases the session and runs the whole turn, and the session's event log is the only turn state. If the worker dies, its lease expires and the next worker resumes from the log. A cancel ends only its own turn, a message sent after a cancel always gets an answer, and a brief database error no longer fails a turn. In chaos runs with two servers, three workers and repeated kills, turns ran exactly once. [Durable execution](https://everruns.com/docs/explanation/durable-execution/) explains the model, and the [changelog entry](https://everruns.com/docs/changelog/2026-10-12-sessions-run-as-actors/) has the before and after; Framework users swap the experimental `durable` feature for `local` ([upgrade notes](https://everruns.com/docs/framework/upgrade-notes/)).

![A diagram of one session's turn under the actor model. A message marks the session runnable and one worker leases it and runs the turn from the event log. Three paths branch off: a tool call running past 30 seconds is detached and the turn parks until it finishes, then resumes on any worker; a worker that is shutting down hands the turn to another worker at its next step; a worker that crashes lets its lease expire, and another worker resumes from the log, rerunning only tool calls that are safe to repeat.](/_astro/turn-lifecycle.DAclFqDK.svg)

### Fewer interrupted turns

The actor model also closed three ways a running turn used to get cut short:

- **Crashes.** Tool calls in flight when a worker dies are rerun when that is safe: calls that never started, and calls to read-only or idempotent tools. MCP calls carry a stable idempotency key so a server can return the first result instead of acting twice ([changelog](https://everruns.com/docs/changelog/2026-10-13-tool-calls-survive-crashes/)).
- **Slow tools.** A tool call still running after 30 seconds no longer holds a worker slot; the turn parks and resumes on any worker when the call finishes _(next release, [changelog](https://everruns.com/docs/changelog/2026-10-27-long-tool-calls-free-workers/))_.
- **Deploys.** Servers drain their event streams on restart, and a stopping worker hands each turn to another worker within about a second _(next release, [changelog](https://everruns.com/docs/changelog/2026-10-29-graceful-rolling-deploys/))_.

### Monitoring

With the actor model, there is finally one clean thing to watch. **Monitoring** shows the execution fleet moving through runnable work, model iterations, tools and waiting, refreshed every second with pause and replay, and its Workers tab maps organizations to the workers that own their sessions, down to each actor's lease and ownership history ([Monitoring guide](https://everruns.com/docs/observability/monitoring/)).

![The Monitoring page showing fleet execution flow: runnable sessions, model calls, tool calls and waiting sessions as connected boxes with live counts](/_astro/monitoring.DDmLPjMG.webp)

## Calling agents

### The Agent API

Calling an agent from your own application used to mean using the management API: an organization token that could do far more than the application needed. The [Agent API](https://everruns.com/docs/features/agent-api/) is the narrow version, and it is stable as of [v0.48.0](https://github.com/everruns/everruns/releases/tag/v0.48.0) ([changelog](https://everruns.com/docs/changelog/2026-10-11-agent-api-channel/)). Add an **Agent API** channel to an agent and create a key. The key reaches that one agent and only the sessions it started: start sessions, send messages, stream events over SSE, answer the agent's questions, approve its tools and cancel turns. Channel settings add end users from your own identity provider, allowed browser origins, `Idempotency-Key` retries and a daily spend limit per caller. Keys rotate with an overlap window.

![The Agent keys card on an Agent API channel, with two active keys and Rotate and Revoke buttons](/_astro/agent-api-keys.DAFImdfI.webp)

The [SDKs](https://everruns.com/docs/features/sdk/) for Python, TypeScript and Rust added `AgentClient` for exactly this in [SDK 0.3.0](https://github.com/everruns/sdk/releases/tag/v0.3.0):

```python
from everruns_sdk import AgentClient

agent = AgentClient()  # reads EVERRUNS_AGENT_URL and EVERRUNS_AGENT_KEY
print(await agent.run("What is the status of order 42?"))
```

[Call your agent from code](https://everruns.com/docs/how-to/call-your-agent-from-code/) walks through it end to end, and [Introducing the Agent API](/blog/introducing-agent-api/) explains the design.

### A2A 1.0 and AG-UI 1.0

Both agent protocols Everruns speaks moved to 1.0 ([v0.34.0](https://github.com/everruns/everruns/releases/tag/v0.34.0)). [A2A](https://everruns.com/docs/features/a2a/) channels negotiate 1.0 by header, return the agent's answer as task artifacts, and support `ListTasks`, `SubscribeToTask` and push notifications; since [v0.44.0](https://github.com/everruns/everruns/releases/tag/v0.44.0) every A2A channel also serves the HTTP+JSON binding. [AG-UI](https://everruns.com/docs/features/channels/) channels gained interrupts and resume for questions and approvals, frontend tools and subagents, so clients such as CopilotKit can handle an agent that stops to ask something. Both work in the Framework too: `everruns-serve` answers A2A for every top-level agent, and `Session::ag_ui` streams any Framework session to an AG-UI client from your own server ([Serve AG-UI](https://everruns.com/docs/framework/ag-ui/)).

### Voice channels

Voice is now a channel type ([v0.47.0](https://github.com/everruns/everruns/releases/tag/v0.47.0)). The speech-to-speech model only listens and speaks; the agent, with its own model, tools and instructions, writes every answer. Speech starts sentence by sentence while the answer streams, talking over the agent stops it, and a call and a text chat on the same session share one transcript. The Framework has the same thing as `everruns::voice` ([Voice](https://everruns.com/docs/features/voice/)).

### Agents in Slack

An Everruns agent can now be a full member of a Slack workspace. An organization admin connects one or more workspaces once in Settings; after that, putting an agent in Slack is picking a workspace and approving one consent screen. Each agent gets its own Slack app, named after it and using its avatar as the app icon ([changelog](https://everruns.com/docs/changelog/2026-10-01-slack-workspaces-per-organization/)).

In Slack, people can DM the agent and get the answer in the DM, or mention it in a channel and get a reply in the thread. Replies stream in and render as proper Slack messages. Files sent with a message are stored read-only in the session, up to 10 files of 25 MiB each, so the agent can open a PDF or spreadsheet someone drops in ([changelog](https://everruns.com/docs/changelog/2026-10-13-slack-agents-dms-and-files/)). A schedule trigger can run in a DM or channel, so an agent can post a morning summary or a reminder into the same conversation each day ([changelog](https://everruns.com/docs/changelog/2026-10-18-schedule-triggers-in-slack-conversations/)). If a Slack installation loses a permission, Settings → Health says so and walks through the fix.

![An agent called Kids Duties as defined in Everruns, its page with the Execution settings, tabs and instructions, with the same agent's Slack app laid over it, posting its morning message in Ukrainian with a linked daily schedule card.](/_astro/slack.-XGP7FMe.webp)

The agent above runs a household: its instructions, memory and schedule live in Everruns, and the family talks to it in Slack. For channels with several people, the new **Explicit** [communication](https://everruns.com/docs/features/explicit-communication/) setting treats the agent's text as private notes, so it speaks only by calling `send_message` and stays silent when it has nothing to add. The [Slack guide](https://everruns.com/docs/capabilities/slack/) covers setup.

### Personal agents: Poppy and PACT

Two protocols for the case where a person's own agent deals with a company's agent. With the `poppy_client` capability, an Everruns agent can find a company that publishes `/.well-known/poppy.json` through the [Personal Agent Protocol](https://everruns.com/docs/features/poppy/), talk to its agent and hand off to a person there; Platform Chat has it, and the Framework has `PoppyPersonalAgent`. On the company side, an A2A channel can accept personal agents under the PACT 1.0 profiles, with each conversation bound to the calling user and, with delegation on, a signed receipt for what the personal agent did on the user's behalf ([changelog](https://everruns.com/docs/changelog/2026-10-07-a2a-http-json-and-pact/), with a short video).

## Building agents

### Agents home and the agent builder

The **Agents** page now shows what each agent is doing: its channels and triggers, run bars for the last 24 hours, and a **Needs attention** list for setup problems, with failure counts linking to the exact failed turn. **New agent** offers Describe, Example, Blank and Import; Describe drafts the whole agent, including channels and a schedule, from a sentence. `everruns agents draft` runs the same builder from the CLI ([v0.47.0](https://github.com/everruns/everruns/releases/tag/v0.47.0)). For testing, a shared **Playground** holds the organization's test conversations, where admins can run an agent as a chosen end user, separate from your own Chat.

### Change history replaces agent versions

Agent versions, with publishing, a default version and version pins, are gone ([v0.44.0](https://github.com/everruns/everruns/releases/tag/v0.44.0)). In their place, change history ([v0.42.0](https://github.com/everruns/everruns/releases/tag/v0.42.0)): every change to every entity records who made it, through which surface (UI, CLI, API or an agent), and why. Configuration changes create numbered revisions you can compare and restore. Channels, triggers and sessions run the agent's current configuration, and each session records the revision it started on. Agents that change configuration must give a reason by default, and **Manager notes** hold context an agent reads before it changes something ([Change history](https://everruns.com/docs/features/change-history/)).

![An agent's History entry for a prompt change, showing the reason given and a diff against the current configuration, with a Restore this point button](/_astro/change-history.HA8iCevB.webp)

### Agent source synced with GitHub

An agent's definition can now live in a GitHub repository and sync continuously into Everruns. In two-way mode, edits saved in Everruns are committed back to the branch; if both sides change, sync pauses and keeps your local edits for review ([v0.49.0](https://github.com/everruns/everruns/releases/tag/v0.49.0), [Define agents as files](https://everruns.com/docs/how-to/define-agents-as-files/)).

## Seeing the work

### Session Trace

A session now opens on **Trace**, which replaced the Transcript and Timeline tabs ([v0.48.0](https://github.com/everruns/everruns/releases/tag/v0.48.0)). It lays out each turn's model calls, tool calls, approvals and subagents with timing bars, and the inspector shows a step's input, output, the full model request and the raw events ([changelog](https://everruns.com/docs/changelog/2026-10-10-session-trace-view/)). It also names prompt cache resets and their likely cause, such as a changed tool list or an idle gap. The same data is at `/v1/sessions/{id}/trace` and in `everruns sessions trace`.

![The Session Trace tab with a turn's steps laid out as a waterfall and the inspector open on a write_file call](/_astro/session-trace.Bo5TizfE.webp)

### Coordinator threads

This is a new way to work with an agent. Instead of one long chat that does everything in sequence, you talk to a coordinator, and the coordinator hands each piece of work to its own thread: a child session with its own context, its own checklist and its own tools. You can start several pieces of work in one message and keep talking while they run ([v0.45.0](https://github.com/everruns/everruns/releases/tag/v0.45.0), [changelog](https://everruns.com/docs/changelog/2026-10-08-coordinator-threads/)).

![A diagram of coordinator threads. You talk to one conversation with Platform Chat, the coordinator. It starts threads and relays follow-ups to them; each thread is a child session shown with its status: Working, with its own checklist; Needs you, waiting on a question; Ready for review, finished with a summary. Every report from a thread wakes the coordinator, so nothing polls.](/_astro/coordinator.B0d6B7uJ.svg)

Every thread report wakes the coordinator with an automatic update, so nothing polls and nothing is forgotten. In Platform Chat, the **Threads** panel sits beside the conversation as a board of what is working, what needs you and what is ready for review. You can open any thread to follow its progress or answer its question, and resolve it when you are done. When a thread finishes, the conversation shows one folded line, such as "Releases is done", with the full report a click away. Organization admins turn it on with **Chat threads** in Settings → Features ([Chat and threads](https://everruns.com/docs/features/ui/)).

![Platform Chat with a finished background work card, and the Work panel listing the thread as ready for review](/_astro/coordinator-threads.CTvNX8Hb.webp)

It is not limited to Platform Chat. Any agent becomes a coordinator with the `coordination` capability, and a published Work Chat can run as one main conversation with work threads. In the Framework, `everruns::coordination` runs threads as sessions of the same engine in your own process, and `coordination::threads` returns each thread's status ([Coordinator agents](https://everruns.com/docs/framework/coordination/)).

For your own observability stack, agents can now send traces to several Braintrust projects and OTLP collectors, with organization defaults and per-agent overrides; message content is exported only when you opt in _(next release, [Tracing destinations](https://everruns.com/docs/observability/destinations/))_.

## Tools

### MCP at scale

Some MCP servers expose thousands of tools, and putting all of them in a model's context does not work. Everruns now loads every page of a catalog, searches tool names, descriptions and parameter schemas, and reveals only the schemas an agent asks for, within a fixed budget, so agents work with servers of 2,000+ tools ([v0.49.0](https://github.com/everruns/everruns/releases/tag/v0.49.0), [changelog](https://everruns.com/docs/changelog/2026-10-21-large-mcp-catalogs/)). Agents also accept [MCP Tasks](https://everruns.com/docs/features/mcp/): a server can answer a slow call with a task, and the agent checks on it for up to 30 minutes instead of hitting the request timeout. Each server can set its own tool call timeout, from one second to 30 minutes.

People can add their own MCP servers in Settings and use them in chat, organization MCP tools can be labeled read-only or "changes things" to decide which need approval, and the Everruns MCP server itself now renders as an MCP App in ChatGPT and Codex, with a live session view and approval buttons ([User MCP servers](https://everruns.com/docs/features/user-mcp-servers/)).

### Tools in Shell and saved scripts

The [Tools in Shell](https://everruns.com/docs/capabilities/tools-in-shell/) capability moves an agent's tools, MCP servers included, into one `tools` command in its Bashkit shell. One script can call several tools and filter the results before the model sees them:

```bash
tools github list-pulls '{"repo":"acme/api","state":"open"}' | jq -r '.[].number'
```

Every call still goes through the turn's tool policy, a script that would need approval is held before it starts, and `tools plan` lists a script's calls and their risk without running anything. Agents can also keep [saved scripts](https://everruns.com/docs/changelog/2026-10-09-agent-saved-scripts/), and a schedule or webhook trigger can run one with the event payload and no model call at all ([v0.48.0](https://github.com/everruns/everruns/releases/tag/v0.48.0)).

### One web search tool

Agents search with one `web_search` tool whatever answers it: the model's own search, Brave, Parallel, Cloudflare Web Search, or keyless free search as the fallback ([v0.48.0](https://github.com/everruns/everruns/releases/tag/v0.48.0), [Web search](https://everruns.com/docs/capabilities/web-search/)). Admins connect search accounts and set organization defaults, and each agent picks its own. With the Web Citations capability, each sentence backed by a search result links to that page.

### Knowledge

[Knowledge](https://everruns.com/docs/capabilities/knowledge/) mounts a collection of files into an agent's workspace: uploaded documents, source trees from GitHub or any public HTTPS Git repository, runbooks, exported tickets, any large body of text. The agent searches it the way a coding agent searches a repository, with `grep` and by reading files, so a collection is useful with no index at all; keyword or hybrid search can be turned on when it gets large ([v0.49.0](https://github.com/everruns/everruns/releases/tag/v0.49.0), [changelog](https://everruns.com/docs/changelog/2026-10-23-unified-knowledge-files/)). Original files and folders are kept as they are. Word documents, spreadsheets and HTML are converted to Markdown by [Markkit](https://github.com/everruns/markkit), so they are greppable too, and the originals stay downloadable.

### Browser and computer use

Agents can operate a browser on Browserless with the `browser_use` capability, reading pages as an accessibility tree and acting on elements by reference, and a full Linux desktop through the `computer` tool ([Computer use](https://everruns.com/docs/capabilities/computer-use/)). Both are experimental. Screenshots from tools now reach the model as images, and _(next release)_ long computer-use sessions full of screenshots no longer freeze.

## Sandboxes

### Sandbox Templates and the fleet view

A [Sandbox Template](https://everruns.com/docs/features/sandbox-templates/) names where an agent's commands run: the Bashkit virtual workspace or a managed provider such as Daytona or E2B, with credentials, durability and lifecycle. Editing a template creates a new immutable revision, and running sessions keep the one they started with. The **Sandboxes** page lists every sandbox in the organization across providers, with a lifecycle timeline and pause, resume and delete ([v0.42.0](https://github.com/everruns/everruns/releases/tag/v0.42.0)). Sandboxes are treated as disposable: paused ones are deleted after a day, while their records are kept.

### Desktops, recordings and snapshots

Templates gained several switches through the month. Daytona and E2B templates can block the network or allow only listed domains, enforced by the provider. A **Desktop** switch starts the sandbox with a Linux desktop the agent operates with the `computer` tool, on the same machine as its shell and files. On Daytona, that desktop is recorded: each turn's video is saved to the session's files and plays in chat under the turn, so you can watch what the agent did. Session files now stream, so recordings seek in the browser and files up to 2 GiB fit (both _next release_). And instead of installing the same toolchain in every session, you can build a reusable Daytona snapshot from an install script, verified in fresh compute before it can be saved as a new template revision _(next release, [changelog](https://everruns.com/docs/changelog/2026-10-29-sandbox-snapshot-builder/) with a video)_.

## Credentials and network

### Scoped credentials

Agents need API keys; they should not be able to read them. Session secrets became write-only to agents in [v0.49.0](https://github.com/everruns/everruns/releases/tag/v0.49.0): an agent can store and delete a secret, but no tool returns its value. An **HTTP API** binding ties a key to one URL, and the agent's shell calls the API with `$NAME` while the model only ever sees a placeholder; the platform injects the key for that URL and redacts it if a response echoes it back. Credentials can belong to a user, an agent, a session or the organization, organization credentials need an explicit grant per agent, and Web Fetch can capture a token from a response straight into encrypted storage after approval of the exact request ([Bashkit shell: API keys the agent never sees](https://everruns.com/docs/capabilities/bashkit-shell/)).

Personal access tokens can now be read-only, and Everruns Cloud is adding an account hub with optional passkeys, where you can review and revoke sign-in devices, connections and API tokens.

### Outbound traffic

Self-hosted deployments choose an outbound policy, `open`, `curated-writes` or `curated-all`, and every outbound request is logged with its organization and session ([v0.48.0](https://github.com/everruns/everruns/releases/tag/v0.48.0)). The server image now ships `everruns-egress-proxy`: point workers at it and agent, MCP and integration traffic leaves from its own address, with per-organization caps and usage counts, while model provider calls keep going out directly. So one tenant's traffic getting an address blocked does not take model calls down with it. Threat-intelligence deny feeds can refuse known malware and phishing domains for every organization, and E2B sandbox traffic can go through the same proxy _(both next release)_.

## Running Everruns yourself

### `everruns docker up`

`everruns docker up` starts the self-hosted Platform on your machine: it checks Docker, asks who signs in, your admin email and an LLM provider, generates the secrets, waits for the server to be healthy and signs the CLI in. Running it again is safe, and `upgrade`, `reset`, `status` and `logs` manage the instance ([v0.49.0](https://github.com/everruns/everruns/releases/tag/v0.49.0), [Docker Compose](https://everruns.com/docs/getting-started/docker-compose/), [changelog](https://everruns.com/docs/changelog/2026-10-25-everruns-docker-up/)).

### Helm chart

For Kubernetes there is now an official Helm chart, published as an OCI chart with every release starting with [v0.49.0](https://github.com/everruns/everruns/releases/tag/v0.49.0):

```bash
helm install everruns oci://ghcr.io/everruns/charts/everruns \
  --namespace everruns --create-namespace \
  --set database.url="$DATABASE_URL" --set auth.adminEmail=you@example.com \
  --set publicUrl=https://everruns.example.com
```

It runs the API server, workers, the UI, a proxy with the same routes as the Docker Compose setup, and NATS. You bring PostgreSQL, such as a managed database or one run by CloudNativePG; a bundled single PostgreSQL pod is there for experiments. The server applies database migrations when it starts, and workers scale with `worker.replicas` or on queue depth with KEDA. On the first install the chart generates the encryption key, session signing key, worker token and admin password into one Secret, and every upgrade reads them back instead of making new ones, so stored credentials stay readable. Sign-in works the same as on Docker: one admin, open sign-up, or none.

It is a chart, not an operator, on purpose: PostgreSQL is the only stateful part, and agents and sessions live in the database behind the API, so they are managed with the CLI, the UI or MCP rather than as Kubernetes objects ([Kubernetes](https://everruns.com/docs/getting-started/kubernetes/), [changelog](https://everruns.com/docs/changelog/2026-10-25-helm-chart/)).

### System health doctor

**System → Health** checks every part of an install, the database, workers and their versions, each API server, keys, NATS, Valkey, S3 storage and metrics scraping, and says what it found, why it matters and how to fix it. Parts you do not use show as notes, so a laptop install and a multi-replica cluster both come out clean when set up right. The same report runs from a terminal with `everruns docker doctor` or `everruns-server --doctor` and exits non-zero on a problem _(next release, [System doctor](https://everruns.com/docs/sre/system-doctor/), [changelog](https://everruns.com/docs/changelog/2026-10-27-system-health-doctor/))_.

### Your own agent workers

Two experimental ways to keep Everruns sessions, chat and traces while running the agent yourself _(both next release)_. Self-hosted installations can connect [custom agent workers](https://everruns.com/docs/how-to/custom-agent-workers/) that own their model calls, tools and database access. And an ordinary agent can point at an agent running in your own infrastructure over HTTPS; the [Cloudflare Agent guide](https://everruns.com/docs/how-to/cloudflare-agent/) has a complete JavaScript example with a private D1 database tool.

## The Framework

- **Fewer crates.** Engine, host, builtins, MCP and AG-UI became features of `everruns-core`, drivers moved into `everruns-drivers`, and the published set shrank to 37 crates ([v0.41.0](https://github.com/everruns/everruns/releases/tag/v0.41.0), [upgrade notes](https://everruns.com/docs/framework/upgrade-notes/)).
- **Live session controls.** A host can run slash commands, activate capabilities, and change model, reasoning effort and MCP servers on a running session, and attach its own capabilities, provider resolution and observers to an `Engine`.
- **Batches.** Independent completions can go through the providers' batch APIs, Anthropic, OpenAI, Gemini, Mistral, Fireworks and Groq, with a serializable ticket you collect from another process _(next release, [Batch model requests](https://everruns.com/docs/framework/batch-model-requests/))_.
- **Serving.** The durable workflow engine is published as `everruns-durable`, `serve` can keep daemon data in S3 and require API keys or OIDC, and the experimental `everruns-serve-agentcore` crate hosts a serve app on Amazon Bedrock AgentCore Runtime.

## Also this month

- **Models.** Claude Sonnet 5.5 and Haiku 5.5, GPT-6.1 Sol with fast and ultrafast tiers, Meta's Muse Wonder with a reasoning effort picker on every Muse model, and Gemini 4 Argon, which continues long responses across requests. Cloudflare AI Gateway and Vercel AI Gateway are new providers.
- **Prompt caching.** Revealing a tool no longer resets the prompt cache on current Claude and GPT-6 models, and caching now works on Bedrock, Claude through OpenRouter, and Mistral.
- **GitHub.** Agents can create and install their own GitHub App, wake on pull request events and CI results, and check out private pull requests into their sandbox; PR reviewer and security scanner templates use it ([GitHub](https://everruns.com/docs/capabilities/github/)).
- **Languages.** _(Next release)_ The interface is available in Ukrainian, French, German, Spanish, Chinese and British English, and agents can carry translated names.
- **Everruns Cloud.** A Usage tab breaks down spend by day, model and agent, with CSV export, and warns when credit runs low.
- **Docs.** The documentation moved to [everruns.com/docs](https://everruns.com/docs/), with a public [changelog](https://everruns.com/docs/changelog/) that has an entry for every user-facing change (most sections of this post link to theirs), and the UI's [design system](https://everruns.com/docs/design-system/) is now documented there too.

## Around the family

[**Yolop**](/yolop/) went from v0.18.4 to [v0.22.0](https://github.com/everruns/yolop/releases/tag/v0.22.0). Coordination threads now run as separate headless Yolop processes, each in its own worktree, on a THREADS board in the TUI. Setup reaches six more providers (Mistral, Fireworks, Vercel, Cloudflare, MAI and native Gemini), new setups default to the latest model on each, and model discovery searches provider catalogs and pings a model before you pick it. Code search works on machines without ripgrep, web search uses the shared `web_search` tool, and the Windows shell runs in an in-process container.

[**Bashkit**](https://github.com/everruns/bashkit) had its biggest month. An opt-in `cpython` feature makes `python3` real CPython 3.14 in a WebAssembly sandbox, with HTTP going through Bashkit's network policy. A `terminal` feature adds `vi`, `less` and a `TerminalTool` that lets an agent type keys across named tabs. `awk` was rewritten to follow gawk 5.2, background jobs and pipeline stages run concurrently, and there is a `make` builtin plus 21 everyday commands that scripts tend to call.

[**Markkit**](https://github.com/everruns/markkit) is new this month. It turns documents into clean Markdown for LLMs and agents: HTML, Word, PowerPoint, OpenDocument, EPUB, spreadsheets, email, Jupyter notebooks and PDF (with optional OCR). It is built for untrusted input, so it runs no scripts, macros or formulas and bounds decompression and document size. It ships as a Rust crate, a CLI, Python and Node.js bindings and a WebAssembly package, and it is what Knowledge uses to make documents searchable.

[**Fetchkit**](https://github.com/everruns/fetchkit) is the web fetcher behind Everruns' [Web Fetch](https://everruns.com/docs/capabilities/web-fetch/) tool, and reached v0.6.0. It turns URLs into LLM-ready Markdown, with dedicated fetchers for GitHub code, issues and repositories, package registries, Stack Overflow, Wikipedia, arXiv, YouTube, Hacker News, RSS feeds and docs sites with `llms.txt`, plus a low-noise extraction mode for agents. Private addresses are blocked by default. It is a Rust library, a CLI, an MCP server and Python bindings.

The **SDKs** reached [v0.3.1](https://github.com/everruns/sdk/releases/tag/v0.3.1): `AgentClient`, change reasons with `with_reason`, and a default base URL that points at Everruns Cloud.

---

All of it is open source and MIT-licensed: [everruns/everruns](https://github.com/everruns/everruns), [everruns/yolop](https://github.com/everruns/yolop), [everruns/bashkit](https://github.com/everruns/bashkit), [everruns/markkit](https://github.com/everruns/markkit), [everruns/fetchkit](https://github.com/everruns/fetchkit). Run `everruns docker up`, read [everruns.com/docs](https://everruns.com/docs/), or try [Everruns Cloud](/cloud/). Questions go to [contact@everruns.com](mailto:contact@everruns.com).

---

## Machine-readable entry points

- [/llms.txt](https://everruns.com/llms.txt): index of this site written for language models.
- [/llms-full.txt](https://everruns.com/llms-full.txt): every page on this site as one document.
- [/auth.md](https://everruns.com/auth.md): how an agent obtains Everruns API credentials.
- [/.well-known/ai-catalog.json](https://everruns.com/.well-known/ai-catalog.json): ARD capability manifest.
- [/.well-known/mcp/server-card.json](https://everruns.com/.well-known/mcp/server-card.json): MCP server card for Everruns Cloud.
- [/.well-known/agent-skills/index.json](https://everruns.com/.well-known/agent-skills/index.json): agent skills for working with Everruns.

Any page on this site serves Markdown to `Accept: text/markdown`.