Free & open source · agentic programming

Point is the semantic layer for applications

Not just a language — an open-source layer for coding agents. Install from npm, point create, point dev on the owned runtime. No account, no paywall.

7892%less agent context
39CI repair fixtures
12full-app benchmarks

Live benchmark · Next.js vs .point

Dashboard — add search page

feature add

81%fewer tokens
Point
0
Next.js
0

dashboard.point

Point agent loop

0tokens
Structured check-json only
  1. Agent opens app source
  2. Runs point check-json
  3. Fix: action search items
  4. point check passes
module DashboardApp
… 105 lines …

Next.js + TypeScript

Agent paste workflow

0tokens
Pasting layout, routes, components…
  1. Agent reads build / tsc error
  2. Pastes Next.js scaffold into chat
  3. Still hunting the right file
  4. Wrong fix → retry same paste
error: wiring mismatch in Add a Search page to an existing Next.js admin a…

CI measured · Point 203 tok check-json · Next.js 1,093 tok paste

“General-purpose languages were built for humans reading functions. Agentic engineering needs intent-shaped source and a compiler that returns structured context instead of stderr.”

How Point uses Point

accelerates your stack from rule → check → run → ship.

Write intent-shaped blocks

Records, rules, pages, and pipelines — named semantic blocks instead of scattered functions. One .point file holds product logic agents actually change.

Stable symbols survive formatters. Agents patch at refs, not line numbers.

Platform

Built for the agent loop, not the IDE.

01

Compiler memory

Everything agents need in one JSON turn

check-json, explain, and repair-plan return structured context — ref, span, expected, repair — built for tool calls.

02

All in one

Logic, UI, routes, and pipelines connected

Point replaces siloed TS helpers, route files, and prompt fragments with one checked .point source.

03

Owned runtime

Create, dev, check — no Vite host

Default apps use the owned runtime: SSR pages, forms, theme toggle, refresh, SSE, and WebSocket views from .point source.

It all works as a single system.

One medium for product logic, HTTP, UI, and agent pipelines — checked together, not pasted across files.

  • Smaller

    Smaller than TS paste

    Structured check-json (~170–260 tok) replaces multi-thousand-token file dumps into chat.

  • Clearer

    Clearer than tsc

    Diagnostics ship expected values and repair hints — not opaque property-missing errors.

  • Stable

    More stable than line numbers

    Semantic refs survive formatters. Patch the rule block, not a drifting function line.

  • Provable

    Provable than prompts

    The repair loop runs in CI without an LLM. point check is the gate.

Intent-shaped source

Author semantic blocks

Named rules, records, and views — the product layer agents change every day without repasting thousands of lines into chat.

Language overview →
rule launch readiness
  input signals: Launch Signals
  output score: Int
  score starts at 0
  add 30 when signals.has bundle id
  add 40 when signals.submitted for review
  add 30 when signals.has passing tests
  return score

Live widget

Try it live

Toggle checklist items — score and status labels follow rules compiled from Point source.

Live widget

App Store listing readiness

Toggle checklist items — scoring and status labels follow the same rules as readiness-widget.point in the Point repo.

Score

0

Needs work

Listing checklist

Readiness summary

Needs work

Each completed item adds 20 points. Status thresholds: 90+ ready, 60+ almost ready.

Proof

Measured context, verified repairs

39 fixtures show check-json alone reaches a passing check. Full proof report →

Point check-json~263tokens · CI measured
vs
TS chat paste~3,000tokens · estimated paste
Context saved7892%39 CI fixtures · avg 87%
CI verified — real fixtures, no LLMEstimated — typical agent paste sizeLive model run May 22, 2026, 3:16 AM

Without Point

TypeScript + agent paste

Estimated workflow
  • 1
    tsc error only

    No list of valid field names.

  • 2
    Paste ~3,000 tokens

    Component, lib, tests — agent searches for the right line.

  • 3
    Guess & retry

    Wrong fix → another turn with the same paste.

With Point

check-json → patch → check

CI verified
  • 1
    ~263 token diagnostic

    ref, expected, repair, line number.

  • 2
    One-line fix

    Pick from expected: has bundle id, submitted for review, has passing tests

  • 3
    point check passes

    Same gate the Point repo runs in CI.

Live model benchmark

Which models pass point check after a one-line repair?

Full test hub →
ModelPoint tokPoint passTS tokTS pass
Claude Opus 4.6anthropic~209 tok13/13~1,842 tok13/13
Claude Sonnet 4.6anthropic~209 tok13/13~1,842 tok13/13
GPT-4.1openai~209 tok13/13~1,842 tok13/13

Reproduce CI proof: bun run proof:agent-repair

Full apps: Point vs Next.js agent context

Same product tasks on real multi-block apps (~70–105 lines) — not repair snippets. Point returns structured check-json; the Next.js side is measured from paired scaffolds in the Point repo, not a char-count guess. 12 CI cases · 5897% less context (avg 85%).

Add a /search page to the existing dashboard app: nav link, search action, search view with load data, and page wired into navigation.

Point context
~203 tok check-json
Next scaffold
~1,093 tok measured
Saved
81%
Category
Feature add

Point — check-json gate

{
  "schemaVersion": "point.core.check.v1",
  "ok": false,
  "diagnostics": [
    {
      "code": "unknown-load-action",
      "message": "View search panel loads unknown action search items",
      "path": "view.search panel",
      "ref": "point://semantic/DashboardApp/view.search panel",
      "severity": "error",
      "span": {
        "start": {
          "line": 52,
          "column": 1,
          "offset": 1452
        },
        "end": {
          "line": 52,
          "column": 37,
          "offset": 1488
        }
      },
      "expected": [
        "fetch items"
      ],
      "actual": "search items",
      "repair": "Declare action search items or fix the load data from action name.",
      "relatedRefs": [
        "point://semantic/DashboardApp/view.search panel"
      ]
    }
  ]
}

Next.js — paired scaffold

Add a Search page to an existing Next.js admin app with sidebar nav, items list, and settings — new route, page component, data loader, and nav link.

Missing in broken scaffold: lib/searchItems.ts

// app/admin/layout.tsx
import { AdminNav } from "../../components/AdminNav";

export default function AdminLayout({ children }: { children: React.ReactNode }) {
  return (
    <div className="admin-shell">
      <aside>
        <AdminNav />
      </aside>
      <main>{children}</main>
    </div>
  );
}

// app/admin/settings/page.tsx
import { SettingsForm } from "../../../components/SettingsForm";

const defaultSettings = {
  workspaceName: "Acme",
  notificationsEnabled: true,
  theme: "light",
};

export default function SettingsPage() {
  return (
    <section>
      <h1>Settings</h1>
      <p>Manage workspace preferences</p>
      <SettingsForm settings={defaultSettings} onSettingsChange={() => undefined} />
    </section>
  );
}

// app/admin/items/page.tsx
import { ItemsList } from "../../../components/ItemsList";
import { fetchItems } from "../../../lib/items";

export default async function ItemsPage() {
  const items = await fetchItems();
  return (
    <section>
      <h1>Items</h1>
      <p>Browse tracked items</p>
      <ItemsList items={items} />
    </section>
  );
}

// app/admin/items/[id]/page.tsx
import { ItemDetail } from "../../../../components/ItemDetail";

ex

Verification gate: point check on the full app graph — same in CI and live model eval. All full-app benchmarks →

Three daily moves

createpoint create my-app
devpoint dev
checkpoint check src/app.point

Free & open source

Install Point and start building in .point today.

MIT licensed on GitHub — fork and PR welcome, no org invite. Compiler, LSP, and VS Code extension publish to npm on every release.

npm install -g @hatchingpoint/point
point create my-app
cd my-app
point dev
point check src/app.point