ailocal v0.9.1 — context sized from measured runner behaviour

Context geometry, output ceilings and client-native compaction re-derived from measurement rather than inherited rationale. No commands, configuration layout or client files change shape — only the numbers inside the profiles, and what the repository can prove about them.

Larger context windows

Every tier's input window grew substantially. The previous limits described a llama.cpp/GGUF backend the 64 and 128 GB tiers no longer run; no model was ever the constraint, since all four chat models report 262,144 native context.

Tier	architecture input	Compaction trigger
16 GB	57,344 → 90,112	45,875 → 67,891
32 GB	57,344 → 122,880	45,875 → 92,262
64 GB	81,920 → 131,072	49,152 → 111,411
128 GB	81,920 → 245,760	49,152 → 139,264

implementation and review now share architecture's input window instead of roughly half of it. Context capacity and role identity are separate concerns.

16 GB and 32 GB previously carried identical geometry despite different memory and different models. The cause was real: their four roles share one llama.cpp runner, where num_ctx is fixed at first load and an over-long prompt is truncated from the front with HTTP 200 and no error. They must declare one identical total, so context_input and max_output offset each other — raising a single role would have silently clipped the other three. A test now enforces that invariant.

The 128 GB profile is a real profile rather than a copy of the 64 GB one.

Role-based output ceilings

Set by role, identically on every tier:

Role	Output
architecture	16,384
implementation	8,192
review	16,384
fast	4,096 → 8,192
completion (FIM)	128 → 512

The FIM ceiling of 128 truncated multi-line completions mid-block. 512 is still far too small to be usable as a chat role, which is the point.

Client-native compaction

A uniform 85% reserve on all four tiers, so no tier runs a different safety margin. The window stays per-tier, because it encodes the one thing that genuinely differs: how many tokens that tier's runner can cold-prefill inside its latency budget.

ailocal holds no conversation state and does not summarise. The clients compact; ailocal owns and generates the threshold they use.

Improved validation

Tests now assert the output policy, the 85% reserve, the shared-runner invariant, and each model's native ceiling — replacing a single hard-coded danger constant that had been applied to all four tiers from a retired backend.

A pre-existing defect was fixed where the regression gate invoked a separately installed ailocal from PATH rather than the working tree. Because that suite regenerates real client configuration, the stale copy rewrote ~/.config/ailocal from its own bundled resources, making ailocal check alternate between OK and "generated files have drifted".

Release process and documentation

Stale rationale was deleted at source rather than layered over: per-tier prefill timings that outlived the backend which produced them, and a reference to a model size no profile has used since gemma4:26b became active.

Upgrading

Run ailocal start after upgrading to regenerate client configuration and restart the proxy.

If you have edited a file in ~/.config/ailocal/profiles/, ailocal will not overwrite it — that is the standing promise about authored policy, and it means a customised profile keeps its old context values. Compare against the shipped file and merge, or delete yours and re-run ailocal install.

Validation

Measured on 64 GB Apple Silicon: cold prefill for all four models, KV allocation behaviour (MLX lazy, llama.cpp eager at ~21 KB per context token), a 112,817-token request through the full LiteLLM → Ollama → MLX path, and a bounded runtime proof of every changed output ceiling.

gate --full 28/28 · ailocal check OK · installed-runtime 17/17.

The 16, 32 and 128 GB tiers are sized from real measurements of the actual models but remain unverified on their own hardware; each profile records which of its numbers are measured and which are not. The clean-install-on-a-new-machine check is waived for this release only — see RELEASING.md.

ailocal v0.9.0

ailocal provides a local AI development environment for Apple Silicon Macs,
integrating local models with Claude Code, Codex CLI, and VS Code Copilot
through a single local gateway.

Everything runs on your own hardware using Ollama and Docker. Supported clients
are configured automatically when present, while remaining optional.

Highlights

Simple installation

brew install --cask docker-desktop ollama-app
brew install pipx
pipx install git+https://github.com/DevelopSolutionsLLC/ailocal.git
ailocal install
ailocal check

Supported clients

• Claude Code (claude-local)
• Codex CLI (codex-local)
• VS Code Copilot (ailocal-* models)

Clients are optional. ailocal configures only the clients installed on your
machine.

Hardware-aware configuration

Automatically selects appropriate model profiles for Apple Silicon systems with:

• 16 GB
• 32 GB
• 64 GB
• 128 GB (experimental)

No manual profile editing is required for typical installations.

Local API

Provides both an OpenAI-compatible API and an Anthropic-compatible API, allowing
local models to work with existing tooling.

Validation

ailocal check performs an end-to-end validation of prerequisites, runtime,
local gateway, models, client configuration, and live inference — with
actionable remediation when something is missing.

What's new

This release includes extensive stabilization work across the project:

• simplified repository structure
• cleaner packaging
• improved installation experience
• automatic client detection
• improved VS Code integration
• improved Claude Code integration
• improved Codex CLI integration
• cleaner configuration ownership
• removal of obsolete generated artifacts
• stronger validation gates
• improved documentation
• comprehensive installation verification

Known limitations

• Docker Desktop and Ollama must be installed by the user.
• VS Code requires one manual API key paste into its encrypted SecretStorage.
  This is a limitation of the VS Code extension model rather than ailocal.
• 128 GB hardware profiles remain lightly validated compared to the other
  configurations.

Stability

This release establishes the initial public interface for ailocal. Future
releases will aim to preserve compatibility for CLI commands, configuration
layout, generated client configuration, and profile behaviour. Breaking changes
will be documented in release notes.

Thank you

Thanks to everyone who tested early versions, reported issues, and helped
improve the project through repeated installation, packaging, and validation
testing.