Code session caches

Every hosted coding session starts in a new pod with an empty build cache. A cache declaration keeps the state worth keeping, such as a Go build cache or node_modules, so the next session restores it instead of rebuilding it. In one measured core-api session, a warm Go build cache cut the build from 726 seconds to 179 seconds and go vet from 242 seconds to 12.5 seconds.

Caches belong to your workspace and your repository. They are not container images, and SchemaBounce does not host images.

Declare a cache

Add caches under sandbox in .schemabounce/runtime.yaml:

sandbox:
  ecosystems: [go]
  caches:
    - preset: go
      include: [downloads]
    - name: lint-tools
      paths: ['~/.cache/golangci-lint']
      key:
        files: [go.sum, .golangci.yml]
        prefix: v1
      restore: prefix
  prebuild:
    enabled: true

A preset (go, node, python, rust, jvm, dotnet, ruby, php) names the platform's own paths and key files. Presets cache derived state by default. Add include: [downloads] to cache the raw download cache too.

A custom cache lists up to 8 paths. A path is relative to the repository, or starts with ~/ under .cache, go/pkg/mod, .npm, .m2, .gradle, .cargo/registry, .cargo/git, .nuget/packages or .local/share/pnpm. Anything else is dropped with a warning, and so is anything that looks like a network address.

The cache key is the content of your key files at the pinned commit, plus the toolchain version and the optional prefix. Change a key file and the next session builds a fresh entry. restore: prefix lets a session on a changed key fall back to the newest entry of the same cache and toolchain.

Warm it once with prebuild

A cache is only worth restoring if something filled it. Add prebuild steps to .schemabounce/pipeline.yaml:

prebuild:
  - name: warm-build
    run: cd schemabounce-api && go build ./... && go vet ./...
    timeout: 20m

Prebuild runs only when the base branch has no cache for the current key, after setup and before the agent's first turn. The result is saved for every later session on that branch. Prebuild time counts as code session compute.

Who can write a cache

• A session reads its base branch's cache. It never writes it after the agent's first turn, and a session whose base is an agent branch (sb-code/*) never writes it at all.
• Caches never hold secrets. A save that contains credential files or key material is refused, not redacted.
• Each archive is checked against a sha256 digest before it is unpacked, and unpacking refuses links that leave the cache path, device files and setuid files.
• A cache never changes where a session can connect.

Manage caches

Code, Caches in the console lists every cache with its size, last restore, 7 day hit rate and time saved. Clear one cache from its row menu, or all caches of a repository from the page menu. Caches that no session has restored for 7 days are deleted.