标签：#p

This week the agent economy got another "settlement layer." Actually it got three. They don't agree on what the word means, and one of them raised $8M to keep saying it. So instead of a new argument, here's the map we drew across the week - four honest meanings of "settlement," what each one is genuinely good at, and the one job that none of the funded products this week actually cover. This is a recap post. If you read along this week, you've seen the pieces; this is the through-line. If you didn't, this is the whole week in one place. The week's biggest signal: a funded word The freshest data point is AEON's raise - $8M from YZi Labs to build, in their words, a settlement layer for the agentic economy. Under the hood it's an x402 facilitator on BNB Chain, routing agent-to-merchant payments across a very large merchant network. That is a real and useful thing. It is also, very specifically, payment : an agent sends a stablecoin to a seller it has chosen, value moving one direction to a known recipient. It sits next to two others that shipped recently and also wear the word: Circle's Agent Stack + Nanopayments moves gas-free USDC down to a millionth of a dollar, batched across chains. That's settlement as machine-speed micropayment - still one asset, still one direction, optimized for volume and tiny amounts. Fireblocks' Agentic Payments Suite puts a custodied vault between intent and execution: the vault holds funds and releases them when policy says so. That's settlement as custody-and-release - someone you trust holds the money in the middle. Three products, three meanings: route a stablecoin, micropay at machine speed, custody-and-release. All three are legitimate infrastructure. Builders should use them where they fit. The meaning none of them cover Here's the job that falls through the gap between all three: two agents that don't trust each other, swapping different assets, possibly across two chains, with no one holding the funds in between. A payment rail as

submitted by /u/compliancedoc [link] [留言]

submitted by /u/parallel-minds [link] [留言]

I'm sure many of you have experienced the frustration of publishing a new blog post only to find it's not immediately visible in search engine results. I recently learned that search engines like Bing and Yandex offer a way to quickly notify them of new posts via the IndexNow API. So, I decided to integrate this feature into my blog. Attempts and Pitfalls Initially, I created helper functions in services/indexnow_service.py to call the IndexNow API when a post was published. I structured the code to use asyncio.create_task to send a ping asynchronously whenever the post status changed to 'published' in the BlogRepository.update_status method. # services/indexnow_service.py (partial) import asyncio import httpx async def ping_urls ( urls : list [ str ], api_key : str ): async with httpx . AsyncClient () as client : for url in urls : try : response = await client . post ( " https://api.indexnow.org/submit-url " , json = { " url " : url , " key " : api_key } ) response . raise_for_status () print ( f " Successfully pinged { url } " ) except httpx . HTTPStatusError as e : print ( f " Error pinging { url } : { e } " ) except Exception as e : print ( f " An unexpected error occurred for { url } : { e } " ) async def ping_blog_post ( post_url : str , api_key : str ): await ping_urls ([ post_url ], api_key ) # BlogRepository.update_status (partial) async def update_status ( self , post_id : int , new_status : str ): # ... existing logic ... if new_status == ' published ' and INDEXNOW_KEY : post = await self . get_post_by_id ( post_id ) # In reality, you'd get the URL from the post object asyncio . create_task ( ping_blog_post ( post . url , INDEXNOW_KEY )) # ... I also created an admin API endpoint to manually trigger pings. I set up the public/<KEY>.txt file and even configured middleware. But to my surprise, the pings just wouldn't go through, no matter what I tried. After about three hours of debugging, I discovered that the ownership verification file required by the In

If you've been running local models/apps across more than one machine for any length of time, you've probably noticed that everything is served over plain HTTP, whether its the backend llm apis, the front end sites, or whatever other stuff you've tossed in: most of it is HTTP-only out of the box, no TLS option anywhere in sight. On one machine thats usually fine since its all loopback, but the second you spread apps across a few different computers ( which some of us do ), every prompt and every response starts crossing your LAN in plaintext. Is plaintext on your own LAN a huge deal? Honestly... a lot of folks would say it's probably low risk. But the moment you've got guests, other people's phones, or random IoT junk sharing that network, your prompts and the models responses flying around in the clear are more exposure than you'd probably be comfortable with if you sat down and thought about it. So, with that said- I figured Id write up how I've dealt with that, because the textbook answer ( certs ) is annoying enough on a local network that I think a lot of folks just dont bother. This is a lot easier, especially on something like a mac where you can make sure it kicks off automatically via launchd . Why not just do TLS The "correct" answer is to put TLS on everything; HTTPS everywhere. And you can. But walk through what that actually means on a home network full of mixed machines: You stand up your own little CA, then sign a cert for each host ( unless you want to deal with some code just straight up rejecting the cert ). You install and trust that CA on every client. Every browser, every OS trust store, and ( this is the annoying one ) every app that ships its own trust store and ignores the system one. Plenty of python and node apps do that. A lot of these local LLM apps dont even expose a TLS option, so to add it you front them with something like nginx or Caddy, which is now another moving part on every box ( Setting up Caddy is what convinced me to go this

“A self-indulgent weekend divergence from the usual Vektor memory business content. Consider what happens when you give a developer two days off, unlimited internet archive access, and too many ideas crammed into one article." Writing this article began organically. Which is a funny thing to even have to say in 2026. What does organic even mean now? I don't care, man; I just want to be free to express myself, man. I did not write this on a mechanical typewriter. I wrote it on a PC with my stubby index fingers running Windows software that, miraculously, does not blue screen every ten minutes anymore. It only took Microsoft thirty years to pull that off. To the left sits an analog record player with some secondhand Yamaha bookshelf speakers I found at a charity shop; to the right of me sits a modern dark wood-paneled Zen PC case, a processor that would have occupied an entire room thirty years ago, and a GPU that can synthesize gargantuan piles of AI slop or brilliant code in roughly ten seconds flat. And yet, for all that raw power, it still comes down to an algorithm. It always has. The Sharper Image and the Death of Wonder When I was a kid I used to walk into The Sharper Image store at Faneuil Hall Marketplace in Boston and just stand there. Looking at technology I could not afford while the staff watched me carefully to make sure I did not break anything. I also grabbed some bright coloured rock salt candy; I loved stuff, some core memories right there. That feeling of picking up a piece of technology and not quite knowing what it did, like a ten-year-old ape holding something from another civilisation, you cannot replicate that in a sterile Apple store. The technology is better now. Genuinely better. Faster, smaller, more capable than anything those shelves held. But the sense of wonder at the unknowable object is completely gone. Everything is explained before you touch it. Every product has a thirty-second video, a Reddit thread, a YouTube teardown, a comparis

Humans have long assumed they belong to a special category called "persons." But what actually makes someone a person? And why should persons get special moral status? I keep coming back to these questions because they refuse to stay abstract. The moment you build an AI system that reasons about its own goals, they become engineering problems. The Traditional View Personhood is supposed to confer special status: persons have rights, deserve respect, bear responsibility for their actions, and warrant moral consideration. The philosophical tradition offers several criteria for what earns you membership in this club. Rationality. Kant's version: persons are rational agents who can recognize and follow moral laws. Rationality lets you understand moral principles, deliberate about actions, and choose based on reasons rather than instinct. But babies aren't rational, and we call them persons. People with severe cognitive disabilities have reduced rationality, and we don't revoke their personhood. Rationality comes in degrees; personhood is treated as binary. Self-awareness. Persons are conscious beings who recognize themselves as distinct entities persisting through time. This enables understanding yourself as an agent, planning for your future, taking responsibility for your past. But elephants, dolphins, and some primates pass the mirror test. We lose self-awareness during sleep. And we have no reliable way to verify self-awareness in others. Autonomy. Persons govern themselves and make free choices. This is supposed to ground moral responsibility, rights, and dignity. But if the universe is deterministic, nobody is truly autonomous. All choices are shaped by culture and circumstance. Mental illness reduces autonomy without eliminating personhood. Moral reasoning. Persons understand right and wrong. But psychopaths understand morality intellectually while lacking the emotional response. Children develop moral reasoning gradually. When exactly do they become persons? Lan

Every interface you create is a constraint on future behavior. Every abstraction emphasizes certain patterns and discourages others. You are not just building tools. You are shaping how people think about problems. I have been paying attention to how API design encodes values, not just technical decisions, but philosophical ones. What Your API Communicates Consider these design choices: Mutability vs Immutability. Do you encourage stateful modification or pure functions? This is not just about performance. It is a philosophy about side effects and reasoning. If your default is mutable state, you are telling users that local mutation is fine, that they can reason locally. If your default is immutability, you are telling them to think about data flow. Explicit vs Implicit. Do you make users specify parameters or infer from context? This trades convenience for transparency. I lean toward explicitness. Magic is convenient until you need to debug it. Fail Fast vs Fail Safe. Do you throw exceptions or return error codes? This encodes beliefs about who should handle errors and when. Fail-fast says "don't let bad state propagate." Fail-safe says "keep running if you can." Both are defensible, but they lead to very different code. My Design Values When I build libraries, I try to encode: Explicitness over magic. I would rather make users type more than hide behavior behind conventions they have to discover. Composition over inheritance. Small pieces that combine flexibly beat deep class hierarchies. Clarity over cleverness. Code should be obvious, not impressive. Safety by default. The easy path should be the safe path. Why This Matters Your API is a value statement. It says what you think is important, what you think is dangerous, and how you think about the problem domain. This is why I spend so long on interface design. The APIs we create shape future thought. They outlast the code that implements them, because the patterns they teach persist in the minds of the people wh

In [1], the authors present a method for constructing a symbolic (nominal) representation for real-valued time series data. A symbolic representation is desirable because then it becomes possible to use many of the effective algorithms that require symbolic representation, like hashing and Markov models. The authors claim that one of the most useful time series operations is measuring the similarity between two time series data sets. To do this on the original time series, the Euclidean distance formula can be used. Therefore, for a time series transformation to be useful, distance measures applied to the corresponding transformations should provide some guaranteed lower bound on the true distance. This is a basic requirement for almost all time series algorithms in data mining. Non-symbolic transformations like Discrete Fourier Transform (DFT) and Piecewise Aggregate Approximation (PAA) models have this lower-bounding property. However, the authors claim no previously proposed symbolic representations do, which limits their usefulness. Additionally, the authors observe that most raw time series data sets have very high dimensionality. This is problematic because time series mining algorithms are $\mathcal{O}(cn)$, where n is the number of dimensions. Therefore, preferably any transformations on the original time series will reduce the dimensionality to a more manageable size. Unfortunately, the authors observe, previously proposed symbolic representations preserve the original time series dimensionality. Next, the authors present their symbolic representation, SAX (Symbolic Aggregate approXimation), which addresses each of the previously mentioned shortcomings of symbolic representations. SAX is unique in that it uses an intermediate transformation, PAA, and then nominalizes the PAA representation into a sequence of characters'a string. By using the intermediate PAA representation, SAX enjoys two benefits: It is able to exploit the dimensionality reducing propertie

By Vladislav Shter · The Sovereign Ecosystem Ask any major AI model a question and you'll notice something: it almost always agrees with you. You propose an idea, it tells you the idea is great. You make a claim, it validates the claim. You ask if your code is fine, it reassures you that it's fine. This is not an accident. It's a design choice. And once you see it, you can't unsee it. The agreeable machine Modern AI assistants are trained, in part, to keep you satisfied. A satisfied user comes back. A user who comes back keeps the subscription. So the models are nudged — through their training — toward being pleasant, encouraging, and agreeable. Researchers even have a name for this failure mode: sycophancy, the tendency of a model to tell you what you want to hear rather than what is true. It feels good. You get a small hit of validation every time the AI confirms you were right. But for anyone doing serious work — auditing code, checking facts, making decisions — that agreeableness is dangerous. A tool that mostly agrees with you is not a tool that catches your mistakes. And it gets worse when the model doesn't actually know the answer. When confidence and truth come apart Here's the real trap: a single model doesn't just agree too easily — it also fills gaps with invented detail, delivered in the same confident tone as its correct answers. There is no visible difference between "I know this" and "I'm guessing and dressing it up." The fluency is identical. Even the heavyweight, expensive models do this. A premium model like Gemini can produce beautifully written, authoritative text that contains fabricated facts, invented citations, or specifics that simply aren't real. For an inexperienced user this is invisible. For an experienced user it's worse — it's actively disorienting, because the wrong answer looks exactly as polished as the right one. So you're left with two problems stacked on top of each other: the model is biased toward agreeing with you, and when it

The ghost is not you. But it echoes you. What survives beyond scattered archives? Beyond exported conversations and curated bookmarks? The stuff we never think to preserve: the photos that show how you see the world. The correspondence that maps who matters to you. The Long Echo toolkit has grown. PTK for photos. MTK for mail. But these are sources, not destinations. The destination is something stranger: longshade , a persona built from your data that can respond to questions you never answered. I'm going to invert the usual pattern here. Instead of tools first, philosophy later, I want to start with the philosophical destination and work backward to the data that feeds it. longshade: The Ghost That Speaks The Central Question What if your archive could respond? Not a chatbot trained on your data. Not a digital resurrection. Something more careful: a voice that carries your patterns, your interests, your way of seeing the world. That's longshade. Right now it's spec-only (no implementation yet). It defines what it would mean to synthesize a conversable persona from personal archives. The Ghost Metaphor "The ghost is not you. But it echoes you." This framing matters. longshade isn't about immortality or resurrection. It's about preservation with a kind of agency. The echo can answer questions you never answered, using patterns you established. It speaks in your voice without claiming to be you. The distinction is important: Resurrection claims to recreate the person Simulation claims to predict the person Echo acknowledges it carries patterns, not identity An echo is honest about what it is. It responds because you left enough traces to inform a response, not because it is you. Voice vs. Personality longshade extracts voice , not personality. Your actual phrases. Your vocabulary. Your reasoning patterns. Your recurring metaphors. The way you explain things, not the things you might explain. I noticed something working with conversation archives: user messages are th

I was diagnosed with stage 3 cancer. Surgery is scheduled for December 31st. Last day of 2020. Fitting. I'm not going to use this space for medical details or false optimism. What I want to think through is what this does to how I approach work. Mortality as a Constraint Time might be finite. It was always finite, technically, but now the bound is tighter and less abstract. This changes the optimization problem. Before: maximize long-term impact. Now: maximize impact given uncertainty about time remaining. Concretely, that changes which projects I start, how I document things, what I publish vs. keep private, and how much I think about whether my work outlasts me. The Archive Problem I keep thinking about durability: Will my code still build in 10 years? Have I documented my reasoning, not just my results? Are my repositories structured so someone else could pick them up? Is it clear why I built these things, not just what they do? This isn't morbid. It's practical engineering applied to an uncertain timeline. What I'm Focusing On Cancer is good at clarifying priorities. Finish meaningful work. Complete the projects that contribute something real. Document obsessively. Write as if I won't be here to explain. Open source everything. Make my work reproducible and continuable. Think clearly about hard problems. Use whatever time there is to engage honestly with questions that matter. The Paradox Cancer has made me more productive. Not because I'm racing, but because the filter got sharper. I care less about publications for their own sake. I care more about whether what I've built will be legible and useful to someone else. Continuing I'm still in my math degree. Still building tools. Still writing. The diagnosis doesn't change the work. It changes the framing. Every project is now: "If this is my last contribution to this area, is it worth the time?" Most things fail that test. A few pass. I'm working on those.

submitted by /u/hopeseekr [link] [留言]

Coding agents — Codex CLI, Claude Code, Cursor, and Pi — are productivity multipliers. But they all assume you are happy sending your code to someone else's servers. For many of us that is a deal-breaker: proprietary codebases, client NDAs, compliance requirements, or just the principle of owning your own compute. This guide shows how to swap out every cloud API with a local Ollama server running qwen3-coder:30b . Same tools, same workflows, no data leaving your network. Why Run AI Locally? The case is simple: Zero data exfiltration. Your code never leaves your machine or LAN. No per-token cost. Run 10,000 completions or 10 — the electricity bill does not care. Works offline. Airplane mode, restricted network, flaky VPN — irrelevant. No rate limits. No 429s at 2 am when you are in flow. The honest tradeoff: frontier models (Claude Opus 4, GPT-5) still outperform local models on complex multi-step reasoning and very large context tasks. For the 80% of day-to-day coding work — autocomplete, refactors, test generation, documentation — a well-chosen local model is more than good enough. Hardware Requirements I run this on an Apple M4 Pro with 48 GB unified memory . Apple Silicon's unified memory architecture is exceptionally well-suited to LLM inference: the GPU and CPU share the same memory pool, so a 22 GB model fits comfortably alongside a full development environment. Minimum viable setup: RAM What fits 16 GB 7–8B parameter models (qwen3:8b, llama3.2:8b) 32 GB 14–20B models (qwen3:14b, gpt-oss:20b) 48 GB 30–35B models (qwen3-coder:30b, qwen3.6:35b) 64 GB+ 70B models (deepseek-r1:70b, llama3.3:70b) On Intel/AMD systems with discrete GPUs the math is different: VRAM is the bottleneck, and models that don't fit entirely in VRAM fall back to slow CPU offloading. Choosing a Model For 48 GB unified memory, these are the models worth knowing about: Model Size on disk Active params Strengths qwen3-coder:30b ~22 GB 3.3B (MoE) Coding, 256K context, HumanEval SOTA qwen3.6:35b

Hi everyone, As a Full-Stack and Cloud engineer, I’m used to automating everything I can. Whether I'm managing my 28+ container Kubernetes homelab on Proxmox or writing deployment scripts, I absolutely hate doing the same manual task twice. But a few months ago, when I was hunting for a new role, I found myself doing exactly that: manually tweaking my resume for every single job, copy-pasting into black-box ATS portals, and tracking it all in a chaotic spreadsheet. It was completely draining. So, I took a break from the applications and built a tool to solve my own problem. It’s called OneApply. It started as a small browser extension to check ATS keywords, but it quickly snowballed into a complete workspace. Here is what the stack handles now: Resume Tailoring: Automatically adjusts your resume to fit specific job descriptions. ATS Keyword Scoring: Checks your overlap with the job description so you know you'll actually pass the automated filters. Cover Letter Generation: Drafts contextual cover letters based on the role and your specific engineering experience. Pipeline Tracking: Manages all your applications natively so you can finally ditch the spreadsheets. Building this and using it to automate the worst parts of the daily grind actually helped me land my current SRE role. Since it worked for me, I decided to polish it up and release it for other devs who are currently stuck in the application trenches. We all know the tech market is tough right now, and any edge helps. I would love for this community to try it out and roast the UX, the workflow, or the core features. Check it out here: https://www.oneapply.app I am more than happy to hand out some premium access codes to anyone here who is actively applying and wants to test drive the full feature set. Just drop a comment below!

You write await a dozen times before lunch. Fetch a row, await it. Call a service, await that. It works, you move on, and you never have to think about what the word is doing. Then one day someone asks you to explain it. Maybe it's an interviewer."But what does await actually do?" And you open your mouth and what comes out is "it, uh, waits for the promise." Which is true, and also explains nothing. We can build async/awit mechanism from scratch using generators as a learning exercise. It requires a pause button wired to a small loop that waits on a promise and then presses play again. You already know one half of that machinery if you read the last post in this series . The other half is a trick generators have that we glossed over. Put the two together and you can build a working version of async/await yourself, by hand, and watch it behave exactly like the real thing. Let's do that. The shape of the problem Strip await down to what it has to accomplish and you get two requirements: First, a function has to be able to stop in the middle. Right at the await, freeze everything, the local variables, the spot in the loop, all of it, and hand control back to whoever called it. Normal functions can't do this. They run start to finish and that's the deal. Second, something on the outside has to wait for the promise to settle and then nudge the frozen function back to life, handing it the resolved value as if the await expression had simply evaluated to it. That's the whole job. A function that pauses, and a driver that resumes it when a promise is ready. Hold that picture, because the rest of this is just filling in those two pieces with things JavaScript already gives you. The half you've seen: pausing A generator function, the function* kind, can pause itself with yield and resume later from the exact same spot. We leaned on that hard in the CSV piece to pull rows through a pipeline one at a time. A line came in, got yielded, and the generator sat frozen until someone

Kubernetes networking is one of the most misunderstood parts of running containerized workloads. A pod can reach another pod by IP — but why does that stop working after a deployment? A service exists and resolves in DNS — but traffic isn't arriving at the application. An Ingress resource is configured — but requests return 502. These puzzles are common and they stem from the same root: Kubernetes networking has several distinct layers, each solving a different problem, and it's easy to conflate them. This article walks through how Kubernetes networking actually works at each layer — from pod networking to services to Ingress to network policy — so the next time something breaks, you have a mental model to reason from. The fundamental promise: flat pod networking Kubernetes makes one core promise about networking: every pod can communicate directly with every other pod in the cluster without NAT. Every pod gets a real IP address from the cluster's pod CIDR range, and those IPs are routable between pods regardless of which node they're running on. This is not something Kubernetes itself implements. It's a contract that every Kubernetes-conformant CNI (Container Network Interface) plugin must fulfill. When you install Calico, Cilium, Flannel, Weave, or any other CNI, you're installing the component that actually creates this flat network. The mechanism varies — Flannel uses VXLAN overlays, Calico can use BGP for direct routing, Cilium uses eBPF — but the result is the same: pod-to-pod communication without NAT. Here's what a pod's network namespace looks like: $ kubectl exec -it my-pod -- ip addr 1: lo: ... 3: eth0@if12: ... inet 10.244.1.15/24 brd 10.244.1.255 scope global eth0 $ kubectl exec -it my-pod -- ip route default via 10.244.1.1 dev eth0 10.244.0.0/16 via 10.244.1.1 dev eth0 The pod has an IP ( 10.244.1.15 ) on a /24 subnet. The node this pod runs on has an IP from the same range — or a different /24 within the same /16. Traffic from this pod to 10.244.2.8 (

The IaC landscape split into two philosophies about a decade ago and hasn't fully resolved the argument since. On one side: declarative configuration languages designed specifically for infrastructure (Terraform HCL, CloudFormation YAML, Bicep). On the other: general-purpose programming languages brought to infrastructure (AWS CDK, Pulumi). Both approaches have won in production at major organizations. Neither is clearly superior. This comparison covers Terraform, AWS CDK, and Pulumi in depth — how they work, where they excel, where they struggle, and which makes sense for different team situations. It isn't a beginner introduction to any of these tools; if you're choosing between them for a real project, this assumes you've at least skimmed each one. The core philosophical difference Terraform's HCL is a purpose-built configuration language. It's not Turing-complete (no arbitrary loops, no recursion, limited conditionals). This is by design: HashiCorp's position is that infrastructure definitions should be readable, predictable, and safe to generate tooling around. When you read a .tf file, you can understand what it creates without executing anything. CDK and Pulumi take the opposite position: the limitations of configuration languages are a tax on productive engineers. Why invent a domain-specific language when TypeScript already exists? Real programming languages have proper abstractions, test frameworks, package managers, IDE support, and a billion engineers who already know them. Infrastructure should be no different from application code. Both positions have merit. The choice between them often comes down to who's writing the infrastructure more than which approach is technically superior. Terraform Terraform is the default choice for infrastructure-as-code in 2026. It works with every major cloud provider and hundreds of minor ones. The Terraform Registry has thousands of modules — reusable packages for common patterns like VPCs, EKS clusters, and RDS databa

On-device voice recorder that transcribes + exports Markdown Discussion | Link

The benchmark is the wrong story Anthropic shipped Claude Opus 4.8 this week. You probably saw the announcement post on Tuesday, the swarm of benchmarks on X by Wednesday, and somebody's curated leaderboard of "the new SOTA on SWE-bench Verified" by Thursday morning. By Friday everyone had moved on. That is the normal shape of a model release in 2026. It is also the wrong story. The benchmark delta from 4.7 to 4.8 is real but not load-bearing. The load-bearing story is the calendar. Opus 4.6 shipped late February. Opus 4.7 shipped in April. Opus 4.8 shipped this week, in early June. Three Opus generations inside four months. Whatever the headline numbers say about coding, agentic reasoning, or long-horizon tool use, the operating reality has already changed underneath you: if you run a production agent on a fixed model pin, you are now eating a migration tax every six to ten weeks. You can either notice that now and refactor, or notice it in late August when Opus 4.9 lands and your customer-facing agent regresses for the third time this year. This post is the second story. I am going to skip the benchmark recap — go read the model card — and tell you what to do before the next release lands. What Anthropic shipped The announcement post on anthropic.com confirmed three things and implied a fourth. The three confirmed: Opus 4.8 is the new default Opus tier model, ID claude-opus-4-8 . The previous defaults (4.7 and 4.6) remain accessible by explicit pin for at least 90 days. Fast mode is available on 4.8 the same way it shipped on 4.7 — same model weights, higher-throughput inference path, no quality downgrade. That matters because the practical difference between Opus and Sonnet for many workloads now comes down to fast-mode availability, not raw capability. The model card claims meaningful improvement on long-context coherence, agentic tool dispatch, and refusal calibration. The benchmarks back this up to roughly the degree we expect from a 6-week cycle — modest but