Don't Paste the AI. But Also: Know Which AI Your Team Is Calling.

"Don't Paste the AI, Please" hit HN #1 with 491 points and 238 comments. The site is a community resource arguing against thoughtlessly copying and deploying AI-generated output. The argument is simple: just because an LLM produced code, text, or analysis doesn't mean it's correct, safe, or appropriate to ship without review.

The thread resonated because every developer has watched a colleague paste AI output into production without reading it. The problem is real. But it's only half the problem.

The question "Don't Paste the AI" leaves open

Essential

"Don't paste the AI" tells you what to do with AI output. It doesn't tell you which AI generated this, for which team, at what cost, and why that model was selected. That's the audit question — and it's the question enterprise governance teams are asking.

The governance gap is upstream of the paste problem. Before you can evaluate whether AI output is safe to deploy, you need to know:

Which model generated this output? Was it GPT-5.6 Sol? Claude Opus 5? DeepSeek V4? The quality, safety, and regulatory profile of the output depends on the model that produced it.
Which team or user initiated the request? In an enterprise with 50 developers using AI coding tools, attributing AI-generated output to the right team is a governance requirement — not a nice-to-have.
What did the request cost? If a single Claude Code session generated $15 of API traffic, someone's budget needs to reflect that.
Why was this model selected over alternatives? If your routing layer picked Opus 5 for a boilerplate generation task, that's a routing decision worth auditing. If it picked DeepSeek V4 Flash for a security-critical code review, that's a different conversation.

Per-request attribution is the missing layer

Essential

"Don't paste the AI" is a culture fix. Per-request attribution is an infrastructure fix. You need both. Culture tells developers to review AI output before shipping. Infrastructure tells governance teams who called which model, how much it cost, and why the routing layer selected it.

The infrastructure fix has three components:

Virtual keys with team scoping. Every API call through the proxy carries a virtual key that attributes the request to a team, project, or user. When AI output shows up in a code review, the governance team can trace it back to the specific request, team, and model that generated it.
Per-request routing evidence. For every request, the proxy records: which LCR rule applied, what quality score was calculated, what the projected cost was, and why this model was selected over alternatives. This is the "why this model" audit trail — available per-request, not as an aggregate dashboard.
Realized cost ledger. The proxy records the actual token count and cost for every request — not estimates. When the finance team asks "how much did Team X spend on AI last month?", the answer comes from per-request data, not from a vendor invoice that lumps everything together.

Why this matters now

The "Don't Paste the AI" thread hit HN the same week that several enterprise AI governance developments converged:

OpenRouter was acquired by Stripe — raising the question of who owns the routing layer and whether enterprise traffic data is now adjacent to payment data
Claude Code shipped an undocumented behavioral change (THRIFTY_SONIC) — proving that harness vendors can and do change per-request token economics without notice
AI governance regulations are tightening — the EU AI Act's documentation requirements, NIST AI RMF attribution requirements, and enterprise procurement teams' internal AI policies all require per-request audit capability

The convergence point: AI governance is no longer a culture problem ("don't paste the AI") or a policy problem ("we need an AI use policy"). It's an infrastructure problem. The proxy layer is where attribution, audit trails, and cost governance live. Without it, "don't paste the AI" is advice without enforcement.

The audit trail that answers "which AI generated this?"

Essential

When a governance team asks "which AI generated this code, and was the routing decision appropriate?", the answer should be one API call away: GET /logs/{id}/routing-evidence returns the model, the routing rule, the quality score, the projected cost, and the actual cost. No dashboards to interpret. No aggregates to decompose. Per-request evidence.

This is what per-request routing evidence looks like in practice:

Model selected: anthropic/claude-sonnet-5
LCR rule applied: coding-agent-tool-call (quality tier: high, cost ceiling: $10/MTok)
Quality score: 0.87 (above threshold of 0.75)
Projected cost: $0.0042 (2,100 input tokens, 850 output tokens at $2/$10/MTok)
Alternatives considered: openai/gpt-5.6-sol (quality: 0.82, cost: $0.0031 — below quality threshold), deepseek/v4-flash (quality: 0.79, cost: $0.0019 — below quality threshold)
Team attribution: platform-eng/virtual-key-7a3f
Cache savings: $0.0018 (cache marker injected, 1,200 tokens cached at 90% discount)

That's the audit trail. One request. One model. One routing decision. One cost figure. One team attribution. One cache savings entry. Available on demand, per request, for every request that flows through the proxy.

"Don't paste the AI" is the right cultural advice. Per-request routing evidence is the infrastructure that makes it enforceable.

Trimio provides per-request routing evidence, virtual key team attribution, realized cache savings ledger, and per-team cost governance — all through a single proxy layer. See how it works.

Trimio

Audit every request. Govern every model.

trimio provides per-request routing evidence, team-scoped virtual keys, and realized cost ledger — the infrastructure layer for AI governance. Don't just tell your team not to paste the AI. Show them which AI they're calling.

Start Free See the product