CtrlK
BlogDocsLog inGet started
Tessl Logo

gg

Working pattern for Grida Gateway (GG) — Grida's first-party, metered, no-BYOK AI surface: the scoped-token mint, the OpenAI-compatible + native gateway endpoints, the `gg` client provider, and the desktop wiring that spends org credit without a user key. Anchor for the `GRIDA-GG: <surface>` grep marker; its security half is `GRIDA-SEC-006`. Use when adding or touching any GG file, the `gg` provider kind, the `gg:ai` token audience, or deciding whether code belongs to the gateway surface. Companions: `security` (the GRIDA-SEC-006 half), `ee-billing` (the ledger it spends), `agent-system` and `desktop` (the two hosts).

74

Quality

92%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Medium

Suggest reviewing before use

SKILL.md
Quality
Evals
Security

gg — Grida Gateway

Grida Gateway (GG) is Grida's first-party AI gateway: the path by which a signed-in client runs AI — text, image, video — without a user-supplied model key (no BYOK), billed to the organization's prepaid credit. It is one coherent, extractable surface, marked so a single grep finds all of it, and it is designed to spin out of this repo into a standalone service at grida.gg. Treat every touch as work on a product that will one day live on its own.

Canonical spec: Hosted AI (metered, no-BYOK). Security boundary: GRIDA-SEC-006 in SECURITY.md.

What counts as GG

The test: does this code exist to let a keyless client spend org credit on a Grida-hosted model? If yes, it is GG. Four surfaces:

  • token — the scoped-token mint + verify. A purpose-scoped, short-lived, org-bound JWT (audience gg:ai) is the only credential the gateway accepts. This surface is also GRIDA-SEC-006.
  • gateway — the server endpoints: the OpenAI-compatible text surface (chat completions, models) and the native image/video generation surfaces. They verify the gg:ai token and meter through the billing seam; they carry no billing logic of their own.
  • provider — the client-side gg provider kind (in the agent package) that resolves to the gateway, plus its in-memory session store, factories, and media adapters. It is the consumer of GG.
  • desktop — the renderer lifecycle that mints/re-mints the token and pushes it to the sidecar (memory-only custody), and the daemon gg capability/namespace that receives it.

Not GG: the billing ledger itself (that is ee-billing / grida_billing); the billing seam's providerOptions.grida namespace (Grida-billing's key, shared with GRIDA-SEC-003); BYOK providers (the carve-out GG sits beside).

The GRIDA-GG marker

Like GRIDA-EE, the surface is grep-able. Tag every file that exists only for GG, with the surface as the sub-label:

// GRIDA-GG: token — scoped-token mint/verify (also GRIDA-SEC-006)
// GRIDA-GG: gateway — OpenAI-compatible chat completions
// GRIDA-GG: provider — the `gg` client provider kind
// GRIDA-GG: desktop — renderer token lifecycle

Sub-labels are surface names (token / gateway / provider / desktop), not ids. The grep is the index:

grep -rn 'GRIDA-GG' editor packages desktop

Tag the file header when the whole file is GG; tag inline when only a branch is (e.g. the gg arm inside a shared provider resolver). The canonical name is Grida Gateway (GG); write it that way in prose.

The naming map (canonical identifiers)

One brand, several forms — consistent with how the repo already names (GRIDA-EE marker + grida_billing schema + descriptive symbols):

conceptidentifier
grep markerGRIDA-GG: <surface>
token audience (wire)gg:ai
signing secret (env)GG_TOKEN_SECRET (+ GG_TOKEN_SECRET_PREVIOUS)
client provider kind (wire)gg
provider id / metadata (code)GG_PROVIDER_ID, GG_PROVIDER_METADATA, isGgProviderId
daemon capability / namespacegg (tag gg@1)
TS symbolsGridaGateway* (e.g. GridaGatewaySessionStore)
filesgg-*.ts
future public hostgrida.gg (endpoint paths stay /api/v1/ai/* for now)

Deliberate carve-outs (not renamed, on purpose): the public endpoint paths (/api/v1/ai/*) — a versioned REST contract whose brand is the host, not the path; and providerOptions.grida — the billing seam's key.

Working on GG

  1. Tag every file you create or touch with GRIDA-GG: <surface>.
  2. Place new code in a gg-named location; don't dilute a BYOK or OSS one.
  3. Direction of dependency: consumers → GG contract, not GG → consumers. The gateway must not import desktop/renderer code; the client provider depends on the wire contract, not the server internals. This is what makes the spin-out cheap.
  4. The gateway meters through the existing billing seam — it never grows its own billing logic. Pre-flight entitlement gate, post-flight usage ingest, sold at cost. See ee-billing.

When GG crosses security

The token surface (mint + verify + custody) is GRIDA-SEC-006. Any file on that surface carries both markers:

// GRIDA-SEC-006 — see /SECURITY.md
// GRIDA-GG: token — scoped-token mint/verify

Touching it runs the security review first (the boundary contract, fail-closed secret handling, audience pinning), then this skill (the surface-organization pass). The invariant to protect: the credential a native process holds for AI is worth at most 15 minutes of AI calls on one org's credit — and nothing more.

Precedence is stated here and cross-referenced from GRIDA-SEC-006 in SECURITY.md, so a reader entering from either side lands in the other.

See also: security (the GRIDA-SEC-006 half), ee-billing (the credit ledger GG spends), ee (the EE marker pattern this mirrors), agent-system and desktop (the two hosts), naming.

Repository
gridaco/grida
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.