Latest in AI
Agno 3.1.5: GitHub-Pinned Agents and S3 Checkpoints
Agno's October 19 releases add repository-pinned coding sessions, S3 checkpoint storage and multi-turn evaluation controls for agents.
Agno 3.1.5 adds GitHub-pinned sessions and S3 checkpoint storage for sandboxed Claude and Codex agents. Released on October 19, it gives coding sessions a stable starting revision and a way to recover saved work across replicas. The same day's 3.1.6 release adds multi-turn evaluation controls.
The 3.1.5 release builds on sandbox support introduced in 3.1.4. Its useful change is how the surrounding system manages a coding session: which repository revision it starts from, where its saved state lives and how another process retrieves the result after the container has gone away.
Those concerns become visible as soon as an agent runs beyond one long-lived development machine. A request may resume on another worker, a branch may move while the session is paused, or a completed container may disappear before someone collects its files.
Keep a coding session tied to one source revision
A sandboxed ClaudeAgent or CodexAgent can now receive a Repository configuration with a GitHub URL and branch. The checkout lives at /workspace/repository. On the first turn, Agno resolves and records the source commit; later turns retain that starting identity along with the agent's commits and uncommitted changes.
The versioned repository implementation accepts credential-free GitHub HTTPS URLs. It is not a general adapter for SSH remotes, GitLab or arbitrary Git hosts. A first-turn metadata override can select a branch or a full commit SHA, but cannot replace the configured repository URL.
This is useful for a task that spans multiple turns. If the upstream branch moves between requests, the session can continue from its established source instead of quietly mixing a new checkout with earlier work. It also means a resumed session should not be assumed to include the latest changes on that branch.
Restoration checks the recorded source identity and the presence of the checkout. Missing or mismatched state fails before the model starts, rather than silently creating a replacement checkout. That is an important failure to surface: a fresh repository may look healthy while no longer containing the work the user expects.
Private repository preparation uses GITHUB_READ_TOKEN in the sandbox environment; this flow rejects GITHUB_TOKEN. Teams should provision the intended read access and inspect the wider sandbox's permissions separately. The repository helper's credential handling does not establish a general guarantee about which secrets an agent can access.
Store checkpoints where other replicas can reach them
S3CheckpointStore lets replicas share checkpoint objects through AWS S3 or a compatible endpoint, without sharing a local filesystem. The released storage implementation uses content-addressed archives, with object names based on their digest.
The store needs the agno[s3] optional dependency, an existing bucket and appropriate permissions. Credentials come through the standard AWS SDK environment or role setup. Sandbox compute and the database still need their own configuration; adding a bucket does not create the rest of the execution service.
The default maximum archive size is 1 GiB and can be configured. Large repositories, generated files and build outputs therefore deserve attention before a deployment assumes every session will fit. There is also an optional local download cache, which is off unless configured.
Integrity checks happen at different stages. Uploading hashes the local archive and checks the readable object's size and stored digest metadata. Opening an archive checks its actual bytes against the recorded digest, downloading it when a verified cached copy is unavailable. The metadata-only verification operation does not download and rehash the entire object.
A checkpoint represents saved state from a completed turn. It does not move a running process between machines or promise to recover every step of an interrupted request. Nor does restoring files undo an external effect, such as an API write that already succeeded. Recovery tests should include those boundaries.
Retrieve the output after the container is gone
The new open_run_checkpoint and asynchronous equivalent expose the archive committed by a completed run. Agno's checkpoint access example shows the host reading the saved result independently of the original container.
That gives a service a practical collection step. It can retrieve generated files or inspect a proposed patch after execution ends, then apply its own review and delivery rules. Opening an archive does not automatically merge code, publish an artifact or deploy anything.
A useful acceptance test is to finish a small coding task, remove the original container and retrieve the expected files through another worker. Also test an unavailable object and an oversized archive. Successful generation is only one part of a service that must reliably return the work.
What changes in 3.1.6
Agno 3.1.6 followed later on October 19 and is the latest stable release checked for this article. Its evaluation cases can pass session IDs, state and other run arguments, and accept message inputs with images or files. Cases sharing a session ID can run as consecutive turns.
This makes it easier to describe a test where the second request depends on the first. It does not, by itself, make an agent more accurate. For these repository and checkpoint features, a multi-turn test is especially useful because a single successful answer cannot establish that source identity and edits survive a resume.
The Python package is available under Apache 2.0 and declares Python 3.9 or newer, below Python 4. Optional SDKs may have their own requirements. Model usage, sandbox compute, database service and object storage can all carry separate costs, so the open-source framework does not imply a free hosted coding service.
I'm Paras. I work at the intersection of AI, engineering and distribution.
I help developer-tool and enterprise AI teams explain agent infrastructure, deployment tradeoffs and product releases through useful technical stories and distribution.