Skip to content

v0.80.0

Choose a tag to compare

View all tags
@github-actions github-actions released this 07 Sep 10:05
· 25 commits to main since this release
v0.80.0
41f5e32

openglacier Core v0.80.0

Compile-time capability builds, local LLM and Agent services, and a more capable concurrent CLI.

openglacier Core v0.80.0 changes how the daemon is assembled.

The Core can now be built from explicit capability families instead of always carrying every service implementation in one binary.

The default build stays focused on the local database path:

  • database
  • auth
  • cli

while additional services can be compiled only when they are actually needed:

  • files
  • events
  • data-import
  • llm
  • agent
  • fabric
  • files-watch
  • cli-tui

This release also introduces a local GGUF LLM runtime backed by llama.cpp, a stateless Agent orchestration layer, streaming LLM and Agent operations, cancellation and queueing, and an optional terminal UI for concurrent interactive work.

Highlights

Build only the Core a node needs

Cargo features now describe which implementation families physically exist in a binary.

Runtime capabilities remain a separate concern.

Conceptually:

Cargo features
      │
      ▼
compiled services
      │
      ▼
OGD_NODE_CAPABILITIES
      │
      ▼
enabled services
      │
      ▼
published operations

A capability therefore has two distinct questions:

was it compiled?

and:

is it enabled on this node?

This makes small, purpose-specific binaries possible without changing the operation model.

Compile-time capability profiles

The default feature set is now:

database
auth
cli

This is intended for a local database node with authentication and the administrative CLI.

Additional service families are explicit opt-ins.

For example:

cargo build --release --features files,events

or:

cargo build --release --features llm,agent

A broad daemon build remains available through:

cargo build --release --features full

full compiles the historical service families together with the optional extension providers.

Compilation does not automatically enable every compiled service at runtime.

In particular, extension capabilities such as:

data.import
llm
agent

remain explicit runtime choices.

Build-aware operation catalogue

The canonical operation catalogue now understands build composition.

Operations can describe:

  • their provider capability;
  • the implementation family required to compile them;
  • whether they depend on the internal database engine;
  • whether the implementation exists in the current binary;
  • whether the operation should be published by the current node.

This keeps operation names and wire contracts centralized while allowing different binaries to expose different implementation sets.

Core operations such as:

ping
core.health
core.operations
node.status

remain independent from optional provider families.

The result is a cleaner separation between:

protocol contract

compiled implementation

and:

runtime publication

Local LLM capability

v0.80.0 introduces a local LLM provider backed by:

llama.cpp
GGUF

The capability is compile-time optional through:

llm

and exposes three operations:

llm.status
llm.generate
llm.cancel

llm.generate is streamed.

Generated text is emitted incrementally rather than being buffered until the complete answer is available.

LLM scheduling and cancellation

The local runtime includes a bounded scheduler.

Each generation receives a runId and can begin in either:

running

or:

queued

state.

The scheduler controls:

  • maximum parallel generations;
  • queue capacity;
  • ownership of runs;
  • queued cancellation;
  • active cancellation.

This prevents an embedded model from becoming an unbounded source of concurrent work.

A queued or running generation can be cancelled with:

llm.cancel

LLM configuration

The first local runtime can be configured through environment variables including:

OGD_LLM_MODEL
OGD_LLM_CONTEXT_SIZE
OGD_LLM_THREADS
OGD_LLM_MAX_TOKENS
OGD_LLM_SEED
OGD_LLM_MAX_PARALLEL
OGD_LLM_QUEUE_SIZE
OGD_LLM_CHAT_TEMPLATE

A model is optional at process startup.

Without OGD_LLM_MODEL, the capability can remain compiled while reporting itself as unconfigured.

When configured, the runtime loads the GGUF model locally and uses the model chat template, or an explicit template supplied through configuration.

Stateless Agent capability

v0.80.0 also introduces the first openglacier Agent service.

The Agent is deliberately stateless.

It owns the reasoning and tool loop, but it does not own the underlying capabilities.

Instead, it invokes services supplied by the host.

Conceptually:

Agent
  │
  ├── llm.generate
  │
  ├── database collections
  │
  ├── database query
  │
  └── files

The first tool set contains:

database.collections
database.query
files.list

Database queries issued by the Agent are restricted to read-only execution.

Mutating query plans are rejected before reaching the database capability.

Inherited execution scope

The Agent does not invent its own Place or AppInstance context.

The execution scope is inherited from the request.

That means tool calls do not carry arbitrary scope identifiers chosen by the model.

Conceptually:

request
  │
  ▼
validated Place / AppInstance
  │
  ▼
Agent run
  │
  ▼
tool calls inherit that scope

This keeps Agent orchestration inside the same authorization and execution model as the rest of the Core.

Local or delegated capabilities

The Agent does not assume that its tools are local.

A standalone daemon can invoke local capabilities directly.

A fabric node can delegate the same capability calls through Gateway.

The Agent loop therefore depends on operation contracts rather than concrete backend ownership.

This is important for keeping AI orchestration out of the database kernel itself.

New Agent operations

The Agent service exposes:

agent.status
agent.run

agent.run is streamed.

A run can emit progress around:

  • LLM steps;
  • tool calls;
  • tool results;
  • final messages.

Process-wide Agent limits can be configured with:

OGD_AGENT_MAX_STEPS
OGD_AGENT_LLM_MAX_TOKENS
OGD_AGENT_MAX_TOOL_BYTES

The service retains limits, not conversation state.

Concurrent ogcli

The interactive CLI can now run requests concurrently.

Long-running operations no longer have to monopolize the prompt while they stream output.

Background work is identified by a local job id and can continue while new commands are entered.

This is particularly useful for:

llm.generate
agent.run
long-running queries
streaming operations

The normal REPL remains intentionally thin: it speaks the daemon protocol and does not duplicate server behavior.

Optional terminal UI

A new optional TUI can be compiled with:

cli-tui

and started with:

ogcli --tui

The TUI uses the same concurrent request model as the regular CLI.

It adds:

  • multiple jobs;
  • tabs;
  • tiled views;
  • per-job status;
  • scrolling;
  • focus switching;
  • LLM cancellation.

The interface is therefore a view over the protocol rather than a second execution model.

Capability-oriented daemon composition

Service implementations are now explicitly grouped around capabilities.

Examples include:

database
auth
files
events
data.import
llm
agent

Infrastructure features such as:

fabric
files-watch
cli
cli-tui

remain distinct from published service capabilities.

This helps keep three concerns separate:

database kernel
service provider
user interface

A database-only build should not need to carry an LLM runtime.

An LLM provider should not need to become a database server.

A CLI should not define server semantics.

Compatibility

The operation protocol remains capability-oriented, but build composition changes materially in v0.80.0.

The default Cargo build now contains:

database
auth
cli

rather than every optional service family.

Applications or deployment scripts that require files, events, fabric, data import, LLM, Agent or TUI support should enable the corresponding Cargo features explicitly.

For a broad daemon build:

cargo build --release --features full

Runtime capability selection still applies after compilation.

An operation cannot be enabled if its implementation was not compiled into the binary.

Examples

Default local database build:

cargo build --release

Broad daemon build:

cargo build --release --features full

Local LLM and Agent build:

cargo build --release --features database,auth,cli,llm,agent

Start a configured local LLM provider:

OGD_LLM_MODEL=./models/model.gguf \
OGD_NODE_CAPABILITIES=database,llm,agent \
cargo run --release --features database,auth,cli,llm,agent --bin ogd

Inspect the compiled and published operation surface:

.core.operations

Start the optional terminal UI:

cargo run --release --features cli-tui --bin ogcli -- --tui

In short

v0.80.0 makes openglacier Core more modular at the binary level.

The visible additions are substantial:

compile-time capabilities · local LLM · stateless Agent · concurrent CLI · optional TUI

but the architectural direction is deliberately conservative.

The database engine remains the database engine.

AI services are capabilities.

The CLI remains a client.

And a node only needs to carry the implementation families it actually serves.

Full Changelog: v0.70.4...v0.80.0

Small core, long life.

Assets 40
Loading