标签：#Fin

You shut the VM down to save money, and next month it is still on the bill. This is one of the most common Azure billing surprises, and it comes down to a distinction Azure does not make obvious: there is a difference between a VM that is Stopped and one that is Stopped (deallocated) , and only one of them stops the compute charges. Here is exactly what is happening, and the cost that survives even when you do it right. Stopped vs Stopped (deallocated) Azure has two "off" states, and they bill completely differently. Stopped (from inside the OS). If you run shutdown inside the guest OS, the VM powers off but Azure keeps the compute resources allocated to it. The status shows Stopped . You are still paying full compute price for a VM doing nothing. This is the trap. Stopped (deallocated). If you stop the VM from the Azure Portal, CLI, or PowerShell, Azure deallocates it, releasing the underlying compute. The status shows Stopped (deallocated) , and compute billing stops. So the rule: shutting down from inside the guest does not save you money. You must deallocate, and deallocation only happens when you stop it through Azure, not through the OS. # This deallocates and stops compute billing: az vm deallocate --resource-group my-rg --name my-vm # Inside-the-OS "shutdown" does NOT deallocate. Status stays "Stopped", billing continues. Check which state you are actually in: az vm get-instance-view --resource-group my-rg --name my-vm \ --query "instanceView.statuses[?starts_with(code, 'PowerState')].displayStatus" -o tsv If that returns VM stopped you are still paying. If it returns VM deallocated you are not paying for compute. The disks nobody mentions Here is the part that catches people even after they deallocate correctly: deallocation stops compute billing, not storage billing. The managed disks attached to the VM (the OS disk and any data disks) keep costing money whether the VM is running, stopped, or deallocated. A deallocated VM with a 512 GB Premium SSD is still

Everybody's cloud cost journey has the same first chapter: someone writes a Lambda that stops the dev instances at night and starts them in the morning. It works. It saves real money. And then the environment grows, and one morning the script that ran fine for a year quietly causes an outage. The shutdown script that works on one instance breaks at three hundred, and it breaks in four specific ways. Here is each one, because knowing them is the difference between saving money and writing a postmortem. The script that works on one instance # stop_dev.py, EventBridge at 20:00 import boto3 ec2 = boto3 . client ( " ec2 " ) ids = [ i [ " InstanceId " ] for r in ec2 . describe_instances ( Filters = [{ " Name " : " tag:env " , " Values " :[ " dev " ]}])[ " Reservations " ] for i in r [ " Instances " ]] ec2 . stop_instances ( InstanceIds = ids ) At small scale this is fine. At scale, here is what goes wrong. Break 1: dependency order Your app instance depends on a database. Stop them in a random order and starting back up, the app comes alive before the database is ready and lands in a crash loop. On one box you get away with it. Across an environment with app tiers, databases, and caches, ordering is not optional: databases up before apps, apps up before the things that call them. A flat list of instance IDs has no concept of "start this after that." Real scheduling needs dependency-aware sequencing (storage, then compute, then application), with delays between tiers. Break 2: timezones The script fires at 20:00. Whose 20:00? As you add teams in different regions, a single UTC cron either shuts down someone's environment in the middle of their afternoon or leaves it running all night. At scale, schedules have to be timezone-aware per environment or per team, not one global time that is wrong for most of the world. Break 3: no overrides, so people disable it The night QA needs staging up late for a release, the script kills it at 20:00 anyway. This happens twice, and then s

CPU rightsizing is a solved, well-documented practice. GPU rightsizing is where the real money is now, and almost nobody writes about it, because GPU instances are expensive enough that people are scared to touch them and unsure how. Given how much a GPU box costs per hour, an over-provisioned one is the single most expensive rightsizing mistake in your account. Here is how to rightsize AWS GPU instances without breaking the workload, including the compatibility check that quietly bites people. Know what each GPU family is for Rightsizing starts with using the right family, not just the right size. On AWS: G5 / G6 (NVIDIA A10G / L4): inference, graphics, smaller training. The workhorses for serving models and lighter ML. Cheaper per hour. P4 / P5 (A100 / H100): large-scale training and heavy inference. The expensive tier, built for jobs that genuinely need the horsepower and interconnect. The most common GPU waste is running a training-class P-family instance for an inference workload that a G-family instance would serve fine at a fraction of the cost. Wrong family is a bigger error than wrong size. Rightsize on the binding resource, and it is usually not CPU GPU workloads have several resources that can be the bottleneck, and CPU utilization, the thing you would check for a normal instance, is often the least relevant: GPU utilization: is the GPU actually busy, or idle between requests? (CloudWatch does not report this by default; you need the CloudWatch agent with GPU metrics or nvidia-smi telemetry.) GPU memory: many inference workloads are GPU-memory-bound, not compute-bound. A model that fits in less VRAM can move to a smaller GPU. Host CPU and RAM: sometimes the GPU is fine but the instance is over-sized on host resources. The rightsizing signal is a GPU sitting at low utilization or using a fraction of its VRAM over a sustained window (a 90-day-style baseline, same idea as CPU rightsizing). That is your candidate to move down a size or across to a cheaper fam

The deploy worked. The bill doubled. The blue-green cutover went perfectly. Traffic shifted to green, health checks passed, the team signed off, and moved on. It was one of those rare deployments that goes exactly as planned. Six weeks later, a cost anomaly surfaced in the monthly AWS review. Infrastructure spend had been running at roughly double what it should have been since the deployment date. Every EC2 instance, every RDS node, every load balancer from the blue environment was still running. Serving zero traffic. Billed at full price. For six weeks. Nobody had decommissioned it because nobody owned it after cutover. The team that ran the deployment assumed operations would clean it up. Operations assumed the team that deployed it would tear it down. The blue environment sat in a perfect ownership gap, healthy and idle and expensive, while both teams closed their tickets and moved on. This is the part blue-green deployment guides don't emphasize enough. The strategy is excellent for zero downtime releases and instant rollback capability. The rollback window is the dangerous part. It's open-ended by default, which means the old environment stays alive until someone makes a deliberate decision to shut it down. That decision requires ownership, and ownership requires someone to be responsible for it after the deployment is considered done. The fix is treating decommissioning as part of the deployment itself, not cleanup that happens afterward. Tag every blue environment resource at launch with a TTL: aws ec2 create-tags \ --resources i-1234567890abcdef0 \ --tags Key = DeploymentColor,Value = blue \ Key = CutoverDate,Value = 2026-01-14 \ Key = TTL,Value = 2026-01-21 Then wire Cost Anomaly Detection to alert when a specific environment tag is still generating spend past its TTL. The old environment doesn't get to become invisible just because traffic moved away from it. The deeper issue is that blue-green deployments create a window of parallel infrastructure that m

Zillow and Redfin reached a settlement with the FTC, which requires Redfin to reenter the rental advertising business.

Is the technique outdated? Yes. Is it still creepy? Also yes.

We open-sourced 449 real equipment financing quotes so nobody has to trust our math Commercial equipment financing sites are almost always a black box: you land on a page, see a monthly payment, and have no way to check how that number was actually derived. The APR is picked out of thin air, the "starting at" price is aspirational, and the amortization math is never shown. We built Equipment Capital Index to do the opposite — every page shows the real per-machine price, the actual amortization schedule, and now we've published the whole underlying dataset so anyone can verify or build on it. What's actually in the dataset equipment-financing-rate-data is a CC BY 4.0 dataset of aggregate financing benchmarks computed from 449 individually priced, real machines — construction equipment, ag machinery, trucking fleet, power equipment, and material handling gear. No survey estimates, no fabricated averages. Current live snapshot: Category Machines tracked Avg APR Avg est. monthly payment Heavy Construction 222 8.25% $3,272 Agriculture 84 7.75% $4,411 Trucking Fleet 63 8.00% $2,501 Power Equipment 44 8.50% $957 Material Handling 36 8.50% $825 Site-wide average: 8.17% APR , $2,954/mo across all 449 machines. Why this exists A couple of principles drove the design: Every number traces back to a real machine. Each of the 449 rows has a sourced price (dealer listing, MSRP, or a documented class-typical estimate — and it's disclosed which one) and a real amortization calculation, not a rounded guess. The math is reproducible, not just displayed. The same aggregation logic that powers the /press page on the site also generates this dataset — one source of truth computed twice, so the numbers can't silently drift apart. It shouldn't require scraping a webpage. The data has three independent, permanent homes: A live JSON API: /api/rate-report.json ( OpenAPI spec ) A self-updating GitHub repo (regenerates from live data every 3 days via GitHub Actions) A permanent, versioned DOI o

The last post was about making a number trustworthy. Leakage geometry, purge widths, de-overlap, a baseline that could not cheat. It ended with a minute-scale ceiling that held at 52% across seven configurations and a model family swap. This one is about what happens after you trust the number. Because a probability you are going to bet on is a different object from a probability you are going to report. The probabilities are not decorative The path-passage classifier is a three-class LightGBM. It returns p_up , p_down , p_none . Those go straight into the expected-value score that decides whether to take a trade and how big: long_score = p_up * ( B - C ) + p_down * ( - B - C ) + p_none * ( - C ) short_score = p_up * ( - B - C ) + p_down * ( B - C ) + p_none * ( - C ) B is the barrier, C the cost. Read the arithmetic. Every term is linear in a probability. Scale p_up by 1.2 and you scale the long score by very nearly 1.2. So miscalibration does not stay in the model. It becomes a bet-sizing error, in proportion, in the bins where the gate actually fires. A classifier that is right 70% of the time while claiming 90% is not 20 points wrong. It is sizing every position in that bin as though the edge were far larger than it is. Boosted trees are known for uncalibrated softmax output. I had been consuming it as if it were a probability. The audit Seven live assets. For each one, fit an Inductive Venn-Abers wrapper on the time-ordered older 80% of that model's training data, 6,988 rows, and evaluate against a 500-row uniform-random sample of the newer 20%, seed 42. The LightGBM models are reloaded from disk and left alone. Only the wrapper is fit. Measure Expected Calibration Error and log-loss, before and after. Asset ECE before → after ECE Δ Log-loss Δ BTC 0.1272 → 0.0621 -51.2% -5.5% ETH 0.1795 → 0.0298 -83.4% -11.5% SOL 0.1680 → 0.0386 -77.0% -10.6% XRP 0.2219 → 0.0645 -70.9% -17.7% ADA 0.1419 → 0.0369 -74.0% -8.0% LINK 0.1260 → 0.0737 -41.5% -1.2% LTC 0.1508 → 0.0603

Short version of a post on gex.live/research ; the full write-up, definitions and reproduce block live there. Most published dealer-gamma numbers are built from open interest : yesterday's outstanding contracts, multiplied by a convention about who holds which side. Whether the convention is right is a separate question. The prior question is simpler: how much of what trades today was already in that book this morning — and how much of tomorrow's book is being created today? Open interest and volume are enough to answer it, with no assumption about who bought. Sample: SPX and SPXW, 2022-04-14 to 2026-08-14, 1,081 trading days, every expiry within about a month (0DTE plus the 21 nearest), 8.6 million contract-days, 4.3 million with volume. Definitions Per contract (expiry, strike, right) and session D: OI(D) is open interest at the start of D, OI(D+1) at the start of the next session, ΔOI = OI(D+1) − OI(D) , vol the day's volume in that contract. |ΔOI| / vol is a lower bound on how one-sided the day's trading in that contract was — 1.0 means every lot opened (or every lot closed), 0 means opens and closes cancelled. Contracts expiring on D have no next-day OI and drop out of the ΔOI statistics; 4.1% of rows (3.8% of volume) show |ΔOI| > vol, which is impossible (OI snapshot timing) and are excluded. The book grows by 40% of what trades, every day days to expiry on D net ΔOI / volume |ΔOI| / volume (lower bound on one-sidedness) share of volume in contracts whose OI rose contract-days 1–5 37.8% 41.8% 90.3% 813,013 6–21 42.7% 53.3% 81.1% 2,206,446 22+ 42.8% 57.6% 76.5% 831,896 Across the whole book, net ΔOI is 39.9% of the day's volume on the median session (IQR 36.2–44.0%), positive in every year and every expiry bucket: the SPX book is always being built faster than it is unwound, until expiry does the unwinding. Far expiries are open-and-hold (a day's trading in a 22+ DTE contract is at least 58% one-sided); the nearest expiries churn (42% at 1–5 DTE). Per contract-

Are pigs flying? Walmart has finally caved on its refusal to support Apple Pay and Google Pay.

A small release, not a launch. The LAB tab on gex.live has a new rightmost rail called IDEA FEED . It is a stream of short, rule-shaped trading ideas about SPX dealer positioning — "fade the first touch of the call wall after a gap up", that kind of thing — collected daily by a scanner from what people actually discuss, rewritten into something the Lab compiler can parse, and published untested . That last word is the point. Why untested is the feature Every feed of trading ideas on the internet comes with a verdict attached: "this works", "78% win rate", a screenshot of a good month. The feed here refuses to do that. Each card says exactly two things about its idea: compiles clean (our compiler turned the text into a runnable rule without complaint) and untested (nobody has run it against the archive yet). The honest test is yours to run. One click drops the idea into the Lab conveyor. The compiler has already done the translation, so the first message in your session is the rule itself, stamped ↳ from IDEA FEED · compiles, untested . Running the backtest costs one Lab credit; a failed job refunds itself. If your balance is zero the button does not go dead — it turns into 0 CREDITS · BUY → , remembers the idea you picked, and comes back to it after. What you will not find No source attribution on the cards. The idea is the unit, not the poster. No win rates, no "rated", no thumbs. The archive is 1,000+ finished SPX sessions; the Lab tests against all of it with an out-of-sample split and tells you what survived, which so far is: very little. That verdict is worth more than a badge on a card. No approval gate. The scanner's finds ship directly every day, so the feed stays fresh by itself. "NEW" is personal — it means new since you last opened the rail, not new for everyone. Why build a feed that mostly produces "no" Because the alternative is pretending. The whole site is built on measuring dealer positioning from the tape instead of assuming it from yesterday's ope

Ramp has launched its own AI model routing service, dubbed Router, that lets users and companies use and switch between various large language models via an API.

Most engineering organizations now pay several vendors for AI coding assistants, each one bills differently, and no single person in the company can answer the simplest question: what did our AI coding tools actually cost this month, and what did we get for it? This guide is the practical answer — the metrics that matter, the ways teams track spend, a step-by-step setup, and an honest maturity model for governing it. The short answer To track AI code assistant spend across every vendor, pull cost and usage from each tool's admin or billing API, normalize it into one model — because every vendor bills on a different unit and a different clock — and map it to your teams and cost centers. The four approaches teams use are manual spreadsheets, each vendor's native dashboard, an open-source usage CLI, and a dedicated AI spend management platform. Only the last gives finance, engineering, and IT one live number plus forecasting, anomaly detection, and per-developer and per-pull-request cost. If you only do three things: inventory every assistant in use, including shadow tools bought on personal cards; connect each vendor read-only and normalize to a common cost model; and instrument the leading indicators — premium-model mix, token or credit runway, and idle seats — because they move before the invoice does. What "AI code assistant spend" means AI code assistant spend is the total cost an organization pays across all of its AI coding tools — commonly GitHub Copilot, Cursor, Anthropic Claude, OpenAI, and others teams connect — including per-seat license fees, metered token or credit consumption, premium-model surcharges, and the hidden cost of idle or duplicate licenses. It sits at the application layer, which distinguishes it from general cloud cost (compute, storage, networking), and it concerns money and utilization, which distinguishes it from AI model governance and its focus on model risk and compliance. Why it's genuinely hard to track (and got harder in 2026) There

Short version: An Application or Network Load Balancer costs ~$0.0225/hour, about $16/month, just to exist , plus capacity units. Classic Load Balancers run ~$18/month. Load balancers outlive the services behind them: the app gets torn down, the ALB keeps billing. Here's how to find load balancers with no real traffic or no healthy targets, and remove them safely. Why idle load balancers linger The hourly base charge is fixed - an ALB with zero requests bills the same ~$16/month as a busy one. Load balancers are usually created early (with an app or an IaC module) and deleted last, if ever. A handful of abandoned ALBs from old environments is real, recurring money. Step 1 - List load balancers and their traffic aws elbv2 describe-load-balancers \ --query 'LoadBalancers[].{Name:LoadBalancerName,Type:Type,ARN:LoadBalancerArn}' \ --output table For an ALB, check request volume over the last 7 days (the metric dimension is the tail of the ARN, e.g. app/my-alb/50dc6c495c0c9188 ): aws cloudwatch get-metric-statistics \ --namespace AWS/ApplicationELB \ --metric-name RequestCount \ --dimensions Name = LoadBalancer,Value = app/my-alb/50dc6c495c0c9188 \ --start-time " $( date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ ) " \ --end-time " $( date -u +%Y-%m-%dT%H:%M:%SZ ) " \ --period 86400 --statistics Sum \ --query 'Datapoints[].Sum' Near-zero request counts over a week is a strong idle signal. (For NLBs, use the AWS/NetworkELB namespace and ActiveFlowCount .) Step 2 - Check for empty or unhealthy target groups A load balancer with no healthy targets is doing nothing useful: for tg in $( aws elbv2 describe-target-groups \ --load-balancer-arn <lb-arn> \ --query 'TargetGroups[].TargetGroupArn' --output text ) ; do echo "== $tg ==" aws elbv2 describe-target-health --target-group-arn " $tg " \ --query 'TargetHealthDescriptions[].TargetHealth.State' --output text done Empty output (no targets) or all unhealthy alongside near-zero requests is a confident "delete me." Step 3 - Delete saf

The investment comes amid Navi plans to go public.

Short answer: for a small fintech product that turns reviewer voice notes into structured code findings, start with one synchronous speech-to-text file-upload adapter for MP3 and WAV, but write every upload to a tenant ledger before making the transcription request. That is usually the fastest integration because it keeps the first release small while preserving per-tenant cost visibility and a clean path to regional routing. Choice Shipping effort Tenant attribution Best fit Main constraint Direct file upload Lowest Clear with an internal ledger Short reviewer notes Bound by the selected API's request and duration limits Object storage plus async worker Medium Clear with job records Long or bursty recordings More states to operate Self-hosted transcription Highest Fully internal Strict control requirements or sustained workloads Model serving becomes your job My recommendation is the first row for the initial release. Keep the adapter replaceable, measure billed units rather than guessing from file size, and promote work to a queue only after real upload patterns justify it. The point isn't to find a universally fastest model. It is to ship weekly without losing the tenant-level evidence needed to understand margin. How should a simple speech-to-text API handle MP3 and WAV file uploads? Treat the upload as a business event, not as an anonymous call to an AI endpoint. Before sending any audio, create an internal record with tenantId , changeId , uploadId , media type, byte count, selected processing region, and a start timestamp. After transcription, add the external request identifier when one exists, the terminal status, and the billable unit reported by the selected service. A byte count is useful for capacity planning; it is not a substitute for actual billing data. That distinction matters in a multi-tenant SaaS. One tenant may submit many short WAV notes, while another submits compressed MP3 files with longer conversations. Charging, margin analysis, and abuse

I built a small manufacturing company end-to-end inside an SAP S/4HANA sandbox — one plant, one product, one month — specifically to watch what the month-end close does to a margin that looks healthy at billing time. Every number below comes from an actual document in that system. At billing, the month looked good Revenue 20,000 COGS at standard 12,800 Margin 7,200 = 36% Three days later, after the close, the same month landed at 1,200 = 6% . Nothing was posted incorrectly. Three gates took the 30 points, in this order. Gate 1 — Cost center revaluation (KSS1 / KSII) The planned price for the labour activity type was derived the usual way: planned cost divided by planned activity quantity. Production orders consumed hours at that planned rate all month. Then the actuals arrived. Depreciation posted 9,000 against a plan of 3,000 . Activity quantity did not move. So the actual activity rate came out at roughly three times the planned rate, and every hour any order had already consumed became retroactively more expensive. This is the part that surprises people: the damage was decided weeks earlier, in a transaction nobody files under "costing decisions" — planning the activity price. Gate 2 — Order variance (KKS1 / CO88) With the revalued rate applied (CON2), the production orders no longer settled clean. The difference split across variance categories and settled to variance accounts — not into inventory. That distinction matters. If it went to inventory, it would sit on the balance sheet until the goods were sold. It doesn't. It is parked, waiting for the next step. Gate 3 — Actual costing (CKMLCP) This is the step people forget, and it is where the margin actually dies. The actual costing run rolls the variance into the material's periodic unit price, and then moves the portion belonging to what was already sold into COGS. Before this run, the P&L still looked fine. After it, the 6,000 that had been sitting in variance found its way onto the income statement. What I

PayPal is still reportedly negotiating a potential sale to Stripe and private equity firm Advent, as the fintech firm's new CEO attempts to turn the company around.

I'm building a small tool that converts bank CSV files into .qbo files for QuickBooks ( qbofile.com ). When a generated file is wrong, QuickBooks rejects it with vague errors and the OFX spec doesn't tell you what QuickBooks actually checks. So I ran some experiments. Notes below, in case someone else hits the same wall. The file is not XML .qbo is Intuit's version of OFX 1.0.2, which is SGML. Leaf tags have no closing tag: <TRNAMT> -42.50 <FITID> 8f3a2b... Only aggregate tags close. The file also needs a 9-line key:value header, then one blank line, then the body. Line endings are CRLF. My first bug was closing every tag like XML. "Missing bid data" means one tag: INTU.BID QuickBooks checks <INTU.BID> against an internal list of banks that pay Intuit for Web Connect. I tested three variants on QuickBooks Desktop for Mac 2024: Variant Result No <FI> block, no <INTU.BID> Rejected: "Missing bid data" Only <INTU.BID> Accepted <FI> block + <INTU.BID> Accepted So the whole <FI> block (bank name, org id) can be dropped, but INTU.BID cannot. I have only tested the Mac version. If you know whether Windows versions behave the same, I'd like to hear. FITID decides duplicates QuickBooks dedupes on FITID, not on date + amount. If a converter generates random FITIDs, re-importing an overlapping date range creates duplicate transactions. I hash account + date + amount + description, so the same transaction always gets the same FITID. Credit card statement cycles never match calendar months, so overlapping imports happen more often than I expected. QuickBooks cannot export .qbo This one surprised me. No version of QuickBooks can produce a .qbo file. The format only goes one direction, from bank to QuickBooks. Every .qbo file in the world came from a bank's download button or from a converter. That's what I have so far. The tool is free for single files and runs fully in the browser, nothing gets uploaded. I have only tested against QuickBooks Desktop — if you use QuickBooks Online

Someone in every company eventually says this out loud. Usually it's the CFO. Sometimes it's a VP of engineering, or the unlucky engineer who got handed "own our cloud costs" on top of their actual job. The bill comes in, it's up again, the spreadsheet has eleven tabs, and someone finally says: "Stop. I don't want another spreadsheet. I need one picture that shows where the money goes." It's a completely reasonable request. It's also strangely hard to satisfy with the tools most teams already have. This post is about why, where the money usually turns out to be going, and what that one picture actually looks like. The bill answers "how much". The question is "where" A cloud bill is a flat table — a very big one. An AWS Cost and Usage Report can run to millions of rows, and every row is precise: this resource, this hour, this rate. If your question is "how much did we spend on EC2 in July", the tools answer instantly. But "where does the money go" is a different kind of question. A dollar enters the company as one line on an invoice and then travels: through a provider, into an account, into some kind of resource, and finally — ideally — onto somebody's team. It's a path, not a number. Flat tables don't show paths. Native tools slice one dimension at a time. Cost Explorer will show you spend by service. Or by linked account. Or by one tag. Each view is true, and each view is a dead end, because the question in the meeting is always a path through several dimensions at once: which team's non-prod environments, in which account, are driving the compute growth? Answering that with one-dimensional views means six tabs and a join you perform in your head. The join in your head is where the meeting dies. So people fall back to the spreadsheet. Someone brave builds a pivot table; it's accurate for a week, then a re-org or a new account lands and it quietly becomes fiction that everyone still forwards. Where the money usually goes We look at a lot of cloud bills. The leaks a