今日已更新 153 条资讯 | 累计 31421 条内容
关于我们

标签:#t

找到 14981 篇相关文章

AI 资讯

More Watts, Less Light

Token burn and business outcomes are not correlated. More burn means more inefficiency, not more value. The electricity problem Imagine you walk into a dark room. Turning on a light helps you see. Turning on every light in the building does not help you see better. It's still the same room. Now every surface is equally lit, the contrast is gone, and you're paying for power you didn't use. Tokens work the same way. A focused prompt with clear scope is the single overhead light over your desk. A sprawling prompt with unlimited exploration is every light in the building — you're burning power, not producing insight. Tokens are electricity, not output. More throughput doesn't mean more value. I've had weeks where I burned through my allocation and looked back at the end to find nothing concrete. Code that worked but went unused. Exploratory branches that dead-ended. Agents that generated plausible-looking output that didn't survive first review. A lot of motion. Not much progress. The ceiling stops you from doing that indefinitely. It forces a moment of reflection: did this burn produce anything real? If the answer is no, more capacity isn't the fix. More discipline is. Three patterns I now use instead I started paying attention to what actually ships versus what just burns context. I gave the patterns names so I could catch myself faster: RTK — Read The Knowledgebase. A focused 15-minute read of the codebase, identifying the exact files and exact changes, saves 200K+ tokens of exploratory waste. The agent doesn't discover the shape of the task — it executes against a known one. Caveman — compress before you prompt. Strip greetings, filler words ("I think", "basically", "Let me know if that makes sense"), and closing courtesies. Every word in your prompt multiplies across every response token. Less fluff in means less fluff out. Ponytail — spec the minimum viable solution. "Robust", "scalable", "enterprise-grade", "comprehensive" — these words invite scope creep. Specif

2026-06-30 原文 →
开发者

T-Mobile is booting customers from its oldest plans

Earlier today, T-Mobile started notifying customers that it will be retiring many legacy plans and moving subscribers onto one of its current rate plans. This move includes plans that date back to the 3G era, and it's going about as well as you'd expect. Affected customers began sharing screenshots of the text on reddit and […]

2026-06-30 原文 →
AI 资讯

OCI Database Auto Backup Window Time Slots Reference

The Database resource in Oracle Cloud Infrastructure Database service provides an optional auto_backup_window option in its API during creation ( Terraform resource: oci_database_database ). The database resource can be used in an OCI Base DB system or Exadata Cloud VM Cluster pluggable database (PDB) for example. The time window enum value selected for initiating automatic backup for the database system is available in twelve two-hour UTC time windows as the following: Slot Description SLOT_ONE 12:00AM - 2:00AM UTC SLOT_TWO 2:00AM - 4:00AM UTC SLOT_THREE 4:00AM - 6:00AM UTC SLOT_FOUR 6:00AM - 8:00AM UTC SLOT_FIVE 8:00AM - 10:00AM UTC SLOT_SIX 10:00AM - 12:00PM UTC SLOT_SEVEN 12:00PM - 2:00PM UTC SLOT_EIGHT 2:00PM - 4:00PM UTC SLOT_NINE 4:00PM - 6:00PM UTC SLOT_TEN 6:00PM - 8:00PM UTC SLOT_ELEVEN 8:00PM - 10:00PM UTC SLOT_TWELVE 10:00PM - 12:00AM UTC Timezone used for the slots is always UTC regardless of the timezone used in the database. For example, if the user selects SLOT_TWO from the enum list, the automatic backup job will start in between 2:00 AM (inclusive) to 4:00 AM (exclusive) If no option is selected, a start time between 12:00 AM to 7:00 AM in the region of the database is automatically chosen. Reference Terraform resource: oci_database_database OCI API Reference: Database DbBackupConfig Safe harbor statement The information provided on this channel/article/story is solely intended for informational purposes and cannot be used as a part of any contractual agreement. The content does not guarantee the delivery of any material, code, or functionality, and should not be the sole basis for making purchasing decisions. The postings on this site are my own and do not necessarily reflect the views or work of Oracle or Mythics, LLC. This work is licensed under a Creative Commons Attribution 4.0 International License (CC-BY 4.0) .

2026-06-30 原文 →
AI 资讯

How to Stop LangChain Agents from Bankrupting Your API Budget

In November 2025, an engineering team deployed a market research pipeline using four LangChain agents. Due to a logic failure, the "Analyzer" and "Verifier" agents got stuck in a recursive ping-pong loop. Because every individual API call was perfectly valid, the system appeared healthy on their dashboards. 11 days later, they discovered a $47,000 API bill . This is the hidden cost of building autonomous AI: infinite hallucination loops . When an agent encounters an error or fails to reach a termination condition, it will ruthlessly retry, burning through tokens in milliseconds. Why Built-in Controls Fail If you build with LangChain or LangGraph, you are likely relying on two things for cost control: max_iterations : An application-layer limit. LangSmith : An observability dashboard. The problem with max_iterations is that it requires every developer to perfectly hardcode it into every agent. Furthermore, iterations do not equal cost, a single iteration with massive context bloat can still cost a fortune. The problem with LangSmith (and all observability tools) is that they act as a witness, not a circuit breaker. By the time your dashboard alerts you that a spike occurred, the money is already gone. To safely deploy agents to production, you need Agent Runtime Governance , a network-layer firewall that physically drops the HTTP request the exact millisecond a budget hits zero. Enter Loopers . What is Loopers? Loopers is an open-source, baremetal reverse proxy for AI agents. It sits on your critical path between LangChain and your LLM provider (OpenAI, Anthropic, etc.). It uses atomic Redis Lua scripts to reserve budget before the request is sent to the provider. If the agent exceeds its budget, Loopers fails closed and instantly severs the connection, guaranteeing zero budget leakage. Here is how to implement Loopers into your LangChain workflow in less than 5 minutes. Step 1: Spin up the Loopers Firewall Loopers is incredibly lightweight (~40MB RAM) and runs via D

2026-06-30 原文 →
AI 资讯

🗄️ The JPA Enum Default Quietly Corrupts Your Data

You add an enum to an entity, slap @Enumerated on it, and move on. Five seconds. It is the kind of decision nobody writes a design doc for. Then six months later a row comes back as SHIPPED when it was PAID , no exception was thrown, no query failed, and you spend an afternoon learning that the default you never thought about has been silently rewriting history. Here is the order lifecycle we will use the whole way through: public enum OrderStatus { PENDING , PAID , SHIPPED , DELIVERED } Five ways to store it. They are not equivalent, and the gap between them only shows up under change. @Enumerated(ORDINAL): store the position This is the default. Leave the annotation bare and JPA stores the enum's ordinal, its index in the declaration order. @Enumerated ( EnumType . ORDINAL ) private OrderStatus status ; PENDING is 0, PAID is 1, SHIPPED is 2, DELIVERED is 3. The column is a tidy little smallint . Everything works. Until someone needs a new status and adds it where it reads well: public enum OrderStatus { PENDING , PAID , CANCELLED , // inserted here SHIPPED , DELIVERED } CANCELLED is now 2. SHIPPED is 3. DELIVERED is 4. Every row written before this change still holds the old integer, so every order that was SHIPPED (2) now reads back as CANCELLED . The database is correct. Your data is wrong. And nothing told you. If you are stuck with ORDINAL on a legacy schema, pin it with a test that fails the build the moment someone reorders: @Test void ordinalsAreFrozen () { assertEquals ( 0 , OrderStatus . PENDING . ordinal ()); assertEquals ( 1 , OrderStatus . PAID . ordinal ()); assertEquals ( 2 , OrderStatus . SHIPPED . ordinal ()); assertEquals ( 3 , OrderStatus . DELIVERED . ordinal ()); } New constants may only be appended. The test turns an invisible runtime corruption into a loud compile-time-ish failure. It is a guardrail, not a fix. @Enumerated(STRING): store the name Store the constant name instead of its position. @Enumerated ( EnumType . STRING ) private OrderS

2026-06-30 原文 →