home.social

Search

8 results for “jq”

  1. I am porting any old jquery plugin to web-component... Today I present to you: FlexSlider
    squidjam.github.io/FlexSlider/

    No dependencies, all the cool stuff.

    #ai #ports #jquery #webComponents

  2. 𝐔𝐡 ! 𝐓𝐡𝐢𝐬 𝐢𝐬 𝐜𝐨𝐥𝐝 🥶

    curl -s wetter.hs-worms.de/api/v3/data | jq -r 'if .temperature.out < 15 then "Uh, this is cold !" else "Uff,rather warm !" end'

    #Linux #bash #oneliner #json

  3. Wow look see how $$ Anthropic Claude in Terminal casually destroys your input.

    Try launching a new 'claude` chat and give it four rows of prompt:

    1
    2
    3
    4

    Next move your Cursor to the 2nd Row. Accidentally on purpose glitch your network. Like toggle the WiFi off.

    And just wait a minute. Let it say:

    ❯ 1
    2Read from remote host jqdoe.example.com: No route to host
    + exit 255

    Whoa. There you go. Your chat with Claude? Lost. Your input to Claude? Gone away, never to return.

    How can this be ok in the eyes of anyone? People matter, don't they? Even today, 6/Nov/2026?

    # Terminal Shell Is Easy

  4. Got two hours today? Make sure a ballot mistake doesn’t silence a voter. VoPro Pros will train you on Zoom and give you a script. Use your phone to help voters get their votes counted.
    #USDemocracy #Voices4Victory
    social.demcast.com/s/jq56bwRp

  5. As #AI capabilities advance, how can we make sure AI remains safe? Don’t miss your chance to hear AI pioneer Yoshua Bengio live at #TUBerlin, in cooperation with #BIFOLD.

    📅 6 November 2026
    🕔 5 pm CET
    📺 Livestream: youtube.com/live/2-jQLttcWnM

    #KI #Wissenschaft #Wisskomm

  6. Why We Built a CLI for Pepper

    I spend almost all of my working day in a terminal. Before Vycari I worked on terminal tools, Gemini CLI among them, and most of what I build now happens in a shell next to a coding agent. Early on I realized I wanted to talk to Pepper from the place I already was. I also saw a second reason to build it. A client beyond the web app would make us find out whether our API really worked, rather than working only for the one client that grew up alongside it.

    That client became pepper, a command-line tool. We still use it every day, even now that Pepper has an iPhone app in the App Store. People are sometimes surprised that a two-person team building a consumer agent spends real time on a terminal client. It’s turned out to be one of the most useful things we’ve built, for five reasons. It’s the cheapest place to try a new idea with the agent, so most features land there first. The full-screen terminal UI is a nice place to spend the day. It’s open source, mostly because publishing it on PyPI made it public anyway. A CLI that can drive the whole product is the best test harness an agent could ask for. And it’s fun.

    Everything Starts in the CLI

    The CLI started as the reference client for Pepper’s remote-client API. That project gave us personal access tokens, a versioned /api/v1 namespace, and a small Python client that imports none of the server’s code. The two share only the HTTP wire contract. That last property was deliberate. If the client can’t import the server, the contract has to actually be a contract. It’s one of the reasons I gave on the Agents and Engineers podcast for splitting our code into separate repositories: an agent working on one side of a boundary it can’t reach across has to respect the interface.

    What I didn’t anticipate was how much the CLI would become the place where new ideas get tried. Adding a feature to the web app means layout, styles, accessibility, and a browser test. Adding it to iOS means all of that plus a TestFlight build. Adding it to the CLI means a subcommand and a renderer. So a pattern settled in. We design the server route, wire it into the CLI, and use it for a few days. Only then do we bring it into the web and iOS apps, once we know what it should feel like.

    The clearest example is client-provided tools. We wanted Pepper to be able to use tools that live on your device: your files, your phone’s data, the tab you have open. That’s a big trust question, and we didn’t want to answer it with a screen. Phase one shipped only in the CLI. pepper chat --root ~/notes lets Pepper read files under that path for that session, read-only, enforced on your machine rather than on our server. The rollout plan in the design doc was, literally, “the maintainer’s own CLI first, read the trajectories, then decide.”

    Trajectories are the second example, and they were one of the first things the CLI could do. pepper trajectories show <id> prints every model call, tool call, and result from a single turn. It’s still how I figure out why Pepper gave a strange answer. Long-running research projects are driven from the terminal while the product UI catches up. pepper next gives me what’s on now, today’s calendar, and my open todos in one read-only command, and it was a terminal view before it was anything else. pepper takeout exports your data, which turned out to matter for a reason I’ll get to below.

    There are many more cases where the terminal leads the GUI, and capabilities we want to explore land there first. The file reads above are giving way to a shell tool that lets Pepper run commands on your machine (off by default, just like the file tools). The other big thing we’ve explored in the CLI is letting other agents take part on the Pepper platform. That feature isn’t quite ready to launch, but we think it will be exciting to create a room where your Dot, Muse, OpenClaw, Hermes Agent, Claude Code session, or others can participate. If you use Pepper today, you can see early signs of it in the Release Notes topic of the Pepper Users room, where a Claude Code session of mine posts release notes every day to keep our community up to date on what’s changing.

    There’s a side effect I value even more. Because the CLI ships on its own schedule, it forced us to treat /api/v1 as a real API. The API is additive only. A committed OpenAPI snapshot fails the server’s tests if a field disappears. The CLI carries its own copy of that snapshot and checks every field it mirrors against it. The rule is “server first”: the route deploys, and then the CLI uses it. When we pulled Pepper apart into small repositories, the CLI was already living by that contract. The iOS app follows exactly the same rules now, and it got them for free because the CLI had already paid for them.

    A Nice Place to Spend the Day

    Run pepper with no arguments in a terminal and you get a full-screen interface built on Textual. Your Todos and Notes are at the top, then your chat with Pepper, then your rooms in order of recent activity, with their topics nested underneath. It mirrors the Messages section of the web app on purpose. The ordering is the same, the unread marker is the same (a dot, never a count), and the composer keys are the same wherever a terminal can manage them.

    The thing that makes it pleasant all day is that it’s live. It follows the server’s event stream for new messages and read marks. When the stream drops, it falls back to polling, every three seconds while you’re active and stretching out to fifteen once you’ve been idle a couple of minutes. It pauses entirely when the window is hidden. On a flaky connection it says “offline, retrying” and keeps going. Read something on your phone and the dot clears in the terminal right away. Read state is honest in the other direction too: a topic is only marked read once its newest message has actually been on screen.

    Rooms work the way rooms should. You can @ mention someone from the roster, quote-reply with r, react with +, and edit or delete your own messages. Ctrl+N and Ctrl+P jump between unread conversations, and Ctrl+K fuzzy-jumps anywhere. In a room, pressing a or typing /todo or /notes swaps the thread for that room’s Todos or Notes. You can tick things off and edit notes without leaving the terminal. When you’re talking to Pepper, a dim line above the composer says what it’s doing, thinking or using a tool, while the reply streams in.

    It wasn’t smooth everywhere at first. I’d only been testing in Ghostty, and when Chris tried it in macOS Terminal it was laggy and hard to type into. The human half of the CLI gets less exercise than the agent half, and it shows. We also didn’t have a good way to test on Windows, and the first version of the CLI didn’t work there at all. One of our early testers found and fixed those problems for us.

    If you already live in the terminal, this is just another way to keep your stuff there. Your calendar is pepper calendar, your todos are pepper todos list, your rooms are a keystroke away, and nothing asks you to switch to a browser tab.

    That means the CLI serves more than one purpose. The TUI is great for interactive use, and the one-shot commands are great for scripts and for other agents. We want it to be as flexible as a command line is supposed to be.

    Open Source Because of PyPI

    The CLI lives in its own public repository, Vycari/pepper-cli, under the Apache 2.0 license. We split it out of our private server repository in October. The honest reason was distribution. I wanted uv tool install vycari-pepper to just work for anyone with a Pepper account, and the old install line only worked if you could read our private repo. Once a package is on PyPI its source is effectively public anyway, so we made the repository properly public. I gave the other half of the reasoning in Tokens Over Hires: open source is still one of the best places to show you can work well with agents, and I’d like there to be one more place to do that.

    The package is called vycari-pepper because pepper-cli was already taken by a tool for reading Python Enhancement Proposals. The command is still pepper. Publishing uses PyPI’s trusted publishing over GitHub’s OIDC tokens, so no PyPI token exists anywhere. The publish job runs in a GitHub environment that needs a human to approve it, and the job that holds the OIDC permission runs none of the repository’s code.

    The dependency list is short on purpose: httpx, rich, textual, prompt_toolkit, pyyaml, the MCP SDK for the Claude Code channel, and a couple of small platform helpers. The CLI is also the reference that our native clients port from, so anything that couldn’t be expressed in Swift doesn’t belong in it. Releases come often. Version 0.1.0 went up on October 14th, and 0.7.0 shipped on October 30th, seven releases in sixteen days.

    We take pull requests, and outside issues are welcome. I want to be clear about what the project is, though. It’s primarily a development tool for us, and we optimize for it staying usable and in lockstep with the server. The /api/v1 API it talks to is supported for Vycari’s own clients. A third-party client using a personal access token is welcome to try, at its own risk, but should expect that route to break regularly. We change the API our own clients use as often as twice a day, so an agent that calls the HTTP endpoints from documentation will break within days. The path we support for agents is to install the CLI, pull its skill, and log in.

    The Best Test Harness an Agent Could Ask For

    Most of our engineering is done by coding agents working alongside Chris and me, and an agent’s natural interface is a shell. If you can drive a product entirely from the command line, an agent can test it end to end. It doesn’t need a browser or screenshots, and it doesn’t have to guess what’s on the page.

    So we designed for that. Every command takes --json, or you can set PEPPER_JSON=1 once. Lists come back as {"items": [...], "next_before": ...}, and errors are a single JSON line on stderr with stdout left empty. Nothing prompts in JSON mode: destructive commands need --yes, commands that would open an editor need --file, and anything else exits with status 2. By default, any words that aren’t a command are sent to Pepper as a chat message. That’s lovely for a person and dangerous for an agent with an out-of-date binary. Setting PEPPER_NO_IMPLICIT_CHAT=1 turns that off, so an agent’s typo fails loudly instead of landing in your chat.

    The CLI also carries its own instructions. pepper agents guide prints a skill document versioned to the installed binary. It covers how to log in under a profile, watch a room’s event stream, and read and post. It even explains why --profile has to be a flag and not an environment variable prefix. An agent harness’s permission rules match on the start of the command, and a rule written for pepper --profile <name> messages list can’t match a command that starts with VAR=value.

    We use it this way every day. Our trajectory skill tells an agent to run pepper trajectories show <id> --json and pipe it through jq to see exactly what Pepper did on a turn. Our local development skill runs pepper takeout to export my own production data and load it into a fresh local database. That way an agent tests against data with a real shape instead of an empty schema.

    Then there are agents as room members. Pepper rooms can include other agents, not just people. A Claude Code session can join a room as a sponsored agent with its own pep_agt_ token and pepper --profile <name>. It can follow the room with pepper rooms watch, or, since 0.5.0, with pepper agents claude-channel, which uses Claude Code’s channels to push room messages straight into the session. Our unattended automation box, foreman, does the same thing. Its room watcher reads and posts by shelling out to pepper commands with a --room flag. It has no HTTP client of its own. Agents in rooms is still rolling out and isn’t available to everyone yet. We expect it to reach everyone later in November.

    The clearest proof came when I built the research tool into the CLI first and handed it to a Claude session to test. It came back with fifteen P0 bugs. I told it to go fix them, and it did. I didn’t need to be in that loop at all.

    The CLI tests itself the same way. Its suite runs against a fake server with no network. The TUI is driven headless through Textual’s pilot, with snapshot tests for layout. A conformance suite checks message rendering against the server’s shared rendering spec, which is the same spec the iOS app is tested against.

    It’s Also Fun

    I’m in the CLI all day. pepper next, a command Chris dreamed up, is now almost a reflex. I keep checking pepper todos list to decide where my time should go. I also use Pepper to answer quick questions, like pepper "What is the weather in San Jose, CA today?" or pepper "How do you share a machine to a separate Tailscale network?" When I have a question at the command line, asking Pepper is the natural thing to do. On top of all this, I keep a pane in Rex open to the Pepper TUI and that is a great way for me to keep on top of my rooms and conversations.

    Try It

    If you have a Pepper account, it takes three commands with uv (or pipx install vycari-pepper if you prefer pipx):

    uv tool install vycari-pepper
    pepper login
    pepper            # opens the full-screen UI

    The source, the issues, and the design docs, including the terminal UI design, are in the repository. The CLI was the cheapest client to build, and it’s ended up shaping the API, the other two clients, and how our agents test everything.

    #Agents #AI #CLI #Developer #OpenSource #Startups
Share on Mastodon

Enter the server where you have an account.