← Selected work02 / CASE STUDY

Public code · self-hosted prototype

Terracotta

A personal AI workspace connecting model selection, tool approval, cost accounting, and self-hosting, with visible control over what gets executed.

ROLEProduct design · UI · agent/API implementation · deployment
PERIOD2026.07–
BUILT WITHTypeScript · React / Next.js · Cloudflare Workers · D1 · MCP · Docker
Terracotta workspace with chat, model selection, and a personal garden
Product interface · model calls require provider API access.
Approval before tool actions
MCP

Tool, arguments, and expiry are visible

Container image publishing
GHCR

Public GitHub Actions run history

Persistence and health checks
D1

Local volume · backup procedure

01 / PRODUCT

Overview

The product starts with the friction of switching AI tools while tracking context and cost separately. Model preferences, connected tools, and work history share a single flow.

02 / SYSTEM

Architecture

Provider model catalogs, price data, and execution usage are kept conceptually separate. Catalog refresh is distinct from a registry that promotes trained model artifacts.

  1. 01Router

    Task and model preference

  2. 02Tool loop

    MCP · pending approvals

  3. 03Review

    A second provider

  4. 04Ledger

    Usage and execution traces

03 / DELIVERY

Deployment and validation

Docker and Compose configuration, database health checks, backup instructions, and update procedures are published. GitHub Actions builds container images for GHCR with public run records.

The self-hosted edition is a personal prototype. It does not establish multi-user internet operation or high availability.

  • Image versions and persistent state have separate update and recovery procedures.
  • CI requires lint, build, and tests before publishing. Fourteen local tests pass, covering D1 restore, encryption keys, provider HTTP 504 fallback, and healthcheck failures.

04 / TRADE-OFF

Evaluation

An offline policy benchmark of 24 tasks estimated lower cost against a high-price single-model baseline, but higher cost against a low-price fixed model. This is not measured savings from live API traffic.

The quality axis depended on hand-defined constants and was excluded from performance claims. The next evaluation compares real classification, task success, and cost together.

ENGINEERING DECISIONS

Engineering decisions

01

Explicit approval for writes

Tools that change external state expose their service and arguments before execution. Approval state and traces make agent actions inspectable.

02

Keep state beyond a container

Usage, settings, approval records, and encryption keys persist in a volume. Health checks inspect both the application and database.

03

Remove an unmeasured quality claim

Hand-defined quality constants in a policy simulation cannot establish model quality. That claim was removed, and cost comparisons retain their baseline conditions.

SCOPE & LIMITS

Limitations and scope

  • Real model responses require provider APIs. Subscription and credit UX remain prototypes.
  • Container publication history is distinct from service availability or large-scale model serving.
NEXT CASEMeeting Assistant ↗

Contact

hyunaeee@gmail.com ↗

South Korea · Korean / English

Portfolio PDF

A casebook with roles, engineering decisions, evidence, and source links.

Choose “Save as PDF” in the print dialog.