DGC v0.41.5 is out
DGC Install
Navigate
Install DGC

SDK · 0.5.2 frozen

Your product.
The DGC harness.

Bring the agent loop into what you build. A Python SDK for applications that work with people, and automations that work while you’re away. TypeScript is in the same repository.

Install the SDK Explore code recipes

Python wheel on GitHub · TypeScript in-tree · protocol v14 · CLI 0.41.5

your intent agent loop observable work
ONE HARNESS · YOUR INTERFACE
Built around the DGC runtime
Local + API modelsTyped eventsExplicit permissions

Get started / SDK + agents

From your terminal.
Or your coding agent.

Choose Python or TypeScript for your integration. Give your coding agent the documentation to help you build it.

Install the current DGC CLI

Install from GitHub.

Python wheel · sdk-v0.5.2
PythonpipGitHub Release
python3 -m pip install "https://github.com/OpenPeach-ai/dgc/releases/download/sdk-v0.5.2/dgc_sdk-0.5.2-py3-none-any.whl"
TypeScriptreposdk/typescript
# from a clone of OpenPeach-ai/dgc
# Node 22+: import sdk/typescript (not on npm yet)

That URL installs our dgc-sdk wheel (import dgc_sdk). Do not run pip install dgc — on PyPI that name is a different, unrelated project. The wheel still needs a DGC runtime (python -m dgc serve, CLI 0.41.5). Set inherit_user_state=False in production.

  1. 01Choose your language

    Python in your environment. TypeScript in your Node project.

  2. 02Connect the runtime

    Use the verified DGC version supported by the SDK release.

  3. 03Open a session

    Set your workspace, model, and permission policy.

01 / The developer experience

From a few lines
to a visible workflow.

Choose a use case. Follow an agent turn from intent to result, with task progress and the permission decision in view.

Interactive concept
01

A coding assistant inside your app.

Stream progress into your interface. Let a person decide when the agent can change a file.

// Proposed API · package not yet published
import { DGC } from "@vibedgc/sdk";

const dgc = new DGC({ binary: "dgc" });
try {
  const session = await dgc.session({
    cwd: "./checkout-app",
    model: "your-configured-model",
    permissions: { mode: "default" },
    onPermission: request => askPerson(request),
  });

  const run = session.stream(
    "Fix the empty-cart checkout error"
  );
  // run.cancel() stops this run.
  for await (const event of run) render(event);
  const result = await run.result();
  showResult(result);
} finally {
  await dgc.close();
}
// askPerson / render / showResult are your app code.
assistant.tsProposed API · subject to change
Session / checkout-appReady
Inspect the checkout flowPending
Add an empty-cart guardPending
Run the focused checksPending
Event stream0 events
  1. Your session’s story appears here.
    Start the demo, or advance one event at a time.

Scripted illustration. No model calls or file changes.

02 / Integration recipes

A few moving parts.
See how they fit.

Start with your workspace. Add progress, decisions, or a job. Explore the code in either language, then select a note to see what each piece does.

One runtime. Two languages.
Your integration, piece by piece.

workspace.ts
import { DGC } from "@vibedgc/sdk";

const dgc = new DGC({ binary: "dgc" });
try {
  const session = await dgc.session({
    cwd: "./checkout-app",
    model: "your-configured-model",
    permissions: { mode: "default", unhandled: "deny" },
  });

  const result = await session.run(
    "Explain the checkout flow. Do not edit files."
  );
  console.log(result.finalText);
} finally {
  await dgc.close();
}
01 · Workspace

The working directory scopes the session to your project. Permission rules still govern tool access; the prompt is not a security boundary.

What your app receivesIllustrated output
session  → ./checkout-app
result   → checkout flow explained
runtime  → closed by the application

SDK 0.5.2. Python snippets belong inside an async function when using AsyncDGC. The workbench output is scripted.

03 / The shape of the system

Your interface.
One agent engine.

The SDK should expose the harness DGC already uses. A managed local process connects your code to sessions, tools, and your configured model.

01

Your surface

Application server
CI or background worker

You own the experience
02

DGC SDK

Python / TypeScript
Sessions, events, results

A typed client contract
03

DGC runtime

Context, tools, permissions
Your configured model

Managed process · NDJSON

A browser UI talks to your application server. The DGC process and provider credentials stay on the server or your machine.

04 / What belongs in v1

Control the work.
See it happen.

Applications and automation get equal priority, built on the same session lifecycle and event model.

How we get there
01

Sessions that pick up where you left off

Create, run, resume, and close a session with explicit ownership, workspace boundaries, and predictable process cleanup.

sessions · history · lifecycle
02

A stream you can build a UI around

Typed messages, tool activity, task updates, approvals, usage, and a final result. Task IDs keep completed work checked off.

events · progress · results
03

Permissions suited to the context

Ask a person inside an app. Apply an explicit policy in a job. Missing decisions fail closed, with cancellation and time limits.

approvals · policy · cancellation
04

Useful outputs, dependable failures

Validated structured results, typed errors, exit outcomes, and usage records make an agent run easier to integrate and test.

schemas · errors · observability

05 / Build direction

A foundation exists.
A public contract comes next.

The current source includes a Python subprocess client and a versioned headless protocol. The SDK work turns that foundation into a supported developer experience.

  1. Existing foundation

    The harness + protocol

    Agent loop, workspace rules, sessions, structured events, and a managed Python client.

  2. Proposed v1 · both tracks

    Python + TypeScript

    Streaming and async lifecycles, approvals, cancellation, structured output, and app + CI examples.

  3. Release gate

    A contract you can trust

    Compatibility tests, OS coverage, API documentation, runnable examples, and signed package releases.

This is a product and API design preview. Scope, names, and release timing remain under review.

06 / A few details

Before you build.

Can I install the SDK today?

Yes. Install the Python wheel from GitHub tag sdk-v0.5.2. TypeScript is in sdk/typescript in that repository (not on npm yet). Do not pip install dgc. You still need a DGC runtime that can run python -m dgc serve (CLI 0.41.5).

Will applications or automation come first?

Both are first-release priorities. Applications need streaming progress and interactive approvals; CI and background jobs need explicit policy, bounded runs, machine-readable results, and reliable cleanup.

Does this run in the browser?

The initial SDK design runs in Node.js or Python, on your server or machine. Your browser interface connects to your backend, which owns the DGC process, workspace, and provider credentials.

Which models will it support?

The SDK should use DGC’s configured native local and API routes. Subscription routes have different tool and permission ownership; their SDK capability contract needs explicit validation before being promised.

Is the code on this page the final API?

No. The examples are illustrative, and the demo is a local scripted sequence. Package names, methods, event names, and output validation are proposed SDK contracts, not claims about the current headless protocol.

Same harness. More places to build.

Make the agent
part of your product.

Explore the proposed API Read the current DGC docs