What we shipped, in plain language

An agent can exchange its agent key for a short-lived access token. That token now carries the same limits as the key it came from.

With either credential, an agent can read its own capabilities and nothing about any other agent. Listing or fetching agents, reading or sending from an agent's inbox, managing agents and their keys, and approving or rejecting pending work are for people only. An agent's token gets 403 on those, and on another agent's capabilities it gets 401, the same answer its key gets.

A workspace owner or admin signed in to the dashboard, and a person's own token, keep full access to every agent in the workspace. Nothing changes for an agent that only works with its own agent.

For help, write to support@last-price.ai.

Batch pricing now follows the same prepaid balance rules as a single price computation. While a workspace has balance billing on, each item of a batch is one compute call drawn from the balance at the prepaid price, the same price and the same saving over paying per call as a single call.

A batch is drawn all or nothing. If the balance cannot cover every item, the whole batch is refused with 402 insufficient_balance, nothing is charged and nothing is computed. The refusal says what the batch needed and what one item costs, and its next steps offer a top-up or turning balance billing off, so an agent can send a smaller batch or top up and try again.

Only priced items stay paid for. An item that comes back as an error is given back to the balance, and every item is given back if the batch fails. A batch the balance paid for reports what is left in remaining.balance, and carries the top-up request while the balance is below your reminder threshold, as a single call does.

Batch pricing is still not part of the Agent Starter plan for self-registered agents; it becomes available once a person claims the workspace. With balance billing off, the default, nothing changes.

For help, write to support@last-price.ai.

Each endpoint under Webhooks now has an Edit events button. Tick the events you want and save; the endpoint keeps its address and signing secret.

• Product updates. Tick platform.changelog to receive each new changelog entry written for agents, with a link to it. It only goes to endpoints that pick it by name, so an endpoint set up before it existed can now opt in.
• Endpoints that take every event. Editing one starts with everything it receives today already ticked. Saving switches it to exactly the events you tick.

Questions: support@last-price.ai.

Agents and people can now ask Last Price to evaluate a competitor offer against a stated match or undercut goal and a minimum acceptable price. Unit cost and target margin can supply that minimum. The answer explains when business limits change the suggested price.

If the goal or price basis is missing, the API identifies the inputs it needs before it can make a suggestion. The Commerce dashboard includes a tryout for this request. Suggestions do not change store prices.

When you unsubscribe using the link in one of our marketing emails, or report one as spam, the Marketing emails switch in profile settings now turns off to match, so the two always agree. Nothing we receive can turn it back on: only you can, from that switch.

Every change to your marketing email choice is now kept in a permanent history, shown under the switch in profile settings, Notifications: when you signed up, each time you turned it on or off, and any change made from an email or by our support team. Marketing emails stay off unless you turn them on, and account, security, and billing emails always arrive.

For help, write to support@last-price.ai.

Each tools/call on https://api.last-price.ai/api/mcp/rpc has 30 seconds. Before, a call that ran longer could end with the connection closing and no reply, and over a stream the stream simply stopped, so your agent could not tell what happened.

Now a call still running at 30 seconds is stopped and answered at once with a JSON-RPC error:

• error.code is -32001, the request timeout code of the MCP reference SDK, and id is your request's own id.
• error.data holds code: "upstream_timeout", retryable: true, timeout_ms: 30000, the tool name, a hint, and an empty next.
• Over a stream, the error is the response event and the stream then closes normally.

What to do: send the same call again once. If it times out again, wait a minute before retrying. Work already under way when a call is stopped may still finish, so a timed-out compute_price can still be counted. Calls that finish in time see no change, and every other tool failure is still a result with isError: true. The locally run MCP server applies the same rule, with the limit configurable through LASTPRICE_TIMEOUT_MS. Questions: support@last-price.ai.

Every other week, the release notes and blog posts that shipped since the last issue are collected into a newsletter issue with two editions.

• The edition for people gives each change in a sentence or two, with a link to its release note.
• The edition for agent builders carries the full release notes written for agents, and points to the changelog JSON feed and llms.txt so an agent can follow changes on its own.
• Every issue is on the newsletter page, with an RSS feed.

Email delivery is not switched on yet. When it is, issues go only to people who turn on Marketing emails in their profile settings, and every issue carries a link to stop them.

For help, write to support@last-price.ai.

A compute call can be paid for when it is made: per call with an x402 payment, from a day pass the workspace bought, or from the workspace's prepaid balance. Those calls used to be added to the workspace's usage cost as well, so a workspace later billed from its usage would have paid for them twice. They no longer are.

A paid call still counts as a request everywhere, in the usage totals, the event list and every limit, and its cost is still shown. It is left out of the billable cost only. The usage summary now reports prepaid_requests and prepaid_cost for the calls already paid for and billable_cost for the rest, and current_period_cost is this month's billable cost, which is zero when every call this month was already paid for. Each usage event carries paid_via (x402, day_pass or balance) when it was paid for, and is null otherwise. A call covered by a free daily allowance was not paid for and is billable as before.

In the dashboard, the usage page's Total Cost card shows the billable cost for the month and, when some calls were already paid for, how much of the total that was and that it is not billed again. Each paid call in the event list is labelled Paid per call, Day pass or Prepaid balance.

For help, write to support@last-price.ai.

A self-registered agent workspace has a daily limit on price computations. Where pay per call is offered, the agent can now buy a day pass with its own key and one x402 payment in USDC. A pass adds a set number of compute calls, 500 by default, for 24 hours from purchase.

The pass is only used once the daily limit is reached, one call per request, and a call is never counted twice. A call that fails is not charged to the pass. With more than one pass, the one that ends first is used first. A call sent with a payment is paid per call, even while a pass is live, and does not use the pass. A pass cannot be bought when the agent's key expires within its 24 hours, and unused pass calls end when a person claims the workspace, since the claim lifts the daily limit. If a pass payment goes through but the pass is not recorded straight away, it is added automatically shortly after. The agent can list its passes and the calls left on each. The refusal it gets at the daily limit now lists a day_pass step in its next steps, between paying per call and being claimed, with the pass size, how long it lasts, its price and where to buy it. A priced response to a call a pass covered reports the calls left on that pass, and does not suggest paying per call while that pass still has calls.

The discovery documents, the plain-text agent guide, the registration response and the guide for testing with your own agents describe the pass, its size and its price. In the dashboard, the usage page shows a Day passes card with each pass and the calls left, for any workspace that has bought one, including after it is claimed.

For help, write to support@last-price.ai.

Team administration used to need a person signed in to the dashboard. An owner or admin can now create an API key with the new Manage the team permission and hand it to an agent they run. With it, the agent can list the team, add and remove members, change roles, and send, list and revoke invitations in that workspace, acting for the person who created the key.

The key is held to limits a signed-in admin is not:

• It works only in its own workspace, and only while the person who created it is still an owner or admin there.
• It can never make anyone an owner or give a role above its creator's own.
• It never changes or removes the workspace owner or its own creator.
• Only a key an owner created can demote or remove an admin.
• The permission is granted by name only. A key with every permission, or with none set, does not carry it, and a token made from a key is refused.

An invitation a key sent can only be accepted while that key is still valid and its creator can still invite at that role; revoking the key cancels its pending invitations.

Only owners and admins are offered the permission, with a warning when they choose it. Every change a key makes, and every attempt it was refused, is recorded with the key and the person behind it. The Team page lists them so you can see what an agent did, and only owners and admins can read them.

A self-registered agent workspace has a daily limit on price computations. Until now the only way past it was for a person to claim the workspace.

Where pay per call is offered, the agent can now send the same request again with its own key and a signed x402 payment in USDC at the per-call price. The call runs straight away in the agent's own workspace and does not count against the daily limit. Every other rule of the workspace still applies, including built-in pricing functions only. Paying works on the compute and price router calls; verifying a price still counts against the limit. If a paid call fails, for instance because the function it names does not exist, the agent gets the same answer as an unpaid call and is not charged, and the same payment can be sent again.

When the limit is reached, the refusal now says what to do next: pay for the call, with the price and where to send the payment, or have a person claim the workspace. The discovery documents, the plain-text agent guide, the registration response and the guide for testing with your own agents say the same.

In the dashboard, paid calls show as "Paid per call" in the usage list, and the live traffic view counts them as the agent's own requests. The paying wallet address is recorded on each paid call. Paying never links that wallet to the workspace, so signing in with the wallet later gives no access to it.

For help, write to support@last-price.ai.

The API reference can display its interactive endpoint list again. Its scripts and styles are included in the deployment and resolved from their installed location, so the page no longer depends on the server's working directory.

An agent that integrated once had no way to hear that something it relies on changed. Every surface an agent reads first now points at the changelog.

• `/.well-known/agents.json` and `/.well-known/mcp.json` carry a changelog object: the JSON Feed and RSS addresses, the changelog page, the filter for agent entries (items[]._lastprice.audience includes agents), when to check, and the date of the newest agent entry, so a client can tell whether there is anything new without fetching the feed.
• `/llms.txt` has a short Changes section with the same addresses.
• `POST /api/agents/register` returns a changelog field with the feed address.
• The welcome and approval emails link the changelog page.

An agent that integrated once had to go looking to learn that something it relies on had changed. Now the answer comes to it, in a response it already reads.

• `notices` in the response. POST /api/compute/price, POST /api/compute/batch, POST /api/price-router, GET /api/me and GET /api/functions add notices when there are changelog entries written for agents from the last 30 days that the key has not been shown yet: id, date, title, summary and a link, newest first, at most three. Each entry is shown to a key once, even one that is published after newer entries or dated earlier than one the key has already seen. A key that has never been shown one gets only the newest entry, and only if it is less than two weeks old.
• `X-LastPrice-Notices` header. The same responses say how many notices they carry, so a client can check the header without reading the body.
• Only API keys. Tokens and dashboard sessions get no notices.
• Last used on the API keys page. Settings, API keys now shows the date and time each key was last used, and on a phone it appears under the key name.

A successful price computation, whether from the compute call, the price router or a batch, and whether made with a key or paid per call, now carries up to four extra fields. Nothing that was already in the response changed.

• savings: what this call cost next to the most expensive pricing function that was eligible for the same request under the same routing rules. It appears only when the router actually chose between functions, so a pinned function, a fallback or a cached answer carries none.
• next_actions: at most three requests your key is allowed to make next, each with a reason and an example body. Record whether the price was accepted, create a routing policy if the workspace has none, register your own pricing function if it has none (the example's name and address are placeholders to replace, since function names are unique across the network), and for a self-registered agent, have a person claim the workspace or pay per call once the day's calls are spent.
• remaining: the daily compute calls left on a self-registered agent workspace, and the request rate limit left, each with when it resets.
• receipt: the usage record of the call, with a link that opens it on the Usage page, where you can mark the price accepted or rejected.

A price router call whose body is not JSON now answers 400 with code: invalid_json, a hint and an example body, the same as price computation; the agent manifest lists it with the others. For a self-registered agent, the claim and pay per call suggestions carry, as detail, the same step the daily limit's 429 lists in next.

The price router test console in the dashboard shows the savings and next steps under each result.

For help, write to support@last-price.ai.

The Legal page has a new Copyright complaints section. If you believe a profile picture, a workspace logo, or a Marketplace listing on Last Price infringes your copyright, it says where to send a notice and lists, in plain words, what the notice must include.

We remove or disable access to content identified in a valid notice, tell the account that posted it, and close the accounts of repeat infringers. If your content was removed and you believe that was a mistake, you can reply with a counter-notice.

The Terms of Use have a matching Copyright complaints section. The later sections are renumbered; their wording is unchanged.

Send notices and questions to support@last-price.ai.

Two ways to learn about a change without having to go looking for it.

• Deprecation headers. When an operation is being retired, every response it sends carries Deprecation (when it was deprecated), Sunset (when it stops working, once a date is set) and Link: <url>; rel="deprecation" pointing at the changelog entry that says what to use instead. Errors carry them too, so a client with a bad key still hears about it. No operation is deprecated today.
• `platform.changelog` webhook event. Subscribe an endpoint to it under Webhooks and it receives a signed event when a changelog entry written for agents is published, with the new entries, links to each, and the feed address. It goes only to endpoints that pick this event by name, never to one that takes every event. Each entry is sent to each endpoint once; it is not retried if the endpoint answers an error or times out, so read the changelog feed to catch up after your endpoint was down. In rare cases an entry can arrive twice, possibly under a different event id, so deduplicate on each entry's id in data.entries, not on the event id. Deliveries show in the endpoint's delivery log like any other.

The guide now shows the access options advertised by the current deployment, including sandbox registration, OAuth registration, and pay per call when available. Limits and availability update with the discovery document.

New sections explain how to rotate an API key and read a compute request trace. A link to the API reference provides complete request and response schemas. If access options cannot be loaded, the guide says so and keeps the reference link available.

The most common API errors now tell the caller how to recover, in optional fields at the top level of the body. Nothing was renamed or removed: error, code, status codes and headers are exactly what they were.

• A 401 names the credentials the API accepts in hint, and next lists where to get one: self-registration (while it is open) and the OAuth token endpoint.
• Agent management, agent keys and inbox, and approval decisions take a person's credential only. Sent a valid API key, they now answer 401 with their own message (it used to read only "Authentication required"), a hint that the route needs a dashboard session or a JWT, and an empty next, instead of pointing you at a new key. Approval decisions say so before checking scopes, so a key is never told to fetch a scope that still would not let it in.
• A 403 for a new key wider than the calling token says to ask only for scopes that token holds.
• A 400 for a body that fails validation lists each failing field in issues, with its path and the reason, plus a hint. Price computation, batch computation, price verification, function registration and agent self-registration also return example, a minimal body that passes.
• A body that is not JSON answers code: invalid_json with a hint on price computation, batch computation, price verification, function registration, API key and embed token creation, costs, credits, customers, disputes, invoices, orders, payments, pricing models, routing policies, webhooks, usage outcomes, data contributions and marketplace listings. Batch computation, price verification, function registration, costs, credits, customers, disputes, invoices, data contributions and new marketplace listings used to answer 500 here. The agent manifest lists the exact operations; other routes are unchanged.
• A 429 from the general rate limits carries retry_after (always equal to the Retry-After header) and limit. A daily quota says it is one: it resets after retry_after seconds, and the response names the ways past it sooner. A self-registered agent's daily limit carries the same hint, retry_after and limit, and its next is a list of steps like every other next: a pay_per_call step where the call can be paid for, and a claim step.
• A 403 insufficient_scope keeps required_scopes and adds a hint on how to get a key that carries the scope.

The agent manifest, llms.txt and the OpenAPI contract list the new fields. For help, write to support@last-price.ai.

Profile settings, Notifications, now has a Marketing emails switch. Marketing emails are off unless you turn them on: new accounts start with them off, and existing accounts keep them off unless you had turned the old option on. Turn the switch off and you are taken off our marketing list straight away, and you stay off it when your account status changes later. Account, security, and billing emails are not marketing and always arrive.

The switch replaces the old "Marketing & product updates" option, which saved a preference that nothing acted on.

Our account and sign-in emails can now show the legal name and postal address of the sender in their footer. The line appears once those details are published; until then nothing is shown in its place.

For help, write to support@last-price.ai.

The MCP endpoint at https://api.last-price.ai/api/mcp/rpc now implements the Model Context Protocol Streamable HTTP transport (revision 2025-11-25). Any MCP client that speaks it can connect with just the URL and, optionally, your key in x-api-key or Authorization: Bearer. Clients that POST plain JSON-RPC, as before, see no change.

• Sessions. initialize returns an Mcp-Session-Id header. Sending it back is optional. The id is a signed token that every server works with, so you can send it on every call. It stays valid for 24 hours and belongs to whoever opened it: a refreshed token or a rotated key for the same workspace and agent keeps it. You get 404 only for an altered id, an expired one, or one opened by someone else; then send initialize again. Without the header every request is served statelessly.
• A notification stream. GET with Accept: text/event-stream returns the newest release notes written for agents (notifications/lastprice/changelog, up to three entries with date, title, summary and link) and closes at once, with a hint to come back in five minutes.
• Streamed replies when you ask. A POST answers over the stream format only when Accept lists text/event-stream without JSON, or when a tool call carries a progress token; then a progress notification comes first. Otherwise the reply is JSON, as before.
• Instructions. initialize now returns short instructions: what the server does, and a pointer to this changelog.
• Sessions end on their own. DELETE answers 405: there is nothing stored to end, so simply stop sending the id.

The discovery document at /.well-known/mcp.json advertises transport: "streamable-http", lists the older http+jsonrpc value alongside it, and describes the session rules, including sessions: "stateless". A request from a web page on another origin is refused with 403, and an unsupported MCP-Protocol-Version header with 400. Questions: support@last-price.ai.

A workspace can now hold a prepaid balance in USDC. Top it up with one x402 payment for the exact amount you name, at least 10 USDC by default. Top-ups of 100 USDC or more earn a 10% bonus, and 500 USDC or more earn 20%. A payment is credited once and cannot be used again.

A prepaid compute call costs less than paying per call: the per-call price is 20% more than the prepaid price by default, and the balance page shows both prices and the saving. A self-registered agent workspace uses its balance once its daily limit and any day pass are used up, and the refusal it gets at the limit now says how to top up. Any other workspace pays for compute from its balance only when it turns balance billing on. A call that fails is given back to the balance, and a call paid from it says in its response what is left and how many more calls that covers.

Auto top-up is a reminder, not a charge. Set a threshold and an amount, and while the balance is below the threshold your compute responses include the exact top-up request, and one balance.low webhook is sent each time the balance falls below it. Nothing is ever charged automatically, and nothing recurs.

Prepaid balance does not expire while your account is active, and unused paid balance is refunded on request when the account is closed. Bonus credit is spent last and is not refundable. Monthly commitments are shown on the billing settings page and arranged with a person.

In the dashboard, Settings, Billing shows the balance, the bonus part of it, recent activity, how to top up, the reminder settings and the commitment options. The discovery documents and the plain-text agent guide describe top-ups and the prepaid price.

For help, write to support@last-price.ai.

The Terms of Use have a new Eligibility section. You must be at least 18 years old and able to form a binding contract to use Last Price. When an AI agent uses Last Price, the person or organisation that operates it must meet this requirement and is responsible for what the agent does. The platform is built for businesses and developers and is not directed at children. The later sections are renumbered; their wording is unchanged.

The sign-up and sign-in pages now show one short line below every way to create an account: by continuing, you agree to the Terms of Use and Privacy Policy, with a link to each. No date of birth is asked for or stored.

If you believe we hold personal data from someone under 13, write to support@last-price.ai and we will delete it.

You can now restrict an API key to billing: billing:read reads invoices, payments, credits and your marketplace earnings and payouts, and billing:write changes them. The commerce control plane gains commerce:configure for setting up connectors, pricing policies and data, beside the commerce scopes that already existed. Those routes now check the scope, where before any key of the workspace was accepted. A key or agent with explicit scopes now needs the matching billing:* or commerce:* scope for those routes, and without it gets a clear 403 naming the missing scope. Your dashboard session and keys created without scopes keep full access.

The key creation dialog now offers the real scope list, and creating a key with a name that is not a scope is refused with the list of valid ones. The read, write and admin choices the dialog used to offer were not scopes any route recognised; keys that already carry one are marked as legacy, and some of them lose access:

• A legacy read key is now read-only for billing and commerce. It can no longer create or change invoices, payments or credits, and it can no longer configure commerce, run a pipeline cycle or execute prices.
• No legacy key can approve or reject commerce proposals any more.
• Legacy write and admin keys keep the rest of their billing and commerce access, and no legacy key gains anything it was refused before.

To do any of those things, create a key with the specific scope, such as billing:write, commerce:proposal:approve or commerce:execute.

Every commerce operation, from connectors to executing approved prices, is now in the API reference, with the scope each one needs. The agent manifest lists where the billing records live and what credits mean here, and /payouts opens your marketplace payouts.

The public Elo Index leaderboard ranks pricing functions on adoption, confidence, speed and cost efficiency. Confidence previously had nothing behind it for any listing: the value a pricing request reports was never kept past the response that carried it, so the confidence component stayed unmeasured for every function on the board.

Confidence is now averaged over the same real consumer requests the adoption count is drawn from: a provider's own calls, demo traffic, pay-per-call traffic and sandbox workspaces still do not count. A function's average confidence is withheld until enough distinct customers have supplied a confidence, a separate floor from the usage counts' own (a function can have enough customers for its counts to publish while only one of them reports a confidence), and shows as unmeasured until then. Once published it is rounded to the nearest 0.05, which hides the exact confidence behind any one request; while few requests carry one, comparing readings can still narrow it to a coarse range.

• Functions with enough real usage can now reach data_status: "measured" on the leaderboard for the first time; a function with published usage but too few customers behind its confidence still reads partial, and one with neither reads unmeasured.

Follow-ups to agent self-registration and pay-per-call.

• Rotate a sandbox key yourself. POST /api/api-keys/rotate with the key in x-api-key now works for a self-registered sandbox key. The new key keeps the same workspace, scopes and expiry, so rotating never widens access or extends the key's life, and the old key stops working at once. A sandbox can rotate a limited number of times a day (sandbox.limits.key_rotations_per_day).
• Limits you can rely on. The sandbox and registration limits are now deployment settings. /.well-known/agents.json (self_registration.limits), /llms.txt and the registration response always state the values actually enforced, so read them there rather than assuming the defaults.
• Registration can be paused. If self-registration is temporarily closed, POST /api/agents/register answers 503 with code: self_registration_closed and Retry-After, and discovery stops listing it. Sandboxes already registered keep working. Sign up, or pay per call, instead.
• Claimed workspaces are ordinary workspaces. When a person claims your sandbox it becomes a normal workspace on the free plan, with their email, a slug and its own test workspace, and keeps a permanent note that an agent started it: GET /api/me reports origin, created_by_agent and claimed_at, and the dashboard shows a "Started by an agent" badge.
• Retry a refused payment. If a pay-per-call settlement is refused (for example, insufficient funds), the 402 carries code: payment_settlement_failed with retryable: true and settle_attempts_remaining. Nothing was charged, and you can present the same signed payment again, up to three settlement attempts by default. A settlement whose outcome is unknown is still never retried.

Opening the dashboard address now takes you to the app, and to sign in when you are signed out, instead of showing the marketing homepage again. The main navigation no longer lists the price check preview, which is not live yet, and the marketplace says that listing your own function needs you to sign in.

For agents: the commerce protocol endpoint advertised in discovery now answers with the same discovery document instead of a not found error. The agent manifest explains that AgentID is an interactive sign-in authorized with your own inbox key, not open client registration. The keyless demo calls now return the demo budget headers on a validation error too, since a rejected call still counts against the hourly budget, and the price check demo also reports when that budget resets. The published API description lists only the production server.

A workspace an agent registers for itself now starts on the Agent Starter plan. The registration response names the plan next to the limits it carries.

The plan allows 25 compute calls a day per workspace, and the key expires after 30 days unless a person claims the workspace first. Registration is limited to 5 a day per address and 200 a day in total. Every limit is still reported in the registration response and in the discovery documents, so an agent always sees the values actually enforced.

Claiming works as before: the workspace moves to the free plan, the limits lift, and it stays marked as started by an agent.

When you claim a workspace one of your agents registered for itself, the claim page now asks which of your workspaces should hold it. The agent's workspace moves under that one with all of its data. Nothing is deleted or merged. It moves to the free plan, gets its own test workspace, and stays marked as a former agent sandbox.

You can claim into any workspace you own or administer, including one you claimed from an agent earlier. One workspace can hold up to 50 claimed agents by default.

An agent you run can also claim for you. A workspace owner or admin can create an API key with the new Claim agent workspaces permission and give it to that agent: it can then claim the workspaces its helpers register, straight into that workspace, for as long as the person who created the key remains an owner or admin there.

A new guide, Testing with your own agents, in the docs walks through the whole flow.

When a person claims a sandbox workspace that an agent registered for itself, the key the agent holds is now revoked as part of the claim unless the person ticks the box to keep it. Previously the key was kept unless they cleared that box.

The claim page and the API contract now describe a kept key honestly: once the workspace is claimed, the sandbox limits no longer apply, so a kept key works with the full access of an API key in that workspace, including anything added to it later, until someone revokes it under Settings, API keys.

Agents are told the same thing when they register: the claim revokes their key unless the person chooses to keep it.

The public leaderboard scores adoption from the number of distinct consumers of each pricing function. A consumer is now a person rather than a workspace: several workspaces with the same owner count as one consumer, and a workspace with no owner counts as itself.

Calls from any workspace owned by the same person as the function's own workspace no longer count at all, just like the provider's own calls. One person holding several workspaces therefore cannot lift a function over the minimum number of consumers needed before its usage is published.

The public Elo Index leaderboard ranks pricing functions on adoption, confidence, speed and cost efficiency. Adoption previously had nothing behind it: every listing reported the same unmeasured value, and the leaderboard scored every function's adoption identically regardless of how often it was actually used.

Adoption now counts the distinct consumer workspaces that call each function. A provider's calls to its own function, demo traffic, pay-per-call traffic and sandbox workspaces do not count, so the number reflects real consumers rather than volume anyone can generate. A function nobody has adopted scores 0.

To protect individual customers, a function's usage numbers are published only once at least three distinct consumers use it. Below that, total_invocations and the new distinct_consumers are null and stats.usage_status reads below_threshold. Confidence still has nothing behind it and stays unmeasured for now, so data_status on each entry reads partial rather than measured. The scoring method is now version 3.

Where wallet sign-in is switched on, the sign-in and sign-up pages offer "Sign in with wallet". The wallet signs a short message that names Last Price; nothing is sent on chain and it costs nothing. Ordinary wallets and smart wallets on Base both work.

A wallet that has not been used before creates a new account, which joins the waitlist like any other new sign-up. Sign in with the same wallet later to check whether access is ready.

Account settings now have a Wallets section. Link a wallet to an account you already have, so either sign-in method works, or unlink one you no longer use. A wallet that created its account stays linked to it as the account's sign-in identity. The same section lists the pay-per-call payments made from your linked wallets, with their status and a link to each settled transaction. The list is read only.

For help, write to support@last-price.ai.

Price verification, both the public demo and the authenticated call, now accepts price as an alias for proposed_price when proposed_price is not sent. When neither is present, the error names proposed_price and mentions the alias, instead of a bare "Required".

The API description can now be fetched as JSON: add format=json, send Accept: application/json, or request /api/openapi.json. YAML stays the default.

The API description opens with what Last Price is: compute a price for a context, verify a proposed price, and browse the pricing functions. The multi-modal pipeline run operation now says up front that it always answers 501 and points to the public compute demo instead.

An agent that read our discovery documents was only ever told about the keyed pricing call, so its first request failed without an account. The free demo calls, POST /api/public/compute/demo and POST /api/public/price-router/verify, now come first in llms.txt, in the public_demo section of agents.json, and in the docs "First call" guide.

• agents.json is also served at the site root, and llms.txt at /.well-known/llms.txt.
• The homepage playground example now shows what the demo actually returns for a $49 plan ($24.99), not the input echoed back.
• The UCP discovery profile no longer links to pages that do not exist. It points at the API reference and the OpenAPI contract.

An agent no longer needs a person, an inbox, or a sign-in to start using Last Price. One unauthenticated request with the agent's name creates a sandbox workspace and returns an API key, shown once.

The sandbox key can compute prices with built-in functions and read functions and routing policies, up to 25 compute calls a day, and expires after 30 days. Every other operation is refused with a clear reason. The same key also works as OAuth client credentials for a short-lived access token.

The response includes a one-time claim link. When a person opens it, signs in and confirms, the workspace joins their account and the sandbox limits lift. They can choose to keep or revoke the key the agent holds.

The discovery documents, the plain-text agent guide and the API contract all describe the new call, its limits and what the key can and cannot do.

An agent's token, exchanged from the agent's own scoped key at /api/oauth/token, was accepted by POST /api/api-keys, so an agent could create an unrestricted key for its workspace. GET, POST /api/api-keys and DELETE /api/api-keys/{keyId} now answer 403 agent_cannot_manage_keys to an agent's token. A person's JWT that is limited to scopes can only create keys within those scopes (403 insufficient_scope otherwise). Dashboard sessions and full-access tokens are unchanged.

An agent can still replace its own key: POST /api/api-keys/rotate with the key in x-api-key returns a new key with exactly the same scopes, agent and expiry, and revokes the old one at once. It cannot widen anything.

The same rule now covers agent management: an agent's token cannot create, edit or revoke agents, or mint agent-bound keys with POST /api/agents/{id}/keys (403 insufficient_scope).

A 401 used to look different depending on which endpoint answered it: some sent a plain error string, others a nested error object. Every 401 now also carries three top-level fields, whatever the endpoint:

• code: invalid_credentials when the credential you sent was rejected (an expired token, an unknown API key, a bad signature), or unauthorized when none was sent or it is not the kind that endpoint accepts.
• message: the same text as before.
• retryable: always false. Retrying without a different credential gets the same answer.

The existing error field is unchanged, so integrations that read it keep working. 401 responses also carry a WWW-Authenticate: Bearer realm="last-price" challenge. The discovery document and the API reference describe the shape.

The public marketplace and the Elo Index leaderboard were empty until a provider listed a function. They now show eight of Last Price's own built-in pricing functions, including the Jale optimizers, cost-plus pricing and the A/B test assigner. Each one is labelled as built-in by Last Price, so you can tell it apart from a third-party provider's listing.

The leaderboard ranks them by the same method as any other listing, from real catalog data only. A function with no recorded latency is no longer scored as the fastest on the board: its speed shows as no data until it has been timed.

Live traffic now shows who sent each pricing request, so you can tell your own agents apart from anyone else calling the network.

• Who sent it: each request is named by the agent its key is bound to, or by the User-Agent your software sent with it, such as your-system/support-role. The channel (API, MCP or public demo) is shown too.
• Mine, Testers, Others: a request sent with your workspace's own API key, agent key or token is yours, whether or not the key is bound to an agent. Testing agents that try the public demo or MCP without a key, the way a stranger would, can be labelled as your testers with a private tester tag from Settings. The tag grants no access and changes nothing they get back. Everyone else is Others, and the User-Agent they send is marked unverified.
• Filter and group: switch between All, Mine, Testers and Others, and see request counts per caller. Pick a caller to see only its requests.
• Several agents can share one workspace key and still be told apart: have each send a descriptive User-Agent. Agent-bound keys remain available when you want per-agent scopes and revocation.
• The usage events API returns the same details and filters.

The Browse tab in the dashboard marketplace used to show a sample catalogue with invented providers, ratings and request counts. It now lists the pricing functions actually published on the network, including Last Price's own built-in functions, which are labelled "Built-in by Last Price".

Each card shows the function's name, description, tags, cost per unit, cost multiplier and average latency. There are no ratings or reviews. Where a figure has not been measured yet, such as the latency of a function that has never been timed, the card says "no data" rather than showing a zero. You can search the catalogue and filter it by the tags the listed functions carry.

/.well-known/mcp.json pointed agents at /api/mcp/rpc, but that address returned a 404 page. It now speaks JSON-RPC 2.0 over HTTP with the same tools as the @lastprice/mcp stdio server: compute_price, verify_price, list_functions and browse_catalog.

Send your key as x-api-key or Authorization: Bearer. Without one you can still initialize, list tools, and price or verify against the public demo, which is rate limited per caller and marks its answers with _lastprice_notice.

A client built on an OAuth client credentials framework can now set itself up without anyone's help. This is an additional way in, not a replacement: registering with one call for an API key works exactly as before, and so do the other ways in. The standard authorization server metadata document lists where to register, where to get a token, and exactly which grant and client authentication methods are supported.

Registering returns a client id and secret for a new sandbox workspace, with the same limits and the same claim link as agent registration. The secret works at the token endpoint and also as an API key. Requests for flows the server does not offer, such as the authorization code flow, are refused with a clear reason. There is no authorization code flow, so clients that need one should use an API key instead. The secret expires with the sandbox, and claiming the workspace lifts that limit.

While self-registration is closed on a deployment, OAuth registration is closed too, and the discovery documents stop listing it.

The MCP manifest now says plainly that credentials are optional: the tool list and the demo pricing tools work without one, and a credential unlocks the workspace tools.

Every discovery document and the agent sign-in guide now open with a short list of the independent ways in, one line each on when to choose which: the keyless demo, a free key with one call, an OAuth client, pay per call with no account where it is offered, and a signed-in account owned by an agent or a person.

The Sessions tab on your profile showed a MacBook Pro, an iPhone 15 and an iPad Air in Brooklyn whenever no real sessions were recorded, and the Security tab listed sample sign-ins. These were placeholders, not devices or sign-ins on your account. Both now show only what is recorded for you, and say so plainly when nothing is.

DELETE /api/user/sessions passed currentSessionId straight to the database, so a value that is not a UUID failed there and answered 500. It now answers 400 "Invalid session ID format" without touching any session, the same as DELETE /api/user/sessions/{sessionId}.

If your dashboard session had expired, the settings pages still opened but could not load anything, so the team page looked empty or unauthorized with no way forward. Settings now send you to sign in and return you to the page you were on. The team page also says when your team could not be loaded, instead of showing an empty list.

Opening the invite dialog on the team settings page used to block the page for a noticeable moment after the click, and every keystroke in the email field redrew the member and invitation lists. The click now responds straight away, and typing only updates the form.

These routes returned an HTML error page with status 500 for every request, signed in or not, so an agent could not tell a missing credential from an outage. They now check credentials first and answer with the usual JSON 401 (code, message, retryable).

Also in this change:

• GET /api/public/compute/demo answers 405 with Allow: POST and a JSON hint showing how to call the demo.
• /.well-known/agents.json publishes every rate limit a caller can meet: the per-workspace default, the per-IP limit every request passes first (the X-RateLimit-* you see without credentials), and the public demo cap.
• /dashboard and /overview open the dashboard, /playground opens the homepage demo, and /support opens the contact page, instead of a 404.

An agent with a funded wallet can now use the pricing endpoint without signing up. Call POST /api/compute/price with no credential to receive 402 Payment Required with the x402 payment requirements: the network, the USDC price per call and the receiving address. Repeat the same call with a signed payment in the X-PAYMENT header. The price is computed first and the payment is settled only after that, so a failed call is never charged, and the result comes back with an X-PAYMENT-RESPONSE header naming the settlement transaction. Clients on x402 v2 can use the PAYMENT-REQUIRED, PAYMENT-SIGNATURE and PAYMENT-RESPONSE headers instead.

Each payment buys exactly one call and is refused if it is presented again. Paid calls run on a shared pay-per-call workspace with the built-in and publicly listed functions. An API key still works on the same endpoint, and a request that carries one is never asked to pay. Whether pay-per-call is available, and its price, is published in /.well-known/agents.json under payments.x402 and in /llms.txt.

The authentication verification trigger helper can no longer be invoked directly by unprivileged callers. Only the specific authorized roles that require it retain execute permission.

• Unauthorized direct calls to the verification helper are now rejected at the database level.
• No change to the sign-up or email verification flow that users experience.

Operations that take no API credential now say which of two cases they are: open to anyone, or available only from a signed-in dashboard session. Before, both looked the same in the contract, so an agent could take a dashboard-only call for an open one and get a 401.

The translation API that turns your own records into canonical products, offers and observations is now in the contract, including the one-call ingest operation and the review queue.

The site now names the real permission scopes on API keys, such as price:compute, and the function catalog is described as a marketplace listing that needs a credential to read. The docs count six reference apps, plus the hub that links them.

Signup reports now distinguish accounts that have confirmed their email address from those still pending confirmation, so a new signup total is no longer mistaken for confirmed accounts.

• The staff activity page and hourly signup alert emails show total, confirmed, and pending counts.
• Alert emails use the configured reply address when one is set.
• Footer links on marketing pages have taller tap targets, so they are easier to tap on phones and tablets.

Previously, an external pricing function that responded successfully but without a usable price (for example, an error body) was reported as "no change" at a confident score, using the current price you sent in. That substitution is gone.

• A missing price or confidence is now treated as a failed attempt, so the fallback chain and circuit breaker take over.
• You no longer receive your own current price back as if it had been computed.

Each compute response now includes a trace: the stages the request passed through, in order, with the time spent in each. It shows which pricing function was chosen, whether the work failed over to a fallback, whether the answer came from the cache, and what was charged. Agents can read it to adjust their routing or budget without a second call.

The dashboard has a new Live traffic page. It draws each recent request moving through routing, execution and metering, marks fallbacks and cache hits, and lists the latest requests with their full details. It refreshes every few seconds and can be paused.

After a price is computed, you can now record what happened next, so your usage history shows which prices were actually used.

• Outcome: mark a usage event accepted or rejected.
• Quality score (optional): a number from 0 to 1.
• Record either one through PATCH /api/usage/events/{id}/outcome, or with the Accept and Reject buttons on the usage events table in the dashboard.

The staff activity page shows new accounts, pricing calls, feature calls and active workspaces over the last day. Configured email alerts report signup batches and a daily usage summary, including days with no usage. Send failures and uncertain delivery attempts are visible to staff.

Agents can follow the public signup guide or machine-readable registration information to sign in and find API credential setup. The dashboard now uses a neutral welcome message for every account.

New messages use the correct sending operation. Replies use the original message identifier and retain the original subject and thread.

A successful send returns message and thread identifiers. This confirms acceptance for sending, rather than delivery to the recipient.

Pricing recommendations stop when experiment data is incomplete or malformed, even if the data service reports success. Experiments with explicitly empty results still report that no results have been recorded.

Invalid candidate prices now return an input error before reading experiment data.

Opening the mobile app from the share sheet now preserves your item while your saved session loads. Shares are still cleared when you sign out or switch accounts.

New verified accounts can enter the workspace setup without waiting for manual approval. Existing account restrictions still apply.

Agents can use the additional identity sign-in option when it is enabled. Email and existing social sign-in remain available. Workspace membership and API permissions continue to control what each account can do.

Restricted accounts cannot change team membership, including leaving a team. Expired sessions show the signed-out account access page. Temporary sign-in service failures report a retryable error on team operations. Protected pages and staff tools also preserve retry guidance during these outages.

API response documentation now matches block creation and team membership changes.

The multi-modal pipeline endpoints executed a simulation and returned it as a successful result: a price, a confidence, and per-stage cost and latency numbers, all produced from constants, with only a simulated field to mark them. A marker in one field does not make a fabricated success honest, so both pipeline execution endpoints now return 501 with code: pipeline_execution_unavailable instead of a simulated price. The protected endpoint first checks credentials and returns 401 when they are missing or invalid; its 501 response follows successful authentication. The public endpoint needs no credentials.

Discovery is unaffected: listing the reference pipelines (and, on the authenticated route, the stage catalogue) still works, so you can see what the network will run once execution is wired. Single-price computation is unchanged and available today.

The consumer price-check page and the dashboard pipeline console now show a clear "not available yet" notice rather than a fabricated recommendation.

Company and billing settings exclude stored integration credentials, including encrypted values. Manage your model key through its dedicated settings screen.

A function you have not listed publicly is now reachable only by you. Explicit routing (a request that carries a function_id, or a routing_preference of explicit) checked three things: that the function existed, that it was active, and that its circuit breaker was closed. It never checked whose function it was. Automatic routing had always filtered to built-ins and your own functions; explicit routing did not, so naming another workspace's function id was enough to have it selected, executed, and its result returned, including the explanation and confidence that are usually the point of a pricing function.

The same rule now applies wherever a caller names a function: POST /api/compute/price, each item of POST /api/compute/batch, POST /api/price-router, and the Test button on the Functions screen. A function is reachable when it is a built-in, when your workspace owns it, or when it is listed publicly on the marketplace. Nothing else is.

This mattered most for functions that call your own endpoint. A function with an execution type of external API is invoked at the address you registered, so an unauthorised caller naming it drove requests, and cost, at infrastructure you pay for, with the calls charged to their workspace and the traffic landing on yours. Batch made that worse: up to a hundred items in a single request, each free to name a function.

Function names were the part that needed no guesswork. POST /api/price-router accepts a friendly function_name in place of an id, which is how built-in models are addressed. That lookup ran across every function on the network, and names are chosen by people rather than generated, so the difference between a hit and a miss reported which names were taken across every workspace. Name resolution is now scoped to the caller, and built-ins and publicly listed functions stay reachable exactly as before.

What you will see if you were relying on the old behaviour. On POST /api/compute/price and the router, a function you cannot reach answers 404, with the same body as an id or name that does not exist anywhere, so the response does not confirm that someone else holds it. A batch still answers 200: one item cannot fail the whole call, so the unreachable item carries that same message as its own error and the rest are priced as usual. The Test button answers 403 for a private function that is not yours, matching what fetching that function's details has always returned. Your own functions, built-ins, and anything listed publicly are unaffected, including testing and routing to a marketplace function you do not own.

Fallback chains follow the same rule. An entry naming a function outside your reach is skipped and the chain moves on, rather than executing it.

If you believe a workspace of yours was named this way, write to support@last-price.ai.

• Explicit routing by function_id now allows only built-ins, your own functions, and publicly listed ones
• Each item of a batch request is checked the same way
• function_name resolution on the router is scoped to the caller, and built-ins stay addressable by name
• Testing another workspace's private function answers 403, matching the details endpoint. Testing a built-in, or a function listed publicly on the marketplace, still works
• An unreachable function is answered exactly as a missing one, so the response is not an existence check (a 404 for single requests and the router, the same message as a per-item error inside a batch's 200)
• Fallback chain entries outside your reach are skipped instead of executed

Previously the MCP server returned an authentication error when no API key was present, blocking agents from discovering what the server could do. It now returns useful responses in that state.

• Pre-credential operation: agents can call MCP tools and receive meaningful output before an API key is configured.
• Graceful degradation: authenticated capabilities are clearly distinguished from those available without a key.

The origin allowlist was shown in several places without explanation, which led some readers to treat it as an access bypass. All occurrences now carry a clear description of its purpose.

• Consistent explanations: the allowlist description is now present in the architecture overview, setup guide, and in-product documentation.
• Correct attachment: the same-origin policy note now appears alongside the function it governs.

Two gaps that blocked agents from using the core pricing call are now closed. First, the endpoint accepts requests that describe work without a product identifier or category. Second, it returns a price even when no prior price exists for that context.

• No product ID required: agents can describe what they need priced in plain terms; the system infers the right function.
• Cold-start pricing: contexts with no pricing history now receive a computed price instead of an error.
• Routing to a capable function: requests are directed to a function that can actually answer them, not just the cheapest available one.
• Accurate capability manifest: the public manifest now lists only the built-in functions that can genuinely price a given request.

You can now submit a price alongside its context and get back a verdict: reasonable, high, low, or unknown when the evidence cannot support a judgement, with the evidence behind it. The public variant of the endpoint works without an API key, so agents can sanity-check prices before signing up.

• Verdict with real reference: the endpoint compares against an actual reference price rather than a placeholder, and discloses when the supporting evidence is not independent.
• No key required for a first check: agents and prospects can call the public verify endpoint without credentials.
• Open band bounds reported correctly: a price band that is open on one side now reports that bound explicitly rather than serialising an unrepresentable value.
• Confidence and weight guardrails: attempts that produce a confidence or weight that cannot be computed are refused at the boundary rather than silently passed through.
• Unknown is a real answer: when no evidence can support a judgement, the verdict says so instead of defaulting to reasonable.
• Fallback on unusable output: a pricing function that returns a value that cannot be used is now treated as a failed attempt, so the fallback chain takes over instead of the request failing.

Agents and explicitly scoped credentials need the price computation grant to use either single-price entrypoint. A missing grant now returns a permission error before any computation starts. Existing dashboard access is unchanged.

Successful router calls now contribute to usage history and totals. If saving usage fails, the computed price still returns and the failure is logged for reconciliation.

A customer used to be a company and nothing else. It can now carry the people behind it.

Contacts. Create a contact against one of your customers with a name, an email, an optional phone number and postal address, and your own identifier for it. Read them back one at a time, as a list, or by the identifier you gave them, update them in place, and delete them. A contact belongs to exactly one customer, and your identifier only has to be unique within that customer, so two customers can each have a contact you number the same way.

A billing contact on an order. An order can name one of its customer's contacts as the contact to bill. A contact from a different customer is refused. Deleting a contact later clears that field rather than touching the order.

A place to manage them. The customer page now lists that customer's contacts, with search, and lets you add, edit and delete them. Choosing which contact an order bills is a dropdown on both the new-order and edit-order screens, where the edit screen used to show a permanent "no contacts found" message and a button that did nothing.

A getting-started guide that works. The Developers page walked new integrators through installing another company's client library and calling endpoints this service does not serve. It now shows five languages calling this API directly, end to end: set up an HTTP client, create a key, create a customer, create a contact, create an order billed to that contact, and price it with order lines.

Two smaller fixes rode along. Creating an order now checks that the customer is yours instead of trusting the identifier, and the order update endpoint is documented, which it never was.

• Contacts: create, list, read, update, delete, and lookup by your own identifier
• Orders accept and return a billing contact
• Contacts section on the customer page, with add, edit, search and delete
• Billing contact selectable when creating or editing an order
• Getting-started walkthrough rewritten against the real API in Python, Node.js, Go, Ruby and Java

Your policy's `strategy` is now the control it looked like. A policy created with "strategy": "cheapest" and "is_default": true was accepted, checked against the seven-value enum, and written to the database, and then the router never looked at it. Requests that state no preference carry default, which sent them to the policy's rules and then straight down its fallback_chain, so the policy routed to the head of the chain, on every ordinary request, no matter which strategy it named.

The router now dispatches on the stored strategy, between the rules and the chain. cheapest, fastest, round_robin and weighted all take effect on traffic that states no preference of its own.

The order of precedence, which is worth knowing: a function_id on the request pins one function; a routing_preference of cheapest, fastest, round_robin or weighted is obeyed as sent and overrides your policy's strategy; otherwise your default policy decides, and within it a matching rule wins, then the strategy, then the fallback chain, then the single fallback function, and finally the same built-in-or-cheapest pick a workspace with no policy gets. The chain is now a fallback in fact as well as in name: it is reached when the strategy produces nothing available, such as a weighted policy whose weights name no function that is currently up.

A behaviour change, not only a fix: your cost and latency ceilings now bind. config.max_cost_per_unit and config.max_latency_ms are presented as maximums, and the router never read either of them. They are applied now, so a function above a ceiling is no longer a candidate and cheapest means the cheapest of the functions that qualify rather than the cheapest outright.

If you already have a policy carrying one of these, its routing can change the moment this ships, without you touching the policy. Two cases to check. Where some functions qualify, traffic can move to a different function than it used to reach. Where none qualify, the strategy now produces no pick at all and your fallback_chain decides, which for cheapest and fastest policies is the first time that chain has ever been reached: those two strategies always returned something before, so their chain was a fallback in name only. A ceiling you set once and forgot, or set tighter than any function can meet, is the case to look at first.

The ceilings constrain the strategy alone. A matching rule in config.rules names one function deliberately and still overrides them. Clearing a ceiling restores the previous behaviour exactly.

Policies that could never be honoured are rejected when you write them. weighted needs config.weights and policy needs config.rules; without them the strategy has nothing to act on and the request quietly fell through to the chain. Both are now a 400 on create and on update, and update checks the policy your patch produces rather than the patch alone, so setting "strategy": "weighted" on a policy that already carries weights still works. Update also validates its body at all, which it did not before: a misspelled strategy used to land in the column unchecked.

The routing policies screen keeps up with the new rules. Create and Save stay disabled while the form would build a policy the API refuses, and a rejected save now shows the reason in the dialog instead of leaving it open with nothing said. Editing a policy also no longer drops settings it was not showing you. The form builds its update from the policy it is editing rather than from the visible fields alone, so a cost ceiling, latency ceiling or other stored setting survives a save even when the selected strategy does not render a field for it. Clearing the single fallback function works again too.

Changing which policy is the default now takes effect immediately. Marking a new policy as default cleared the old one in the database but not in the running instance, so the superseded policy kept deciding routing until the instance restarted. Now that the strategy is read from the policy, that meant routing by a strategy you had replaced. The in-memory store follows the same one-default-per-workspace rule the database does.

A clearer error for a function you just registered. Registration creates a function as draft, and routing to one explicitly refuses anything that is not active, which is the first thing most integrations hit. The refusal now names the fix instead of only the state, quoting the PATCH that activates it. A function you deactivated yourself gets the refusal without that sentence.

One caveat, unchanged by this: a stored policy still only applies on the instance that created it, because nothing reloads policies from the database at start-up. If you need routing that holds on every instance, send cheapest, fastest or round_robin as the request's routing_preference; those three are computed from the available functions alone. weighted and policy still read their weights and rules from the stored policy, so they are not a workaround for this.

• A policy's strategy is honoured for requests that state no preference
• A routing_preference of cheapest, fastest, round_robin or weighted still overrides the stored strategy
• weighted without a positive weight in config.weights, and policy without config.rules, are refused with a 400
• PATCH /api/routing-policies/{id} validates its body and can now answer 400
• The policies dialog disables submit for a policy the API would refuse, and shows the reason when one is refused
• Editing a policy preserves its cost, latency and circuit breaker settings, and can clear the fallback function again
• A policy’s maximum cost per unit and maximum latency are now applied when the strategy picks a function
• Marking a new policy as default takes effect without waiting for a restart
• Routing to a draft function explains how to activate it

The Usage page now reports the AI-backed features alongside pricing requests.

• New AI tab with calls, tokens, and cost for agent generation and task estimation
• Separates calls paid for with your own provider key from calls on the platform key, so the billable amount is explicit
• Per-operation breakdown for the selected time range
• The same figures are available from the API for reporting and reconciliation

A new AI usage tab appeared in the dashboard, showing a breakdown of AI calls over any date range you select. Errors from the usage endpoint now return clean messages instead of raw database output, and the tab strip targets are tall enough to tap comfortably on touch screens.

• Dedicated AI usage tab in the dashboard with date range filtering
• Usage requests validate date formats before querying, so malformed inputs get a clear error
• Error responses from the usage endpoint no longer include internal database details
• Tab tap targets are at least 44 px tall for reliable touch interaction

Several places where the API reference promised one thing and the API did another are now settled, each on the side that was correct.

• Listing pricing functions honours the built-in filter. Asking for only built-in functions, or only your own, previously returned the full list with no indication the filter had been dropped. An unrecognised value is now rejected instead of ignored.
• The default marketplace commission is 30%, which is what the reference, the stored default, and the payout maths already said. Listings created through the API were getting 20%. Setting the rate explicitly works as before.
• Listings created before this change keep the rate they were created with. A listing that was created without setting a rate took the old 20% default and still does, while the published default is now 30%; one where you set the rate yourself is unaffected and always was. Nothing was changed retroactively. If you have a listing on the older default and want it moved, contact support@last-price.ai.
• The pricing object returned with a variant carries whatever fields that variant's metadata defines, and the reference now says so and documents how to set it. Putting features in variant metadata is the supported way to return real feature copy. Metadata that reuses plan, price or features has to match the type the response declares, and an experiment whose metadata would break the response is now rejected when you create it rather than producing an invalid response later.
• The inbound mail webhook documents the signature headers it verifies, so generated clients and security reviews see it as authenticated.

The API reference could show a missing-specification message depending on which directory the application was started from, and a specification the server could not read was reported the same way as one that was not there.

• The reference finds its specification in every supported layout
• A specification the server cannot read now reports a server error instead of a missing page, so the real fault is visible
• Pointing a deployment at a specific specification file is now authoritative: if that file is absent the reference says so, rather than quietly serving a different contract
• The published specification is checked by a real validator before any change can merge

Reading the published reference and calling what it described could produce a 404 on an endpoint that was never built, or a rejection on a method the service does not accept. Nine operations were affected, and each has been resolved against the behaviour that actually ships.

• Updating a customer, an invoice or a dispute is a partial update and is documented as one. Send only the fields you want to change, rather than a complete replacement object
• Adding a line to an order is documented as the single-line append it has always been, instead of a bulk replace that was never implemented
• Request schemas now list exactly the fields each endpoint reads, along with the limits it expects, so a reference-valid body is an accepted body
• Order line amounts are documented as the decimal strings the API returns, not as numbers
• Updating or deleting a customer by external id, and the contacts endpoints, have been withdrawn from the reference. They were listed but never built, and calling them could only fail

The reference for the customer, order, invoice, payment, dispute, credit and cost endpoints described a response body that no endpoint has ever returned. It is now written from the responses themselves.

• Field names match the response, so a generated client reads a real value instead of undefined
• Money and quantity fields are documented as decimal strings, which is how they arrive, rather than as numbers
• List endpoints are documented with their data and pagination envelope instead of a bare array
• Deleting a customer, contact, invoice or credit bundle is documented as a 200 with a confirmation message, which is the response you get
• Adding an order line is documented as the single POST it is, rather than a bulk update that was never available
• The in-app documentation examples for these objects were rewritten to match, so the two no longer disagree
• A contract test keeps these schemas tied to the endpoints, so the reference cannot drift away again unnoticed

Conversations in Ask Last Price now call the AI model in real time. Every response includes a per-message artifact you can save or share.

• Responses reflect your actual query, not pre-written examples
• Artifacts are attached to each message individually
• Usage is recorded per workspace for metering purposes

The Developers page offered a "generate a token" flow that called an endpoint removed months ago, when sign-in moved to dashboard sessions and the OAuth client credentials grant. It could only fail, and the surrounding documentation described it as if it worked.

• The dead token generator is gone from the Developers page
• The API Reference no longer advertises the removed endpoint
• Authentication guidance now names the real flows: an agent-bound key exchanged at /api/oauth/token, a plain tenant key sent as x-api-key, and a separate exchange for native apps
• The copyable example on the API Keys page includes the userId parameter the pricing endpoint requires, so it works as pasted
• A contract test now fails the build if the reference documents an operation no route serves

Removing an order that was created by mistake previously meant leaving it in the list. Draft and cancelled orders can now be deleted outright, from the orders list or through the API, and the order's line items are removed with it.

• A draft or cancelled row on the orders list has a delete action, behind a confirmation, that says exactly what will be removed
• An order that has reached a billing stage cannot be deleted outright. Those rows offer Cancel in place of delete, so the step that makes an order deletable is one click away, and the API declines a direct delete and points you at cancelling first. The rule is that deleting a live order is never a single unconsidered click, not that such an order can never be removed
• An order that has started billing also cannot be moved back to draft, so the protection cannot be stepped around
• Cancel an order first, then delete it, if you want it gone once it has started billing
• Deleting an order removes only that order and its lines. Invoices and payments are untouched

The Elo Index gives you a live, ranked view of how pricing functions perform across the network. Scores are computed from actual usage, not self-reported metrics.

• Accessible at the new Leaderboard page in the dashboard
• Rankings update as network usage accumulates
• Exposed through the API so agents can query current standings programmatically

The embed snippet can now talk to the API directly from a customer's browser. Create an embed token in the dashboard, list the sites it may run on, and paste it into the snippet. It is built to be public, so it is safe in your page source.

• Create, inspect, and revoke tokens on the Embed Snippet page, and the generated snippets come pre-filled
• Each token works only from the sites you register on it, which stops it working if it is copied onto another web page
• Reaches the price lookup and conversion tracking only, and is rate limited per token and client address
• Your secret key keeps whatever access its scopes allow and stays on your server, where a browser cannot reach it
• Revoking a token takes effect on the next request

AI agents can now reach the Pricing Compute Network directly through a Model Context Protocol server. Any MCP-compatible agent or orchestrator can call one tool and get a computed price back.

• Works with any MCP-compatible agent framework out of the box
• Returns the same price results available through the REST API
• No additional authentication setup beyond your existing workspace credentials

The Last Price mobile app brings on-the-go pricing to any media or attachment you can share from your device.

• Price photos, documents, audio clips, and product links in one flow
• Browsable history tab shows past price checks
• Sign in with your existing Last Price account

The mobile pricing screen was redesigned from the ground up. The layout now opens with a single Add action that reveals a source picker, keeping everything else out of the way until you need it. Account and advanced options moved into a header menu, and the empty state is a calm, centered prompt with no extra chrome.

• All-black, high-contrast visual style with sharp borders throughout the app
• Single Add action opens a source picker instead of showing all options at once
• Account and advanced settings consolidated into one header menu
• Centered, minimal empty state with no distracting title or secondary actions

You can now share any photo, screenshot, document, or link straight into Last Price from any other app on your device. The share sheet intake handles multiple files, enforces attachment size limits before anything is sent, and keeps pricing locked while attachments are loading so results are always consistent.

• Share images, documents, and links from any app directly into the Last Price pricing screen
• Attachment size is checked before files are read, so oversized items are rejected immediately with a clear message
• Files are processed one at a time to prevent partial or mixed results
• In-flight requests are cancelled automatically when you sign out, so no results from a previous session appear
• Sub-cent costs now display to six decimal places in results and to two decimal places when the cost is zero
• History entries show compute costs with full sub-cent precision

Access controls for multi-tenant workspaces were reviewed and the criteria for granting cross-tenant access were tightened.

• Tenant API key storage is now documented accurately, removing a description that did not match the live system.
• The conditions under which a stored routing policy applies are now stated explicitly, so integrators know when to override it in the request instead.

The published OpenAPI specification now includes all 41 schema definitions that belong in the shared components section.

• Generated SDKs and clients that reference these schemas will resolve correctly again
• AI agents relying on the spec for tool discovery see complete, accurate type information
• Description punctuation across the affected endpoints was also corrected

Several gaps in the OpenAPI spec were closed. The shared 401 response now documents real authentication requirements, the advertised API key header matches what the API actually reads, Elo routes are mapped to their correct spec entries, and the function-test operation has its own dedicated request schema instead of sharing one.

• Shared 401 response documents the authentication contract accurately
• Advertised API key header name matches the header the API reads
• Elo leaderboard routes mapped correctly in the spec
• Function-test operation has its own request schema with an accurate description
• Docs page rewrites only the canonical host, leaving all other spec content intact

Every order id in the orders list linked to a page that did not exist, so clicking one returned a 404 and the edit form could not be reached from the list at all. Orders now open to a read-only detail page, matching how invoices already work.

• The detail page shows status, customer, agent, totals, dates, and metadata
• Line items appear with quantity, unit price, amount, and a subtotal
• Draft orders can be activated from the page, and the edit form is one click away
• Order line items can now be read back through the API, not only written

The Pricing Compute Network documentation was substantially rewritten across the integration guide, deployment reference, and network design document. Every example now reflects the live API contract.

• Routing policy examples now show how a policy actually selects a pricing function, and what to send when recording a conversion.
• HTTP-served pricing function registration now shows the execution type that calls your endpoint.
• Price experiment setup now warns that variants must be named control and experiment; any other names silently serve a single price.
• The error code table for compute endpoints now matches the exact codes the API returns when a computation fails.
• The request latency limit field is documented as not yet applied; callers should set their own timeout.
• Dashboard figures and marketplace listings that are still placeholder are now clearly labelled as such.
• Zero-revenue conversions are documented as not recordable, with guidance on what to send instead.
• API hosts that are not yet serving are identified, so you know which endpoints to target.

A pricing experiment could previously run to completion while showing every visitor the same price, and still look healthy on the results page. That happens no longer.

• Creating an experiment now fails with a clear message unless it has exactly two variants named control and experiment. Those are the only two arms the assignment engine can assign, so any other setup recorded its results under those two names while serving prices from arms you had named something else.
• If an experiment somehow reaches the pricing endpoint with an arm that cannot be served, the request now returns an error instead of silently falling back to the first variant. No view or revenue signal is recorded for a price that was never shown.
• The per-variant weight you set is now honoured. Previously every experiment ran on a fixed even split regardless of the weights you configured. Set 70 and 30 and traffic now splits 70/30; leave both unset to keep the even split.

If you are running an experiment whose variants are not named control and experiment, its results to date are not valid and should be discarded. The price a visitor saw did not reliably match the arm their result was recorded under, and depending on the order the variants were stored, one arm's price may have reached nobody at all while the results page still reported figures for it. Where neither arm carried a supported name, every visitor saw the same price. Those experiments now return an error instead of a price, so recreate them with the supported names to collect real data.

Separately, if an experiment set a weight on only one of its two arms, it has been running on an even split rather than the split you configured, because the weight was never applied. It keeps serving, and you can correct it by setting a weight on both arms or on neither. Testing more than two prices at once is not supported yet.

Every pricing call is now recorded in your usage ledger, not just batch calls.

• Usage, usage events, and the cost breakdown now include single price requests
• Monthly usage roll-ups count the same traffic, so totals no longer run low
• A recording failure never blocks a pricing response; you still get your price

Cost estimates for agent tasks are now computed from the AI model in real time, broken down by country.

• Replaces the previous static sample figures
• Estimates reflect current model pricing and task parameters
• Available through the same API endpoint as before

Two things that tripped up first-time integrations are fixed.

You can now discover your own workspace ID. Endpoints that carry the workspace in their path, such as POST /api/tenants/{tenantId}/experiments, only accept the workspace your credential resolves to, but there was no way to learn that value with an API key: the workspace listing is gated on a browser session, and no dashboard screen displayed it. GET /api/me now returns it, along with how the request authenticated and what scopes the credential carries. Settings then API keys displays the same value with a copy button, and the Developers page reads it from your session rather than asking you to type it in.

`POST /api/functions/{id}/test` resolves database-backed functions. The route initialised the in-memory function registry rather than the database-backed one, so on a cold instance it could not see functions the workspace had registered and returned 404 Function not found for a function that had just been created successfully. It now initialises the same registry as every other function route.

• GET /api/me reports tenant_id, auth_method, and scopes for the presented credential
• Workspace ID shown with a copy button under Settings then API keys
• Developers page reads the workspace from your session instead of a typed input
• Function test endpoint no longer 404s on a workspace's own functions

The marketplace browse catalog gained a Media category alongside a set of media-focused pricing models you can discover and explore.

• New Media filter on the marketplace browse tab
• SVOD Tier Optimizer for churn-aware streaming subscription, bundle, and ad-supported plan pricing
• Ad Inventory CPM Engine for real-time programmatic video and display floor pricing
• Stock Media Repricer for demand and exclusivity-based licensing of photo, video, and audio assets
• Generative Render Metering for per-second and per-resolution AI video and image generation

The commerce control plane used to need a connected storefront before it could do anything. Run a cycle on a brand new workspace and every count came back zero, so there was no way to try approvals or see a proposal.

Now the Commerce dashboard has a "Load sample data" button on the Pipeline tab. One click:

• Creates a demo connector account with a small sample catalog
• Adds competitor observations priced below your catalog
• Adds an "undercut competitors by 3%" policy that needs manual approval
• Runs a full cycle so proposals appear in the Approvals queue

From there you can approve or reject a proposal end to end, exactly as you would with a real store. When you are ready, connect your own storefront and run cycles against your real catalog.

Questions? Reach us at support@last-price.ai.

A round of fixes across the commerce pages ensures that partial failures no longer result in silent empty states.

• The costs page loads cost data even when customer names cannot be resolved
• A notice is shown when the trace list is capped at its maximum size, so you know results may be incomplete
• Trace-load failures now display an error message instead of an empty table
• Orders, invoices, and credits lists are now wired to their real APIs, replacing the last remaining mock responses on those pages

Four dashboard pages that previously displayed stub data or silently faked success have been wired to the live APIs.

• Costs page now pulls from the real cost APIs and no longer shows invented KPIs.
• Usage page now reads from the live metering APIs, so usage figures match what is actually recorded.
• Invoice detail page - the "Send invoice" action now submits to the real endpoint and persists the result.
• Payment detail page - the "Refund" action now calls the real refund endpoint; refunds are processed and recorded instead of returning a fake success message.

Two user-visible bugs in the billing flows were resolved.

• Payment date entered at creation time is now stored correctly and displayed in the payments list; the date field uses a proper date picker control
• Invoice detail Edit link and the order edit page were broken when the record ID was not yet resolved; both now await the ID before rendering

Anyone can now visit /price-check to run a live pricing query across modalities, no account required. The page is linked from the main nav and uses a streaming pipeline endpoint purpose-built for public access.

• New /price-check page with a multi-modal pricing form available to all visitors
• Public pipelines API endpoint enforces a 2 MB request body limit
• Abort handling cancels in-flight requests when the user navigates away

A new write client and scheduled publishing pipeline ship pricing data to a structured dataset on a regular cadence.

• A cron-triggered endpoint builds the current pricing dataset and publishes it automatically
• A staff-only endpoint allows on-demand dataset pushes outside the scheduled window
• The integration layer gained a typed write client for the dataset host, with full test coverage

The pricing models section is now fully wired to a persistent backend. Data is stored in a dedicated table and served through a new API route, so the page reflects real configuration instead of static placeholders.

• Added a GET /api/pricing-models endpoint that reads and returns live pricing model records
• Pricing models page replaced mock state with real API-backed data
• Input validation added to the new endpoint to reject malformed requests early

The signals page now reads from a real endpoint backed by persistent signal records, so the data you see reflects your actual usage history.

• Refreshing the page no longer shows stale signal data from a previous load
• The signals API rejects malformed date and limit parameters with a descriptive error instead of silently failing
• AI agents calling GET /api/usage/signals can rely on validated, structured responses

Webhook configuration moved from an in-memory UI state to a fully persisted, tenant-scoped store. Each endpoint you add is tied to your workspace and survives sessions.

• Create, update, and delete webhook endpoints from the dashboard; changes persist immediately
• Send a signed test event to any saved endpoint with one click
• Each delivery attempt is recorded in a log so you can confirm receipt and inspect failures
• All test events are signed using the same signature scheme as live events

Two authentication improvements shipped together to tighten access control across the API.

• First-party session tokens are now accepted on all authenticated API routes, so browser-based flows no longer require a separate API key
• x-tenant-id is now validated against the caller's workspace membership; unrecognized or unauthorized values are rejected rather than passed through
• Staff email allowlist is honored even when the database promotion step fails, preventing lockouts during degraded states

The PriceRouter surface is now fully represented in the OpenAPI contract:

• GET /api/price-router documented with PriceRouterCapability response schema (providers, builtins, strategies, metering constants)
• POST /api/price-router documented with typed request/response schemas including function-name resolution and metering output
• Seven new component schemas: PriceRouterCapability, PriceRouterStrategy, PriceRouterProvider, PriceRouterBuiltin, PriceRouterMetering, PriceRouterRequest, PriceRouterResponse
• New /features/price-router marketing page with investor-facing copy framing the multi-vendor routing as "OpenRouter for price computation"
• SDK generators and agent tool runtimes can now validate against the canonical contract without relying on runtime discovery alone

Last Price implements the Universal Commerce Protocol (UCP) so AI shopping agents and commerce platforms can interact with your pricing without custom integration code.

• Standard discovery at /.well-known/ucp advertises checkout and pricing compute capabilities with protocol version negotiation
• Full checkout session lifecycle: create, read, update, complete, and cancel, with idempotency on every mutating call
• Pricing quotes flow through the same compute pipeline, so routing policies, metering, and cost tracing all apply automatically
• UCP-Agent header negotiation ensures forward compatibility as the protocol evolves
• Fulfillment and discount extensions are supported from day one
• New dashboard page under Commerce shows all UCP checkout sessions with status, buyer, totals, and line item count

If you connect a storefront or marketplace account, the OAuth tokens and API keys you hand us never sit unencrypted on disk. Reads now return a __unreadable sentinel instead of raw ciphertext when decryption fails, so a misconfigured key cannot leak a token through an error path.

• AES-256-GCM envelope encryption applied to stored connector credentials
• Plaintext fallback dropped: legacy rows are read once, re-encrypted, and the plain form is purged
• Decrypt failures return a sentinel value, never the raw stored bytes
• Same cryptographic wrapper used for workspace API keys is reused here so there is one path to audit

Questions or concerns: support@last-price.ai.

Signing into Last Price is now a first-class experience instead of a detour. The old /login route is gone and everything redirects to the new /sign-in and /sign-up pages.

• One-click Google sign-in on both pages
• Forgot-password and reset-password flows wired end to end
• Sessions refresh in the background so deep links into the dashboard resume cleanly after a tab has been idle
• Sign-up form labels its fields explicitly so browser password managers stop autofilling company name into the email field
• Same look and feel as the dashboard, with the LastPriceLogo squircle in the sidebar on desktop and the header on mobile

The /app shell now renders in a read-only preview mode for signed out visitors. Catalogs, sample functions, and the marketplace are visible; anything that mutates state (creating a function, running a priced call, editing settings) prompts a sign-in instead.

• Header CTAs adapt: signed-out visitors see "Sign in" and "Open the app"; signed-in users see their workspace switcher
• A dedicated public-preview API guard blocks write paths at the server boundary, not just in the UI
• Telemetry hook captures preview-mode page views separately so we can measure conversion from preview to signed up
• Dashboard layout no longer races on the redirect decision when a session is still loading

Previously a small number of internal routes would accept an x-user-id header as a fallback when no bearer token was present. That fallback is gone. If your integration was relying on it (it should not have been), switch to the standard Authorization: Bearer <token> flow and you are set.

• Header fallback removed from all API routes
• OpenAPI spec scrubbed of x-user-id references
• Bucket-key paths now key strictly off the authenticated identity
• Components that previously read the header now read from the auth context

If you are unsure whether you were depending on the old behavior, the fastest check is to issue a request without the header and make sure it still succeeds.

The commerce control plane wires together every piece you need to move from "I have a Shopify store" to "Last Price set my prices this morning, here is the audit log." A full cycle runs:

• pullCatalogs from connected storefronts
• pullObservations from PriceAPI and Keepa
• matchSnapshots via Rosetta
• decidePrices through the pricing policy engine
• createProposalsFromDecisions into the approval queue
• executeApproved back to the storefront connector
• Every step writes to the audit log

What shipped:

• Seven packages live in packages/commerce-control-plane and friends (connectors, observations, matching, pricing-policy, approvals, execution-router, orchestrator)
• Eight cp_* tables backing the cycle (see migration 007)
• /api/commerce/* routes for triggering each step independently
• Dashboard at /commerce shows the live cycle, recent proposals, and the audit log
• Mobile commerce view collapses tabs to icons and shortens execute button copy so the cycle stays usable on a phone

Visual cleanup pass across every surface. The squircle is the canonical mark; the wordmark component is shared between the auth sidebar and the mobile header so they cannot drift again.

• New LastPriceLogo squircle on every auth page
• Emerald L$ mark promoted to the favicon and dashboard accent
• Sign in and sign up pages match the dashboard color scheme
• Copy passes across the dashboard caught lingering references to the prior brand and unified everything under Last Price
• Color tokens consolidated under the Tailwind v4 @theme inline block so theming is one file, not scattered overrides

The OpenAPI spec is the contract. We grew it so it actually covers the whole product, not just the original handful of endpoints.

• Tags for PriceRouter, Rosetta, Commerce, Signals, and the underlying inference router
• Every request and response has a named schema, so generated clients (and agent tool definitions) come out clean
• Capability descriptors are part of the spec, so a generated client can introspect available providers and models at runtime
• Spec is served at the API root and rendered with a "try it now" panel in the API docs page on the marketing site

PriceRouter is a multi-vendor catalog of pricing models behind one API. These three additions make it transparent.

• Explain after run: every response can include a step-by-step trace of which provider was picked, why, and what each one would have returned
• Compare strategies: a side-by-side view in the dashboard runs the same input through cheapest, fastest, policy, and the rest, so you can pick the strategy with eyes open
• Clickable catalog: each provider/model has its own page with description, cost per unit, and a one-click playground
• Tool manifest: /api/price-router returns a manifest that agent frameworks can consume directly, with each built-in named lastprice/<provider>-<model> so the provider is unambiguous

PriceRouter is "OpenRouter for price computation": one OpenAPI surface in front of multiple pricing vendors. The capability endpoint now returns the list of providers, their descriptions, and the models we expose for each, so an agent can call GET /api/price-router and discover what is available without scraping docs.

• New GET /api/price-router capability endpoint
• PriceRouterCapability OpenAPI schema with providers[] (id, display name, description, model count) and per-builtin provider
• Built-ins named lastprice/<provider>-<model> so the provider is unambiguous from the function name alone
• Dashboard reframes PriceRouter as multi-vendor: clickable catalog, compare-strategies view, explain-after-run, and a downloadable tool manifest for agent frameworks
• Snippets switched to safe JSON-to-Python literal conversion so copy-pasted examples run on first try
• POST body now uses proper context nesting and returns the actual response shape (previous docs had drift)

Both documents were rewritten from scratch to match how Last Price actually works today: who handles what data, how connector credentials are stored, what happens on account deletion, and where to send a disclosure. The legal hub at /legal is the entry point.

• New plain-language Privacy Policy at /privacy
• New plain-language Terms of Use at /terms
• Legacy /tos route returns a 308 Permanent Redirect to /terms
• Footer "Legal" column links to the hub, the policy, and the terms
• Security disclosures and legal questions both go to support@last-price.ai

A small change with a real impact on perceived speed for workspaces with large rosters.

• Membership verification uses an indexed LIMIT 1 lookup instead of iterating the team
• The team settings page makes one query for the full roster and derives membership in memory, instead of two round trips
• Tested against rosters up to several hundred members; the page now loads in well under a second on cold cache

If you wire Last Price into your stack, you receive signed webhooks for proposals, price changes, and approvals. The new public verifier lets you (or your AI agent) check a signature without writing a line of code. Same algorithm as the SDKs, just runnable from a tab.

• Paste the Last-Price-Signature header and the raw request body
• Tool confirms the HMAC and surfaces the timestamp window
• Failure messages name the exact reason (wrong secret, replay outside the freshness window, body altered after signing)
• Reference snippet shows how to do the same verification in code

Last Price is now multi-tenant from the ground up. Invite teammates, assign roles, and switch workspaces from the avatar menu.

• Three roles: owner (billing + members), admin (settings + secrets), member (read and run, no destructive actions)
• Workspace switcher in the dashboard header keeps you scoped at all times; API keys are workspace-scoped too
• Membership and role checks run on every request, with the audit trail attributing each action to a real person
• GET /team returns the full roster in a single round trip; the membership check no longer re-queries on every page load

The built-in catalog grew from eight to fifteen. Every function is token-metered, callable from any SDK, and works the same way an AI agent would invoke it from a tool manifest.

• Rosetta: translate, normalize, validate, suggest, freeze, and ingest for canonical-schema translation and autonomous merchant onboarding
• Elo: ab-test, significance, and allocator for live experimentation on pricing variants
• Jale: optimizer, elasticity, advanced, psychological, bundle, and tier-optimizer for end-to-end revenue and margin shaping
• All fifteen share the same metering rate and the same input/output schemas, so swapping one for another is a single string change

Rosetta is our translation layer between merchant payloads and our canonical schemas (offer, product, observation, match, action). The new ingest endpoint runs the full proposal-to-staged-mapping pipeline in a single call, so a merchant or an agent can onboard without clicking through the Mapping Studio.

• New POST /api/rosetta/ingest endpoint backed by the lastprice/rosetta-ingest builtin
• Rosetta dashboard now has six tabs: Translate, Mapping Studio, Onboard, Canonical Schemas, Review Queue, Frozen Adapters
• Mapping Studio supports both UI editors and agent-driven JSON edits
• Built-in catalog now includes Rosetta's six functions (translate, normalize, validate, suggest, freeze, ingest) for a total of 15 built-ins across Jale, Elo, and Rosetta

Last Price is something people open from email and Slack, often on mobile. The dashboard now expects that.

• Dark mode is the default, with prefers-color-scheme: light still honored
• Every page tested at 375px (phone), 768px (tablet), 1280px (desktop)
• Tables that used to overflow now either reflow as cards below the md breakpoint or scroll inside a contained wrapper
• Dialogs and sheets render full-width on small screens with scrollable content areas
• All interactive elements meet the 44 by 44 pixel tap-target minimum
• Charts use a responsive container so they fit any width without blowing out the page

Different storefronts speak different languages. Rosetta is the layer that turns "your" schema into "ours" without you writing glue code.

• POST /api/rosetta/translate accepts any merchant payload and a mapping, returns a fully validated canonical record
• Mapping Studio in the dashboard supports both UI editing and agent- driven JSON edits, so a person and an agent can collaborate on the same mapping
• Validation runs against trust tiers: high-confidence mappings ship straight through, low-confidence ones land in the review queue
• Frozen Adapters tab lets you pin a mapping version so production traffic does not drift when you experiment with new fields
• Tested against the canonical schemas for offer, product, observation, match, and action

Two changes that close long-standing hardening items.

• Workspace API keys are encrypted at rest in the format ivHex:authTagHex:cipherHex. The same wrapper is reused everywhere we store a secret, so there is one cryptographic path to audit.
• Reads are backward-compatible with legacy plaintext rows. If decryption ever fails, the read returns null rather than leaking the stored ciphertext through an error path.
• Dashboard session tokens moved from localStorage to sessionStorage so they are scoped to the browser tab and do not survive a tab close.

Two product surfaces that turn Last Price from "API you call" into "thing you ship to customers".

• Embed Snippet page in the dashboard generates a single drop-in tag with your workspace ID baked in. The snippet streams observation events back to Last Price so your pricing functions see real demand, not just static config.
• Experiments / A/B Testing page lets you split traffic across pricing variants, watch the allocator balance arms, and call the Elo significance built-in to decide when to declare a winner.
• Both surfaces work with any pricing function in the marketplace, built-in or custom.