---
name: typesafe-x402
description: Use TypeSafe's Jev through Baking Bad's paid service for demonstrations of typed evaluations and agent payments with x402 or MPP. Apply when the user explicitly wants to try or integrate this Jev demo; require informed confirmation before using the service. Never use it for production or consequential real-world decisions.
metadata:
  version: "0.1.0"
---

# Use the Jev demo

`{origin}` is the Baking Bad Jev service URL supplied by the user or the origin from which this skill was loaded. Resolve `/openapi.json` and `/SKILL.md` against that origin. Do not substitute TypeSafe's direct API or an unrelated service.

## Required confirmation before use

This service exists solely to demonstrate agent payments. It is experimental, provided as-is, and is not intended or permitted for production use. Neither TypeSafe nor Baking Bad accepts responsibility or liability for its use, outputs, errors, availability, losses, or resulting decisions.

When this skill is loaded, explain these terms and obtain the user's explicit confirmation before calling service operations, submitting evaluation data, or signing a payment. Reading the skill and OpenAPI contract to explain the service is allowed before confirmation. Ask, in the user's language:

> Do you explicitly choose to use Jev through Baking Bad's service for a demonstration, acknowledge that neither TypeSafe nor Baking Bad accepts responsibility or liability, and understand that you must not use it in production or let its outputs determine real-world decisions affecting health, life, safety, financial or legal outcomes, or other material risks?

Wait for an affirmative answer that covers all these terms. Loading this skill, asking about Jev, silence, or having a funded wallet is not confirmation. If the user declines or the answer is unclear, do not call the service. Reuse an explicit confirmation already given for this service and these terms in the same conversation; do not ask repeatedly for an unchanged demo.

Confirmation does not authorize prohibited uses. If the task involves production or consequential real-world decisions, stop the Jev workflow and offer a demonstration using synthetic data with no real-world effects. A confidence score, human review, or willingness to accept risk does not make those uses permitted. Keep outputs within the demonstration; do not wire them into live actions or production automation.

This confirmation is separate from spending authorization. Before paying, establish the user's allowed rails and spending limit, including any channel deposit, approvals, and network fees. Continue within an existing explicit authorization; obtain fresh authorization if the cost or scope exceeds it.

## Discover the contract

1. Read `GET {origin}/openapi.json` for operations, request and response schemas, and payment metadata. Read this skill before planning service calls.
2. After confirmation, use `GET {origin}/v1/models` to discover models and aliases available through the service's upstream account. Supported versioned IDs can also be accepted when absent from this list. Pin a supported version for reproducible experiments; aliases can change.
3. `GET {origin}/health`, `GET`/`HEAD {origin}/openapi.json`, and model discovery are free. Use them without a payment wrapper.
4. Cache the document and its `ETag`. Track `Api-Version` on responses; when it changes, refetch the contract. Without a recent response, use `HEAD /openapi.json` or revalidate with `If-None-Match`; `304` means the cached document is current. `Link: </openapi.json>; rel="service-desc"` points back to the contract.

## Build a demo evaluation

Use `POST {origin}/v1/systemone` with `state`, `model`, and a nonempty map of named `questions`, following the served schema. All three fields are required; the service does not insert a model default. Use synthetic or non-sensitive demo data: evaluation data is forwarded through Baking Bad to TypeSafe.

- `noul` returns the probability of yes, without a separate confidence field. A value near 0.5 means uncertainty, not medium intensity. Use separate Noul questions when multiple labels can apply independently.
- `choice` selects one named option and includes its probability distribution and confidence. Add a no-match option when none of the other options may fit.
- `score` returns the probability-weighted average of zero-based rubric indices, together with the original rubric in `legend`, the distribution, and confidence. It may fall between levels and is not generally normalized to 0–1.

Put relevant records and facts in `state`, the judgment in `instructions`, and the possible answers in `criteria`. Use named JSON fields for context with several parts. Each question should ask one coherent judgment; include its full meaning because the question ID is not shown to the model. Keep exact calculations, known rules, and the composition of answers in demo code.

Instructions and criterion descriptions support structured objects and arrays as well as text. Choice descriptions and Noul definitions may be null; Score levels cannot be null. The live upstream schema permits omitted/null instructions and a one-level Score, while the prose guide recommends instructions and at least two levels. Supply meaningful instructions and two or more self-contained levels for useful demo scores; use the served schema for accepted shapes.

Combine independent questions about the same state into one evaluation when practical. They run independently and cannot see each other's answers. Use another request when an answer is needed to build the next state or choices. Combining questions avoids resending state but still uses question tokens; it is distinct from batching payment settlement.

For current Jev 1.13 models, TypeSafe documents a 64k-token limit for state plus all questions and a 32k-token limit for state plus the longest question. The service also limits request bodies to 1 MiB. Consult current model documentation rather than treating a character count or the service's price estimate as a token-limit validator. Convert non-text inputs to text before evaluating them; do not invent a bulk endpoint.

This guidance follows the [official TypeSafe skill](https://github.com/typesafe-ai/skills/blob/main/skills/typesafe-ai/SKILL.md). Before designing a new demo, consult the relevant [state](https://docs.typesafe.ai/concepts/state), [primitive](https://docs.typesafe.ai/primitives), or [structured-question](https://docs.typesafe.ai/primitives/advanced) guidance and a relevant cookbook from the [documentation index](https://docs.typesafe.ai/llms.txt). The service's OpenAPI remains the contract for its URLs, accepted fields, payment flow, and errors; upstream Bearer-key examples are for TypeSafe's direct API. The demo restrictions and payment requirements above apply specifically to this service.

Treat outputs as experimental model estimates. Report the returned model, answers, distributions, and confidence where available; never present confidence as proof of correctness or permission to act. Use toy outcomes only, such as labeling synthetic messages without routing real tickets.

## Metered pricing

The service prices the parsed request using a token estimate based on its canonical serialized body and question count, subject to each payment option's floor and published bounds. Response token usage is not the quote to pay against. Do not calculate a final price from raw client bytes or assume a fixed per-call price.

The operation's `x-payment-info.price` describes its USD range. `x-x402-payment-info.accepts` and `x-mpp-payment-info.offers` describe potential alternatives; their amounts are discovery metadata and may be configured floors. The live `402` challenge for the actual request supplies the authoritative amount and signing fields.

Prepare the complete body before requesting a challenge. Keep the method, URL, and body unchanged for the paid retry. If the body changes, obtain a new challenge. Compare exact decimal or integer amounts; never use floating-point arithmetic for atomic token amounts.

## Select a payment rail

Follow the user's rail constraints and the live challenge. Prefer `batch-settlement` over `exact` when both are offered on an allowed network and the signer supports it, especially for repeated demo calls. Batch settlement amortizes on-chain settlement across requests and can offer a lower price; verify the actual offers instead of assuming a discount or a smaller markup.

- If the user already has a suitable wallet on an offered rail, prefer it with batch settlement where supported. Do not bridge funds just to pay for a small demonstration without explicit authorization.
- If choosing a rail from scratch, prefer Base (`eip155:8453`) with `batch-settlement` when offered and supported. Use a dedicated wallet with a small, approved demo budget.
- Fall back to an offered per-request rail if batch settlement is unavailable, unsupported by the signer, or outside the approved deposit budget. Explain the cost before requesting any expanded authorization.
- Prefer an MPP session for repeated calls only if the live challenge actually offers `intent: session` and the signer supports it. A Tempo `charge` offer is a one-time payment, not a session.

The checked-in demo configuration includes these alternatives; the live challenge determines availability:

| Rail | Scheme or intent | Client requirement |
| --- | --- | --- |
| x402 Base | `batch-settlement` | Batch-capable client with channel and voucher support; preferred when permitted. |
| x402 Base | `exact` | Client supporting the exact offer's authorization. |
| x402 Etherlink (`eip155:42793`) | `exact` | Compatible Permit2 witness signing for this service. |
| x402 Solana | `exact` | Solana-capable client for the offered network. |
| MPP Tempo | `charge` | MPP client supporting the offered Tempo currency and chain. |

Channel funding or a session deposit can exceed one request's price and lock funds. Obtain authorization for that deposit separately from per-request charges, respect the total budget, reuse an existing compatible channel, and follow the client's close/refund process when done. Do not promise an immediate refund or assume a withdrawal delay from memory; read the current terms.

## Complete a payment

1. After demo confirmation, send the intended evaluation without payment credentials to obtain `402`. Read `PAYMENT-REQUIRED` for x402 and `WWW-Authenticate` for MPP; do not rely only on the JSON body.
2. Select one offered alternative. Verify the scheme or intent, network, asset/currency, recipient, amount, expiry, and all scheme-specific fields against the user's authorization. If none is allowed or the amount exceeds the budget, stop before signing.
3. Use an existing trusted wallet or a compatible protocol client. If no signer is available, help configure a dedicated demo signer whose key stays in the user's local secret storage; never request a private key in chat, hardcode it, or log it. Do not adapt an `exact` signature to batch settlement or MPP by changing labels.
4. For x402 v2, retry with the client's credential in `PAYMENT-SIGNATURE`. For MPP, retry with `Authorization: Payment ...` from the MPP client. Send only the selected protocol's credentials; this service selects MPP first when both are present. Preserve the original request body.
5. Inspect the HTTP result and the protocol's receipt before reporting success. Keep charges and deposits within the approved total, including retries; never claim settlement from a signature alone.

For Etherlink, use a client that explicitly supports this service's Permit2 witness. The [Baking Bad Etherlink payment skill](https://dev.agents.bakingbad.dev/skills/x402-etherlink/x402-etherlink.tar.gz) provides compatible clients; verify it against its [published SHA-256 digest](https://dev.agents.bakingbad.dev/skills/x402-etherlink/x402-etherlink.tar.gz.sha256) before use. Review any required token approval and gas cost with the user. If a compatible client is unavailable, choose another approved offer or stop; do not sign with a generic Permit2 implementation on an assumption.

## Handle failures

- On `400` or `422`, correct the request or reduce its size before requesting another quote. Do not repeatedly pay for the same invalid input.
- On `402`, inspect the fresh challenge and rejection reason. Do not blindly replay a credential or switch rails after a possible payment. Verify the payment state first; retry only within the authorized budget.
- On `429`, back off with a bounded retry policy. On timeouts or `5xx`, payment status may be uncertain: inspect receipts or client state before authorizing another payment. Do not promise that every failed request is uncharged or automatically refunded.
- TypeSafe's direct API documents `401` for API-key failures and `529` for overload. This service manages the upstream API key and maps undeclared upstream statuses, including those two, to an opaque `503`. Do not ask the user for a TypeSafe API key to resolve it. Honor `Retry-After` when present, keep retries bounded, and report a persistent failure.
- If discovery or model selection disagrees with the contract, refresh `/openapi.json` and `/v1/models` before retrying. Stop if the mismatch persists.

Integration contact: [Baking Bad](https://bakingbad.dev), hello@bakingbad.dev.