embed DGC in an application or CI job

The DGC SDK runs the same agent inside your own program: an application, a service or a CI job. It is free and local. You do not pay DGC to use it; optional Pricing only attributes the model-token spend your provider bills you.

The published dgc-sdk 0.8.0 pairs with CLI 0.50.0 and 0.50.1 over editor protocol v14. Its release dry run passed on Linux, macOS 26.5.1 (Apple silicon), and Windows 11 through WSL 2 (Ubuntu 24.04). Native Windows remains experimental; focused SDK checks passed there, but the full suite was not run natively. The guide and API reference are in docs/SDK.md. Check PyPI or npm for the published version before installing.

python3 -m pip install dgc-sdk

That installs import dgc_sdk. Do not run pip install dgc: PyPI's package named dgc is a different project. The SDK drives dgc serve from your DGC CLI install and finds it on its own (dgc on PATH, ~/.local/bin/dgc, the installer's versions). DGC_PYTHON or runtime=[...] picks a different one.

import os
import tempfile

from dgc_sdk import DGC

with DGC(
    state_dir=tempfile.mkdtemp(prefix="dgc-sdk-"),
    model=os.environ["DGC_MODEL"],          # for example "qwen3:8b"
    base_url=os.environ["DGC_BASE_URL"],    # for example "http://127.0.0.1:11434/v1"
    api_key=os.environ.get("DGC_API_KEY"),  # only when the endpoint needs a key
) as dgc:
    session = dgc.session(cwd=".", permissions={"mode": "plan", "unhandled": "deny"})
    result = session.run("Summarize this repository in two sentences. Do not edit files.")
    print(result.status, result.final_text)
    if result.error:
        print("error:", result.error)

Each DGC owns one state_dir: an isolated HOME that holds its conversations, checkpoints and logs. Your own ~/.dgc is unused unless you pass inherit_user_state=True. Use a private directory, never a shared fixed path.

with session.stream("Review the checkout flow", max_turns=12, timeout=600) as run:
    for event in run:
        if event.type == "text_delta":
            print(event.data["text"], end="")
    result = run.result()
# run.cancel() stops an in-flight turn, including during an approval wait.

Async: AsyncDGC / await session.stream(...) / async for event in run. Events are plain dictionaries keyed by event.type; docs/SDK.md lists them.

RuntimePolicy(network="deny", deny_tools=("write_file",)) is enforced by the runtime for that session in every permission mode, including auto, and is never saved to a config file: denied tools (custom and MCP tools too), file tools kept inside the workspace, no web or third-party MCP access. Shell commands cannot be held by rules on their text, so by default the policy runs them in the OS sandbox (bwrap or sandbox-exec): no network, no writes outside the workspace. In auto mode the shell runs only there. sandbox={"requirement": "required"} refuses to start a session that cannot be confined.

@vibedgc/sdk (Node 22+) is on the npm registry; the identical tarball is also attached to the GitHub release.

npm install @vibedgc/sdk

import { DGC } from "@vibedgc/sdk";

const dgc = new DGC({ stateDir, model: process.env.DGC_MODEL, baseUrl: process.env.DGC_BASE_URL });
const session = await dgc.session({
  cwd: "./checkout-app",
  permissions: { mode: "plan", unhandled: "deny" },
});
const result = await session.run("Explain the checkout flow. Do not edit files.");
console.log(result.status, result.finalText);
await dgc.close();

With inherit_user_state=True the same client reaches the rest of your DGC profile. session.pips lists its Pips, reads their runs and what each run posted in its own chat (run_posts), and starts or changes one with mutate, which needs your code's approved=True on that call. sdk/PIPS.md lists every call and field with the Pips API it needs, such as a live-data Pip's changes.live_plan (API 60). DGC.chat() is ChatDGC from your program: ask, stream, research and answer, with numbered sources. TypeScript has the same API.

Product page: vibedgc.com/sdk. Source: github.com/OpenPeach-ai/dgc (sdk/).